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

Previous Next

Full log

Message #32 received at 58041 <at> debbugs.gnu.org (full text, mbox):

From: Visuwesh <visuweshm <at> gmail.com>
To: Stefan Monnier <monnier <at> iro.umontreal.ca> 
Cc: 58041 <at> debbugs.gnu.org
Subject: Re: bug#58041: [PATCH] docview: Use svg images when using mupdf for
 conversion
Date: Thu, 12 Jan 2023 12:13:27 +0530

[Message part 1 (text/plain, inline)]

[திங்கள் ஜனவரி 09, 2023] Stefan Monnier via "Bug reports for GNU Emacs, the Swiss army knife of text editors" wrote:

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

I should have said "leads to blurry images when zooming when using PNG
images."  My bad.  It is the same as when we use +, - to zoom in on a
PNG image in image-mode.

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

Right, then I guess adjustment of that sort is in order.  How about the
following patch?  It should be safe enough to go to emacs-29.

[0002-Use-internal-image-scaling-when-using-SVG-images-in-.patch (text/x-diff, attachment)]

[Message part 3 (text/plain, inline)]

I see that the user option is also used by doc-view-insert-image but I'm
not sure if the adjustment is needed there as well.

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

Indeed, it is a misleading name.  This change will have to go to master,
I believe?  I have to look around a bit more to see where the function
is being used.
There's also the fact that there's more than one more program that can
generate SVG files (as Gregory pointed out in this thread) so it might
be nice to have pdf->png and pdf->svg "function variables" and a "super
function" that actually does the job.  Hopefully, this will allow to
fall back gracefully to PNG if SVG generation is faulty.

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

Thanks for the feedback, how about the following patch?

[0001-etc-NEWS-Announce-doc-view-s-SVG-support.patch (text/x-diff, attachment)]

Previous Next

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