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

From: Eli Zaretskii <[email-masked]>
Date: Thu, 12 Jan 2023 10:11:38 +0200

> Cc: [email-masked]
> From: Visuwesh <[email-masked]>
> 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.