So the idea is that the bookroll can be used for doc-view (and possibly
djvu.el) also.
The code for the new server is also 'crude' code, but it works fine here (I
am no
professional programmer, so I appreciate any feedback about anything).

On Sat, 8 Jan 2022 at 08:11, dalanicolai <dalanicolai@gmail.com> wrote:

> 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.
>>
>>