Re: Multi image PDF continuous mode

[dalanicolai <dalanicolai@gmail.com>]

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

I forgot to attach the link to the (initial) bookroll
<https://github.com/dalanicolai/bookroll.el> code.

https://github.com/dalanicolai/bookroll.el

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

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

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