The server in this repository contains an early experimental version of a python
pdf-tools server. Unlike the epdfinfo server, this version of the python server
communicates via the EPC protocol (instead of using the transaction queue). The
only reason for that is that at the time of writing I knew how to use EPC but I
did not yet learn about transaction queues. Finally, a better (faster)
alternative python pdf-tools vimura-server can be found at the python package
index here.
For using the vimura-server it is required to use the production branch of my
pdf-tools fork. After installing the fork and the server (using pip install),
the server can be used by selecting it via M-x pdf-tools-toggle-server.
Unfortunately svg’s turn out to use a lot of internal memory when used on full
screen(-width) (here M-x-: (window-width nil t) tells me that its 1904
pixels; also read explanation here). Fortunately they seem to use
significantly less memory when used on half screen (or split window, here
window-width is 944 pixels). Therefore it is recommended to use this only on
half screen width (and maybe experiment with full screen while monitoring your
internal memory usage).
Because png’s use less internal memory and because also this solution is not
so fast (before the images have been cached), I have created another test
using a similar approach but embedding three png’s in a root svg file and
using the epdfinfo server. The result can be found here. Installation and
usage are the same as for this package when replacing vimura with
pdf-cscroll. However, the result of this test seem to be that the
vimura-epc solution on half screen works best (especially when someone finds
a way to cache images in advance).
This package provides an alternative to the great pdf-tools (maintenance
transferred to vedang/pdftools). There are two main differences between this
package and pdf-tools its approach (although the approach was heavily inspired
by pdf-tools):
1. Instead of using the epdfinfo server this package uses pymupdf via
python-epc making it much more hackable.
2. The package uses svg for rendering the pages, making it easier to combine multiple pages into a single image, hence enabling the possibility for ‘real’ continuous scrolling.
These two differences have a few more advantages:
- pymupdf offers possibilities to add e.g. arrow annotations (see pymupdf-mode) and editing form fields (This should be possible with poppler also, but the epdfinfo server does not have it implemented.
- svg allows for drawing on the image with elisp directly, which could be handy
when editing forms.
However this is all still a far sight. The package currently is just a very simple basic proof of concept.
speed
Unfortunately, pymupdf and elisp are not blazingly fast. Therefore there is
some lag when first visiting a new page (probably most of the lag is due to
python exporting 3 svg images and subsequently emacs combining them. If the
package gets more mature then probably we could request the mupdf developers
to implement it in the c code of mupdf directly, because it is really just a
tiny amount of work). However, the lag is more or less eliminated after that
due to caching of the images, try it!:) (byte- or even native-compiling the
/home/dalanicolai/git/vimura-epc/vimura-epc-client.el also helps).
As the lag is more or less eliminated after caching, all lag could probably get eliminated by caching images in advance (probably asynchronously).
rendering Due to some some weird svg behavior (probably a svg bug), pages often do not get rendered well (adding multiple times the same page(/images) to a single root svg seems to always work, but when adding different pages, then often later pages don’t get rendered well. I will probably create a bug report for it soon).
To try out this package, first install pymupdf (available on most GNU/linux
distributions or better install with pip). Then clone this repo and load the
vimura-epc-client.el file. Finally use M-x find-file-literally some pdf
file and then M-x vimura-mode.