Multi image PDF continuous mode

Multi image PDF continuous mode

[Juri Linkov]

Doc-view has such a long-standing shortcoming that it doesn't allow
continuous scrolling of PDF pages when one PDF page at the top of the
window smoothly flows into the next PDF page at the bottom of the window.

But it seems there is no inherent limitation in Emacs that would
prevent implementing this.  And indeed after doc-view generates
PNG images in /tmp/docview*/*pdf/*.png it's possible to insert
absolute filenames of all PNG files into some buffer, then enable
two modes:

  M-x iimage-mode RET

that replaces filenames with images, and after

  M-x pixel-scroll-precision-mode RET

wheel-mouse scrolls consecutive PDF images smoothly
like all decent PDF viewers do.

OTOH, scrolling keys are not so nice, and PgUp/PgDn
insist on jumping to the top of the next image.
But maybe image-scroll-up and image-scroll-down
could be adapted to multi image buffers,
possibly by creating a new mode multi-image-mode.
Also mouse dragging could help in scrolling.

Now when looking at this problem from another point of view,
browsing a list of image files is what image-dired.el
is intended to do.  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.

PS: Actually, there is some weird problem in image-dired: when
the thumbnail window is resized to a width less than half-frame,
then image-dired creates a new thumbnail window.  But surely
this could be fixed.

Re: Multi image PDF continuous mode

[Stefan Kangas]

Juri Linkov <juri@linkov.net> writes:

> Now when looking at this problem from another point of view,
> browsing a list of image files is what image-dired.el
> is intended to do.  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.

Yes, we should be able to do this, and make it work nicely.  I might be
able to help on the image-dired.el side.

> PS: Actually, there is some weird problem in image-dired: when
> the thumbnail window is resized to a width less than half-frame,
> then image-dired creates a new thumbnail window.  But surely
> this could be fixed.

Indeed, I have noticed that too.  It's on my TODO-list, if no one beats
me to it.

Re: Multi image PDF continuous mode

[Tomas Hlavaty]

On Thu 09 Dec 2021 at 19:05, 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.

Re: Multi image PDF continuous mode

[Juri Linkov]

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

Re: Multi image PDF continuous mode

[dalanicolai]

[-- 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 --]

Re: Multi image PDF continuous mode

[dalanicolai]

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

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: 6952 bytes --]

Re: Multi image PDF continuous mode

[dalanicolai]

[-- 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 --]

Re: Multi image PDF continuous mode

[Stefan Kangas]

dalanicolai <dalanicolai@gmail.com> writes:

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

It's a very good package, indeed.  As for why it doesn't ship with
Emacs, I think it's the usual story: we don't have the copyright
assignments for it that the Emacs maintainers insist on.

If we could collect the copyright papers for it and get in on GNU ELPA,
that would be an excellent step forward.

Re: Multi image PDF continuous mode

[Juri Linkov]

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

It would be nice to include pdf-tools in Emacs, but I don't know
if the new maintainer has an intention to submit it for inclusion.

> You might already be familiar with my 2-buffer continuous scroll hack for it
> (which can be easily ported to doc-view mode, but 'developing' a 'real'
> continuous scroll mode solution makes much more sense

I agree, a real continuous scroll mode would be more preferable.

> - 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. It currently uses a trick where it only uses two images
>   at the time

While two-images approach could provide better optimization for memory,
it has severe limitations, e.g. the vertical scroll bar can't be used
to scroll all images at once.

>   but as I will describe now, I think it will be better to create a
>   'bookroll' package for it.

This is a promising direction.

> 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

Why not?  'image-roll' could be useful for the image gallery packages
like image-dired.el and thumbs.el.

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

Good news, so loading a 1000-page document won't take much memory.
Only scrolling will load real images.  Maybe then after a real image
will be scrolled out of view, it could be replaced with a placeholder again
to free 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.

Thanks, feel free to post updates about your progress
or when stuck on some problems.

Re: Multi image PDF continuous mode

[dalanicolai]

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

Okay, so I have got a working Proof of Concept / core functionality.
You can very easily test it by loading the bookroll.el file from here
<https://github.com/dalanicolai/bookroll.el>,
then do `M-x br-test` and scroll using `j`/`k`. I will now focus on trying
to implement
it into pdf-tools, which is probably a little more work as its code is
quite complex/opaque.

@Juri
```
Maybe then after a real image
will be scrolled out of view, it could be replaced with a placeholder again
to free memory.

> Then, the scrolling can be implemented, by changing the display
properties (from empty
> svg to real image, and back)
```

Haha, that is exactly what I meant with exactly that (the following)
sentence.
Anyway, thanks for the nice response!


On Sat, 8 Jan 2022 at 19:33, Juri Linkov <juri@linkov.net> wrote:

> > 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.
>
> It would be nice to include pdf-tools in Emacs, but I don't know
> if the new maintainer has an intention to submit it for inclusion.
>
> > You might already be familiar with my 2-buffer continuous scroll hack
> for it
> > (which can be easily ported to doc-view mode, but 'developing' a 'real'
> > continuous scroll mode solution makes much more sense
>
> I agree, a real continuous scroll mode would be more preferable.
>
> > - 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. It currently uses a trick where it only uses two
> images
> >   at the time
>
> While two-images approach could provide better optimization for memory,
> it has severe limitations, e.g. the vertical scroll bar can't be used
> to scroll all images at once.
>
> >   but as I will describe now, I think it will be better to create a
> >   'bookroll' package for it.
>
> This is a promising direction.
>
> > 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
>
> Why not?  'image-roll' could be useful for the image gallery packages
> like image-dired.el and thumbs.el.
>
> > 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).
>
> Good news, so loading a 1000-page document won't take much memory.
> Only scrolling will load real images.  Maybe then after a real image
> will be scrolled out of view, it could be replaced with a placeholder again
> to free 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.
>
> Thanks, feel free to post updates about your progress
> or when stuck on some problems.
>

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

Re: Multi image PDF continuous mode

[Juri Linkov]

> Okay, so I have got a working Proof of Concept / core functionality.
> You can very easily test it by loading the bookroll.el file from here,
> then do `M-x br-test` and scroll using `j`/`k`. I will now focus on trying
> to implement
> it into pdf-tools, which is probably a little more work as its code is
> quite complex/opaque.

One problem is that the vertical scroll bar doesn't allow scrolling all images.

>> Maybe then after a real image
>> will be scrolled out of view, it could be replaced with a placeholder again
>> to free memory.
>
> Haha, that is exactly what I meant with exactly that (the following)
> sentence.

This is nice that you already took care about this case.

>     > 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.
>
>     It would be nice to include pdf-tools in Emacs, but I don't know
>     if the new maintainer has an intention to submit it for inclusion.
>
>     > You might already be familiar with my 2-buffer continuous scroll hack
>     for it
>     > (which can be easily ported to doc-view mode, but 'developing' a
>     'real'
>     > continuous scroll mode solution makes much more sense
>
>     I agree, a real continuous scroll mode would be more preferable.
>
>     > - 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. It currently uses a trick where it only uses
>     two images
>     >   at the time
>
>     While two-images approach could provide better optimization for memory,
>     it has severe limitations, e.g. the vertical scroll bar can't be used
>     to scroll all images at once.
>
>     >   but as I will describe now, I think it will be better to create a
>     >   'bookroll' package for it.
>
>     This is a promising direction.
>
>     > 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
>
>     Why not?  'image-roll' could be useful for the image gallery packages
>     like image-dired.el and thumbs.el.
>
>     > 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).
>
>     Good news, so loading a 1000-page document won't take much memory.
>     Only scrolling will load real images.  Maybe then after a real image
>     will be scrolled out of view, it could be replaced with a placeholder
>     again
>     to free 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.
>
>     Thanks, feel free to post updates about your progress
>     or when stuck on some problems.