From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.io!.POSTED.blaine.gmane.org!not-for-mail From: dalanicolai Newsgroups: gmane.emacs.devel Subject: Re: Multi image PDF continuous mode Date: Sat, 8 Jan 2022 08:11:50 +0100 Message-ID: References: <86lf0tq5zy.fsf@mail.linkov.net> <87ilvxinbn.fsf@logand.com> <86pmq5lf2o.fsf@mail.linkov.net> Mime-Version: 1.0 Content-Type: multipart/alternative; boundary="000000000000f0247405d50cd11b" Injection-Info: ciao.gmane.io; posting-host="blaine.gmane.org:116.202.254.214"; logging-data="27909"; mail-complaints-to="usenet@ciao.gmane.io" Cc: Tomas Hlavaty , Emacs Devel To: Juri Linkov Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane-mx.org@gnu.org Sat Jan 08 08:38:32 2022 Return-path: Envelope-to: ged-emacs-devel@m.gmane-mx.org Original-Received: from lists.gnu.org ([209.51.188.17]) by ciao.gmane.io with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.92) (envelope-from ) id 1n66J6-00075n-1a for ged-emacs-devel@m.gmane-mx.org; Sat, 08 Jan 2022 08:38:32 +0100 Original-Received: from localhost ([::1]:56476 helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1n66J4-00052D-8g for ged-emacs-devel@m.gmane-mx.org; Sat, 08 Jan 2022 02:38:30 -0500 Original-Received: from eggs.gnu.org ([209.51.188.92]:60864) by lists.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1n65ta-0003LM-8e for emacs-devel@gnu.org; Sat, 08 Jan 2022 02:12:10 -0500 Original-Received: from [2607:f8b0:4864:20::935] (port=36841 helo=mail-ua1-x935.google.com) by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_128_GCM_SHA256:128) (Exim 4.90_1) (envelope-from ) id 1n65tT-0008Sk-Rl for emacs-devel@gnu.org; Sat, 08 Jan 2022 02:12:07 -0500 Original-Received: by mail-ua1-x935.google.com with SMTP id r15so14272739uao.3 for ; Fri, 07 Jan 2022 23:12:03 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20210112; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=MnwvpCx+qDgaGcEf/DNFQVrcA/+H6wA0q6TDPpbEx5M=; b=PhzmJLxhhU+FXhgXeDUFkUdB1P3Gan4lIlFrefi7FkTdtATqcACcftIDP/EMppmehi tbSbunIs2EeZ6KZZhAXi8S7cdm21V0MOtw6dJMZprNmZBcbVq13r8CElskNeMAlfSc2V yMZKd+WjuMnY/CL76ZEVE1O2IHIzFThgAOa4AK4JFEApIUcClj+XkieiS8mOW47Yg9qb uHS3rGDHY0GB5Ot+0RLgGnNwshKiXIpWk5u6D6FCd9/GvORRNegxknvfoLtGLoQ6QwPq Equ5p9MWTWatOyzejPq6xui6Ots2XfnDJLi4J6YHNVn9VwuBq4Ikk9ncAB8aFJHNv8GG EO0Q== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=MnwvpCx+qDgaGcEf/DNFQVrcA/+H6wA0q6TDPpbEx5M=; b=wiLGtV2aClOVu300+yUGtJZumYWxIF1EAnGKJJn9JhhciLYnNlzuJ4CtX1B9GSCfWY uYL2KidZXMuwDBUhMPxzDvl40Tq7vZviaAEX55cScG9dQgjAfX/3lg6oYNYWRTbIs/tU yQyDcLJmHDAqfSiZmBg3x8efxTNNVn0ThCnXxzbpxAMEcJHy3lJmzU64h4Mt8qsUJ+90 LSDvwnl/6K/zir6rCt9O3kcaIMiT/UGy+DbESJgAe5eepJ2Kvg6Cswz6b6O1HjikbE2x 3js0dq3gAnmZ3n6bhVaKekwxzR9i3nB6AVXCboOY9CCngyLd4k1Q7WxZcFRoKvmONWGw Fpgg== X-Gm-Message-State: AOAM532mJUAqxyK//BIFAK4Em3NMZzSS22C09dGrZFXAmebW+BplXrMY mI/QbXviNhGm4Q/QayHO59KMNzdhd1uR427ht5MM3/ipqMg= X-Google-Smtp-Source: ABdhPJzXCPM2RcGqnfMtzSihwLXIFNLSWvvBq6zxrB4zkCotRNf/njEmaNq6AJxB4iCwFqh8n5dxcrjTFsl7gThwjdM= X-Received: by 2002:ab0:3807:: with SMTP id x7mr19877075uav.134.1641625922051; Fri, 07 Jan 2022 23:12:02 -0800 (PST) In-Reply-To: <86pmq5lf2o.fsf@mail.linkov.net> X-Host-Lookup-Failed: Reverse DNS lookup failed for 2607:f8b0:4864:20::935 (failed) Received-SPF: pass client-ip=2607:f8b0:4864:20::935; envelope-from=dalanicolai@gmail.com; helo=mail-ua1-x935.google.com X-Spam_score_int: -12 X-Spam_score: -1.3 X-Spam_bar: - X-Spam_report: (-1.3 / 5.0 requ) BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, RDNS_NONE=0.793, SPF_HELO_NONE=0.001, SPF_PASS=-0.001 autolearn=no autolearn_force=no X-Spam_action: no action X-BeenThere: emacs-devel@gnu.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "Emacs development discussions." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: emacs-devel-bounces+ged-emacs-devel=m.gmane-mx.org@gnu.org Original-Sender: "Emacs-devel" Xref: news.gmane.io gmane.emacs.devel:284445 Archived-At: --000000000000f0247405d50cd11b Content-Type: text/plain; charset="UTF-8" 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. > > --000000000000f0247405d50cd11b Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
After reading this thread, and especially after reading th= is message by Eli (if
the links don't work, I have attache= d 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 pro= vides many sophisticated features.


You might already be familiar= with my 2-buffer continuous scroll hack for it
(which can be easily p= orted to doc-view mode, but 'developing' a 'real'
c= ontinuous scroll mode solution makes much more sense, and, if possible, to = me
it would make even more sense to try to get pdf-tools int= o Emacs).

Some related interesting announcements are that:
=
- I have written an alternative server for pdf-tools, which uses the pymupdf
=C2=A0 l= ibrary. You can read more about it in the PR. A nice thing about its design
=C2=A0 is t= hat it uses the python interpreter/REPL directly as a server (it reads
= =C2=A0 messages and prints to standard output). It already extends/compleme= nts the
=C2=A0 features of the original epdfinfo server by supporting li= ne/arrow annotations
=C2=A0 and supporting the EPUB format very nicely. = Additionally, it enables other non
=C2=A0 C programmers to extend its fe= atures (e.g. support for freetext annotations
=C2=A0 should be only litt= le work).

- I have created a, very rude but already nicely working, = 'real' continuous
=C2=A0 scroll proof of concept, for which, if = you are interested, you can find the
=C2=A0 code in this commit. It currently uses a trick where it only uses two ima= ges
=C2=A0 at the time, but as I will describe now, I think it will be b= etter to create a
=C2=A0 'bookroll' package for it.


T= he 'continuous' rendering is only part of implementing continuous s= croll into
pdf-tools because it would also be nice if it could be made c= ompatible with all
pdf-tools its features. After investigating how to ac= hieve that, I have come to
the conclusion that we need a 'bookroll&#= 39; alternative to 'image-mode', because
the main obstacle is th= at 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 dif= ficult to implement (I first started to
think about a general 'image= -roll', but I think continuous scrolling is
generally not what you w= ant for viewing/scrolling images, so it can be just a
dedicated bookroll= ). So my current idea for how to implement it, is by
immediately creatin= g overlays for all pages in a single buffer and fill them
with 'empt= y' svg-images of the correct size (after testing this with a thousand'placeholders', it seems that the 'empty' images use almo= st no memory). Then,
the scrolling can be implemented, by changing the d= isplay properties (from empty
svg to real image, and back) and jumping t= o the correct positions using
`set-window-vscroll`. I have started on wr= iting bookroll.el, of course your
joined efforts or feedback would be ve= ry 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.


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.=C2=A0 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.

--000000000000f0247405d50cd11b--