由于它使用 Dynamic Module 构建，响应速度很快，支持多种格式：pdf、epub 等（最主要也是这两种）。目前关于阅读方面的功能比较完整，翻页、缩放、自适应窗口高度/宽度，不过注释等功能还缺着。
我这两天和开发者一起推进跨平台的进度，目前 MacOS 平台下已经完美运行，但 Windows 平台还不清楚。开发者主要使用 Linux，我主要用 MacOS，缺乏 Windows 测试环境。
在 Emacs 下阅读 PDF、ePUB 电子书又有另外一个选择，而且我觉得实现比较优雅。当前在 emacs 下可以阅读 PDF 的包有：pdf-tools、eaf-pdf、org-embed，都各自有各自的不便。比如说 pdf-tools 和 eaf-pdf 的外部依赖都很多，org-embed 虽然不用外部依赖，但 Xwidget 贴片在 Emacs 的窗口里的位置有时候很难固定。
目前为止，我非常看好 emacs-reader 的发展。希望它尽快丰富更多和注释有关的功能。
我看它的描述，他是生成 svg 展示的。能否选择其中的文字吗？
现在还不行。现在的功能仅满足正常地看。
这大概是个什么原理？如果是生成 svg 的话，它为什么会比 pdf-tools 性能更好呢？
我之前研究了一下，pdf-tools 有时候性能让人难以忍受的原因主要是 emacs 的 cairo 后端滤镜用错了，导致图片滚动非常慢。不过我还没把这个 patch 交到主线里。
这里不应该用 CAIRO_FILTER_BEST。当然这个问题只有在 smoothing 为 true 的时候才触发，一般是放大的时候会让 smoothing 为 true.
你可以 patch 了之后对比一下看看。
我好像完全没有说 emacs-reader 的性能比 pdf-tools 好，我只是说外部依赖更加简约了。希望你仔细阅读了帖子之后再回复。
哦，确实没仔细看。
期待提交patch
如果能选中文字跟Emacs进一步交互就好了。
不错，期待。
弱弱地问问，是不是terminal下Emacs 是不可以用这个的？
看了一下构建流程 （makefile）还是可以优化的。
比如在 macOS 上 hardcode homebrew 的路径。实际上 macOS 也有人使用 nix，macport的。
再比如在 linux 上是自动 fetch submodule 从源码构建 mupdf 再构建动态模块。其实不是所有的发行版都有 mupdf 的依赖问题，如果用户用 nix 或者能够自己搞定 mupdf 的依赖（比如pymupdf），完全不需要再做一遍从源码构建 mupdf 的工作。
当然 mupdf 的依赖问题马上就会被上游发行版修复了，到时候就不需要 submodule 了。因此我打算再等等再去看能不能优化构建流程。
我很看好这个包，把构建流程优化好了，我觉得可以取代 pdf-tools。主要依赖少了，而且支持更多的富文本格式。我也不需要 pdf 的批注功能，这年头做笔记整理都交给 AI 了，pdf 能做好看这个工作就足够了。
没试过，我发现我不会用 emacs -nw，进入之后不知如何按 M-x
Hack 了一下 dynamic module 的构建，可以使用 Linux 自带的 mupdf 了。
(straight-use-package `(reader :type git :host codeberg :repo "divyaranjan/emacs-reader"
:files ("*.el" "render-core.so")
:pre-build ("cc" "-fPIC" "-shared" "-o" "render-core.so" "-DLINUX"
"render/elisp-helpers.c" "render/mupdf-helpers.c" "render/render-core.c"
,@(split-string-shell-command
(string-trim-right
(shell-command-to-string "pkg-config --cflags --libs mupdf"))))))
pdf-tools是poppler，这个是mupdf，mupdf不论性能还是功能都比poppler强一点
不错，希望支持 dark 模式
已经支持了
关心下，这个和nov相比看epub有什么优势？
面对页面比较多的 epub，它的处理性能比较优秀，我用 nov 总是在一些小地方感觉卡卡的。emacs-reader 则不会。
不过目前功能也比较简陋，只能看，不能选择、复制文字。不知道添加了更多功能后，性能表现是否依然优秀。