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

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

[積丹尼 Dan Jacobson]

[-- Attachment #1: Type: text/plain, Size: 159 bytes --]

Here I have opened both chromium and emacs (lower frame),
and zoomed one step, on a PDF.

As you can see chromium (or firefox) is much crisper than doc-view.


[-- Attachment #2: 0.jpg --]
[-- Type: image/jpeg, Size: 46745 bytes --]

[-- Attachment #3: Type: text/plain, Size: 49 bytes --]

emacs-version "25.2.2"
gnus-version "Gnus v5.13"

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

[Lars Ingebrigtsen]

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

> Here I have opened both chromium and emacs (lower frame),
> and zoomed one step, on a PDF.
>
> As you can see chromium (or firefox) is much crisper than doc-view.
>
> emacs-version "25.2.2"

I'm unable to reproduce this on the trunk -- PDFs (even after zooming)
look fine to me in doc-view.  Are you still seeing this?

-- 
(domestic pets only, the antidote for overdose, milk.)
   bloggy blog: http://lars.ingebrigtsen.no

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

[積丹尼 Dan Jacobson]

LI> I'm unable to reproduce this on the trunk -- PDFs (even after zooming)
LI> look fine to me in doc-view.  Are you still seeing this?

Try:
wget -O x.pdf https://www.ris.gov.tw/documents/data/2/4/4e050f2b-9778-4a7d-a764-241e43d659f1.pdf
chromium x.pdf # then zoom with the "+" button until 400%. (Yup 400
percent, or higher still.)

gv x.pdf # then zoom to "10.00", the maximum.

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.

(info "(emacs) DocView Navigation") says
   You can enlarge or shrink the document with ‘+’ (‘doc-view-enlarge’)
   and ‘-’ (‘doc-view-shrink’).  These commands work by reconverting the
   document at the new size.  To specify the default size for DocView,
   customize the variable ‘doc-view-resolution’.

doc-view-resolution is a variable defined in ‘doc-view.el’.
Its value is 100

    Documentation:
    Dots per inch resolution used to render the documents.
    Higher values result in larger images.

g runs the command doc-view-revert-buffer
but it doesn't make the enlarged document clearer.

One needs to set doc-view-resolution higher before opening the file.

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

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.

Or, how about instead of failing, simply do the nil action if the t action fails!

By the way, when it is nil, one sees
DocView: process pdf/ps->png changed status to killed.
messages each time one hits "+".

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.

emacs-version "26.1"

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

[Tassilo Horn]

積丹尼 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

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

[Lars Ingebrigtsen]

Tassilo Horn <tsdh@gnu.org> writes:

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

I've now done so, and I don't think there's anything else to fix in this
bug report, so I'm closing it.

-- 
(domestic pets only, the antidote for overdose, milk.)
   bloggy blog: http://lars.ingebrigtsen.no