* bug#33226: chromium, firefox sharper than doc-view @ 2018-11-01 14:23 積丹尼 Dan Jacobson 2019-07-10 13:39 ` Lars Ingebrigtsen 0 siblings, 1 reply; 5+ messages in thread From: 積丹尼 Dan Jacobson @ 2018-11-01 14:23 UTC (permalink / raw) To: 33226; +Cc: tsdh [-- 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" ^ permalink raw reply [flat|nested] 5+ messages in thread
* bug#33226: chromium, firefox sharper than doc-view 2018-11-01 14:23 bug#33226: chromium, firefox sharper than doc-view 積丹尼 Dan Jacobson @ 2019-07-10 13:39 ` Lars Ingebrigtsen 2019-07-14 12:01 ` 積丹尼 Dan Jacobson 0 siblings, 1 reply; 5+ messages in thread From: Lars Ingebrigtsen @ 2019-07-10 13:39 UTC (permalink / raw) To: 積丹尼 Dan Jacobson; +Cc: 33226, tsdh 積丹尼 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 ^ permalink raw reply [flat|nested] 5+ messages in thread
* bug#33226: chromium, firefox sharper than doc-view 2019-07-10 13:39 ` Lars Ingebrigtsen @ 2019-07-14 12:01 ` 積丹尼 Dan Jacobson 2019-08-02 16:38 ` Tassilo Horn 0 siblings, 1 reply; 5+ messages in thread From: 積丹尼 Dan Jacobson @ 2019-07-14 12:01 UTC (permalink / raw) To: Lars Ingebrigtsen; +Cc: 33226, tsdh 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" ^ permalink raw reply [flat|nested] 5+ messages in thread
* bug#33226: chromium, firefox sharper than doc-view 2019-07-14 12:01 ` 積丹尼 Dan Jacobson @ 2019-08-02 16:38 ` Tassilo Horn 2019-09-27 16:21 ` Lars Ingebrigtsen 0 siblings, 1 reply; 5+ messages in thread From: Tassilo Horn @ 2019-08-02 16:38 UTC (permalink / raw) To: 積丹尼 Dan Jacobson; +Cc: Lars Ingebrigtsen, 33226 積丹尼 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 ^ permalink raw reply [flat|nested] 5+ messages in thread
* bug#33226: chromium, firefox sharper than doc-view 2019-08-02 16:38 ` Tassilo Horn @ 2019-09-27 16:21 ` Lars Ingebrigtsen 0 siblings, 0 replies; 5+ messages in thread From: Lars Ingebrigtsen @ 2019-09-27 16:21 UTC (permalink / raw) To: Tassilo Horn; +Cc: 33226, 積丹尼 Dan Jacobson 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 ^ permalink raw reply [flat|nested] 5+ messages in thread
end of thread, other threads:[~2019-09-27 16:21 UTC | newest] Thread overview: 5+ messages (download: mbox.gz follow: Atom feed -- links below jump to the message on this page -- 2018-11-01 14:23 bug#33226: chromium, firefox sharper than doc-view 積丹尼 Dan Jacobson 2019-07-10 13:39 ` Lars Ingebrigtsen 2019-07-14 12:01 ` 積丹尼 Dan Jacobson 2019-08-02 16:38 ` Tassilo Horn 2019-09-27 16:21 ` Lars Ingebrigtsen
Code repositories for project(s) associated with this external index https://git.savannah.gnu.org/cgit/emacs.git https://git.savannah.gnu.org/cgit/emacs/org-mode.git This is an external index of several public inboxes, see mirroring instructions on how to clone and mirror all data and code used by this external index.