bug-gnu-emacs
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

bug#58041: [PATCH] docview: Use svg images when using mupdf for conversi


From: Eli Zaretskii
Subject: bug#58041: [PATCH] docview: Use svg images when using mupdf for conversion
Date: Thu, 12 Jan 2023 10:11:38 +0200

> Cc: 58041@debbugs.gnu.org
> From: Visuwesh <visuweshm@gmail.com>
> Date: Thu, 12 Jan 2023 12:13:27 +0530
> 
> >>> 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.

Since this is not fixing a bug, I'd prefer it to go to master.

> +** doc-view now 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 which leads
> +to genearlly sharper images (especially when zooming) and
> +customization of background and foreground color of the page via the
> +new user options 'doc-view-svg-background' and
> +'doc-view-svg-foreground'.  To get the old behaviour, set
> +'doc-view-mupdf-use-svg' to nil.
> +Note that MuPDF SVG generation is known to sometimes generate files
> +that are buggy or can take a long time to render.

The last sentence makes me wonder why we made a less-than-perfect
option the default.  It's against our usual conservative approach.





reply via email to

[Prev in Thread] Current Thread [Next in Thread]