yibie
1
由于它使用 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 的发展。希望它尽快丰富更多和注释有关的功能。
14 个赞
我看它的描述,他是生成 svg 展示的。能否选择其中的文字吗?
这大概是个什么原理?如果是生成 svg 的话,它为什么会比 pdf-tools 性能更好呢?
我之前研究了一下,pdf-tools 有时候性能让人难以忍受的原因主要是 emacs 的 cairo 后端滤镜用错了,导致图片滚动非常慢。不过我还没把这个 patch 交到主线里。
这里不应该用 CAIRO_FILTER_BEST
。当然这个问题只有在 smoothing
为 true
的时候才触发,一般是放大的时候会让 smoothing 为 true.
6 个赞
yibie
6
你可以 patch 了之后对比一下看看。
我好像完全没有说 emacs-reader 的性能比 pdf-tools 好,我只是说外部依赖更加简约了。希望你仔细阅读了帖子之后再回复。
1 个赞
弱弱地问问,是不是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 能做好看这个工作就足够了。
yibie
14
没试过,我发现我不会用 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"))))))
3 个赞
SPQR
16
pdf-tools是poppler,这个是mupdf,mupdf不论性能还是功能都比poppler强一点
yibie
20
面对页面比较多的 epub,它的处理性能比较优秀,我用 nov 总是在一些小地方感觉卡卡的。emacs-reader 则不会。
不过目前功能也比较简陋,只能看,不能选择、复制文字。不知道添加了更多功能后,性能表现是否依然优秀。