bug#33226: chromium, firefox sharper than doc-view

[Tassilo Horn <tsdh@gnu.org>]

積丹尼 Dan Jacobson <jidanni@jidanni.org> writes:

> emacs x.pdf #and then use "+ runs the command doc-view-enlarge" many times.
>
> We observe a /tmp/docview*/*.pdf-*/ is created and contains a png
> conversion of the PDF, and a second factor file: page-1.png,
> resolution.el. We note that the resolution.el has not changed. Inside is
> "100" and that has not changed despite our zooming.
>
> So that's probably why the file doesn't look as clear in docview vs. the
> others! You must admit it is fuzzier at 400% zoom than the others.

Yup, this means Emacs has ImageMagick support built in and scales in
memory rather than reconverting with a higher resolution.  So if your
Emacs has ImageMagick support (which is NOT the default anymore due to
security concerns), I'd suggest to set doc-view-resolution to a higher
value, e.g., 200.

> But wait! *Not* on the INFO page is
>
> (defcustom doc-view-scale-internally t
>   "Whether we should try to rescale images ourselves.
> If nil, the document is re-rendered every time the scaling factor is modified.
> This only has an effect if the image libraries linked with Emacs support
> scaling."
>   :version "24.4"
>   :type 'boolean)
>
> And indeed, setting it to nil makes the bug go away, as proved by
> resolution.el finnaly changing each time we hit "+".

Right, it wouldn't be bad to enhance the documentation with those
details.

> So, this critical variable, if t, will cause scaling to silently fail
> in half the cases ("if the image libraries linked with Emacs..."
> fails. So should be nil by default, so that it never fails, I suppose.

I don't know.  Internal scaling is fast and its quality is very good if
you scale down (but not up, therefore use a high resoltion in this
case).  And when you open a 1000 pages book and then zoom, do you really
want that emacs starts reconverting each and every page?

> Also I think there in /tmp/ it should save a copy of the previous few
> scales each time we hit + or - so we can quickly zoom in and back out
> etc.

Well, that would be feasible for small documents (where a reconversion
doesn't matter that much), but for large documents I wouldn't want to
have hundredth of megabytes of image data which I probably wouldn't use
anyway.

Bye,
Tassilo