After reading this thread, and especially after reading this message 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 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 library. You can read more about it in the PR . 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 . 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 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. > >