GNU bug report logs - #58041
[PATCH] docview: Use svg images when using mupdf for conversion

Previous Next

Full log

View this message in rfc822 format

From: Stefan Monnier <monnier <at> iro.umontreal.ca>
To: Visuwesh <visuweshm <at> gmail.com>
Cc: 58041 <at> debbugs.gnu.org
Subject: bug#58041: [PATCH] docview: Use svg images when using mupdf for conversion
Date: Mon, 09 Jan 2023 18:02:49 -0500

>>>> IIUC this means that `+` and `-` now don't need to re-process the PDF, right?
>>>> I think this is particularly valuable for things like ODT where `+/-`
>>>> was pretty slow (because it re-created the PDF each time before having
>>>> a chance to focus on the current page).
>>> It depends on the value of `doc-view-scale-internally'.  The default
>>> value (t) implies that we change the :width image property which leads
>>> to blurry images when zooming.  In my case, even without zooming in, the
>>> image quality was noticeably worse.
>>
>> So `doc-view-scale-internally` should default to nil when we use SVGs, right?
>
> It should default to t, which is the case currently.

Then what did you mean by:

    The default value (t) implies that we change the :width image
    property which leads to blurry images when zooming.

>>> If `doc-view-scale-internally' is nil though, what you say happens.
>> IIUC you're saying here that when `doc-view-scale-internally` is nil we
>> re-create the SVGs every time the users try to zoom in/out?  While not
>> strictly a bug, it's a significant inefficiency we should address, no?
> I suppose so.  But I'm not really sure if users out in the wild adjust
> the variable.

I set it to nil because of the blurriness.

> If they do, then it might be worth looking into ignoring
> that variable if we're generating SVG images.

Ah, that'd be a good option, indeed.

>> Another thing that's odd now is that we use
>> `doc-view-pdf->png-converter-function` to convert to SVG, despite
>> its name.
>
> It felt like a waste to create a separate pdf->svg function since it
> would contain the same exact BODY of mupdf pdf->png function since we
> only change the PNG argument to end with a .svg extension at the caller
> site (see doc-view-set-up-single-converter).

I wasn't thinking of duplicating the code, but of rethinking the naming
a bit.  I think what we meant by "pdf->png" is actually the process that
extracts pages (which just happened to use the PNG format and now can
also use the SVG format).

>     * doc-view generates SVG images when viewing PDF files if possible.
>     If Emacs is built with SVG support, doc-view defaults to generating SVG
>     files when using MuPDF as the converter for PDF files.  To get the old
>     behaviour, set 'doc-view-mupdf-use-svg' to nil.
>     Note that MuPDF SVG generation is known to be buggy for certain files.

Sounds good.  In my case, it wasn't "buggy" but just very slow (the
generation of the SVG is fast, but the SVG is very slow to render), so
maybe the last line should say:

      Note that MuPDF SVG generation is known to sometimes generate
      files that are buggy or can take a long time to render.

Also, the wording suggests the new default is a poor choice, so we may
want to include a more positive note about why we choose it as a default
despite its occasional downside (i.e. better rendering).


        Stefan

Previous Next

GNU bug tracking system
Copyright (C) 1999 Darren O. Benham, 1997,2003 nCipher Corporation Ltd, 1994-97 Ian Jackson.