GNU bug report logs - #33226
chromium, firefox sharper than doc-view

Previous Next

To add a comment to this bug, you must first unarchive it, by sending
a message to control AT debbugs.gnu.org, with unarchive 33226 in the body.
You can then email your comments to 33226 AT debbugs.gnu.org in the normal way.

Toggle the display of automated, internal messages from the tracker.

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

From: 積丹尼 Dan Jacobson <jidanni <at> jidanni.org>
To: bug-gnu-emacs <at> gnu.org
Cc: tsdh <at> gnu.org
Subject: chromium, firefox sharper than doc-view
Date: Thu, 01 Nov 2018 22:23:39 +0800

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

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.

[0.jpg (image/jpeg, attachment)]

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

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

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

From: Lars Ingebrigtsen <larsi <at> gnus.org>
To: 積丹尼 Dan Jacobson <jidanni <at> jidanni.org>
Cc: 33226 <at> debbugs.gnu.org, tsdh <at> gnu.org
Subject: Re: bug#33226: chromium, firefox sharper than doc-view
Date: Wed, 10 Jul 2019 15:39:29 +0200

積丹尼 Dan Jacobson <jidanni <at> 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

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

From: 積丹尼 Dan Jacobson <jidanni <at> jidanni.org>
To: Lars Ingebrigtsen <larsi <at> gnus.org>
Cc: 33226 <at> debbugs.gnu.org, tsdh <at> gnu.org
Subject: Re: bug#33226: chromium, firefox sharper than doc-view
Date: Sun, 14 Jul 2019 20:01:23 +0800

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"

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

From: Tassilo Horn <tsdh <at> gnu.org>
To: 積丹尼 Dan Jacobson <jidanni <at> jidanni.org>
Cc: Lars Ingebrigtsen <larsi <at> gnus.org>, 33226 <at> debbugs.gnu.org
Subject: Re: bug#33226: chromium, firefox sharper than doc-view
Date: Fri, 02 Aug 2019 18:38:32 +0200

積丹尼 Dan Jacobson <jidanni <at> 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

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

From: Lars Ingebrigtsen <larsi <at> gnus.org>
To: Tassilo Horn <tsdh <at> gnu.org>
Cc: 33226 <at> debbugs.gnu.org,
 積丹尼 Dan Jacobson <jidanni <at> jidanni.org>
Subject: Re: bug#33226: chromium, firefox sharper than doc-view
Date: Fri, 27 Sep 2019 18:21:48 +0200

Tassilo Horn <tsdh <at> 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

Previous Next

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