Re: Multi image PDF continuous mode

[dalanicolai <dalanicolai@gmail.com>]

[-- Attachment #1: Type: text/plain, Size: 4971 bytes --]

After reading this thread, and especially after reading this message
<https://lists.gnu.org/archive/html/emacs-devel/2018-04/msg00087.html> by
Eli (if
the links don't work, I have attached them also at the end), I have again
looked
into this. I would like to share my perspective on this, but before I do
that,
let me first ask you if you have any idea about why pdf-tools is not part of
Emacs. It is a very high quality package, that already lazily loads the
images,
and provides many sophisticated features.


You might already be familiar with my 2-buffer continuous scroll hack
<https://github.com/dalanicolai/pdf-continuous-scroll-mode.el> for it
(which can be easily ported to doc-view mode, but 'developing' a 'real'
continuous scroll mode solution makes much more sense, and, if possible, to
me
it would make even more sense to try to get pdf-tools into Emacs).

Some related interesting announcements are that:

- I have written an alternative server for pdf-tools, which uses the pymupdf
<https://pymupdf.readthedocs.io/en/latest/>
  library. You can read more about it in the PR
<https://github.com/vedang/pdf-tools/pull/61>. A nice thing about its design
  is that it uses the python interpreter/REPL directly as a server (it reads
  messages and prints to standard output). It already extends/complements
the
  features of the original epdfinfo server by supporting line/arrow
annotations
  and supporting the EPUB format very nicely. Additionally, it enables
other non
  C programmers to extend its features (e.g. support for freetext
annotations
  should be only little work).

- I have created a, very rude but already nicely working, 'real' continuous
  scroll proof of concept, for which, if you are interested, you can find
the
  code in this commit
<https://github.com/dalanicolai/pdf-tools/commit/b76a6337c39f114aa668e9f1985bfdfd87bd857d>.
It currently uses a trick where it only uses two images
  at the time, but as I will describe now, I think it will be better to
create a
  'bookroll' package for it.


The 'continuous' rendering is only part of implementing continuous scroll
into
pdf-tools because it would also be nice if it could be made compatible with
all
pdf-tools its features. After investigating how to achieve that, I have
come to
the conclusion that we need a 'bookroll' alternative to 'image-mode',
because
the main obstacle is that pdf-tools now uses image-mode functions, that are
written only for a single overlay per buffer.

I think the bookroll should not be so difficult to implement (I first
started to
think about a general 'image-roll', but I think continuous scrolling is
generally not what you want for viewing/scrolling images, so it can be just
a
dedicated bookroll). So my current idea for how to implement it, is by
immediately creating overlays for all pages in a single buffer and fill them
with 'empty' svg-images of the correct size (after testing this with a
thousand
'placeholders', it seems that the 'empty' images use almost no memory).
Then,
the scrolling can be implemented, by changing the display properties (from
empty
svg to real image, and back) and jumping to the correct positions using
`set-window-vscroll`. I have started on writing bookroll.el, of course your
joined efforts or feedback would be very much appreciated. Otherwise, this
short
message serves just to inform you about these activities.

Finally, it would be great if you could share your 'knowledge' about why
pdf-tools is not in Emacs. Its main developer has stepped down from the
project,
and 'vedang' has taken the roll of new maintainer. Anyway, I guess we could
best
ask the former and current maintainers as soon as possible about thier
'opinions' and for signing the necessary papers.

https://lists.gnu.org/archive/html/emacs-devel/2018-04/msg00087.html
https://github.com/dalanicolai/pdf-continuous-scroll-mode.el
https://pymupdf.readthedocs.io/en/latest/
https://github.com/vedang/pdf-tools/pull/61
https://github.com/dalanicolai/pdf-tools/commit/b76a6337c39f114aa668e9f1985bfdfd87bd857d



On Thu, 9 Dec 2021 at 21:06, Juri Linkov <juri@linkov.net> wrote:

> >> After doc-view generates a gallery of PDF images, image-dired could be
> >> invoked on the output directory of PNG images, and indeed in this case
> >> the window layout of image-dired looks like what most PDF viewers do:
> >> on the left side there is a narrow window with thumbnails of PDF
> >> pages, and on the right side a larger window with PDF pages.
> >
> > Scaleable document viewer should generate the images lazily.
>
> Indeed, for long documents we will need more optimization:
> not to load all images at once, but only after going to the next page.
> At the beginning each page could have a placeholder, either just
> newlines or an empty image.  Then navigating to a page,
> it will attach the image file with the display property.
> Also only visited pages should update their images when
> the user zooms or changes other parameters, etc.
>
>

[-- Attachment #2: Type: text/html, Size: 6138 bytes --]