GNU bug report logs - #66308
30.0.50; DocView: Bump default value of doc-view-resolution

Previous Next

To reply to this bug, email your comments to 66308 AT debbugs.gnu.org.

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

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

From: Stefan Kangas <stefankangas <at> gmail.com>
To: bug-gnu-emacs <at> gnu.org
Subject: 30.0.50; DocView: Bump default value of doc-view-resolution
Date: Mon, 2 Oct 2023 07:55:47 -0700

Severity: wishlist

How about increasing the default value of `doc-view-resolution' from 100
to something like 300?  In my use, I find that the default value gives
poor results, especially after `doc-view-enlarge', whereas a value of
300 gives a nice, crisp display.  Monitors these days are certainly much
larger, and have much higher resolutions, than they used to.

People in highly restricted environments might have to turn it back down
again, of course.  I think this is okay though, if the benefit is that
doc-view will look better in more typical cases.

I also note that `doc-view-resolution' has had the same value since
2007, when DocView mode was first added to Emacs.  After 15-20 years, it
might be time for a bump.

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

From: Po Lu <luangruo <at> yahoo.com>
To: Stefan Kangas <stefankangas <at> gmail.com>
Cc: 66308 <at> debbugs.gnu.org, Tassilo Horn <tsdh <at> gnu.org>
Subject: Re: bug#66308: 30.0.50; DocView: Bump default value of
 doc-view-resolution
Date: Tue, 03 Oct 2023 16:49:07 +0800

Stefan Kangas <stefankangas <at> gmail.com> writes:

> How about increasing the default value of `doc-view-resolution' from 100
> to something like 300?  In my use, I find that the default value gives
> poor results, especially after `doc-view-enlarge', whereas a value of
> 300 gives a nice, crisp display.  Monitors these days are certainly much
> larger, and have much higher resolutions, than they used to.
>
> People in highly restricted environments might have to turn it back down
> again, of course.  I think this is okay though, if the benefit is that
> doc-view will look better in more typical cases.
>
> I also note that `doc-view-resolution' has had the same value since
> 2007, when DocView mode was first added to Emacs.  After 15-20 years, it
> might be time for a bump.

How about making the resolution commensurate with that of the display
itself?  Monitor density has not increased for lay folk, only those
willing to spend prodigally on display hardware.

Compounding that, larger images will consume greater quantities of disk
space and X server memory.  Bear in mind that /tmp is customarily small;
only 4 GiB on my system, with 1.8GiB in use, whereof /tmp/docview1000
consumes 971 MiB.

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

From: Stefan Kangas <stefankangas <at> gmail.com>
To: Po Lu <luangruo <at> yahoo.com>
Cc: 66308 <at> debbugs.gnu.org, Tassilo Horn <tsdh <at> gnu.org>
Subject: Re: bug#66308: 30.0.50;
 DocView: Bump default value of doc-view-resolution
Date: Tue, 3 Oct 2023 02:28:59 -0700

Po Lu <luangruo <at> yahoo.com> writes:

> How about making the resolution commensurate with that of the display
> itself?  Monitor density has not increased for lay folk, only those
> willing to spend prodigally on display hardware.

Yes, if we can make it dynamic, that should be even better.

Do we have a canonical way of checking the resolution of the screen that
the current frame is on?

> Compounding that, larger images will consume greater quantities of disk
> space and X server memory.  Bear in mind that /tmp is customarily small;
> only 4 GiB on my system, with 1.8GiB in use, whereof /tmp/docview1000
> consumes 971 MiB.

That's an important consideration.  We have the `doc-view-clear-cache'
command, but perhaps we could do more, for example

a) a separate command to display the cache size, or
b) a warning when the cache size reaches some threshold, or
c) automatically cleaning up old files when the cache reaches some
   threshold,

or some combination of all of the above.

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

From: Björn Bidar <bjorn.bidar <at> thaodan.de>
To: Po Lu via "Bug reports for GNU Emacs, the Swiss army knife of text
 editors" <bug-gnu-emacs <at> gnu.org>
Cc: Po Lu <luangruo <at> yahoo.com>, 66308 <at> debbugs.gnu.org,
 Stefan Kangas <stefankangas <at> gmail.com>, Tassilo Horn <tsdh <at> gnu.org>
Subject: Re: bug#66308: 30.0.50; DocView: Bump default value of
 doc-view-resolution
Date: Tue, 03 Oct 2023 13:19:04 +0300

Po Lu via "Bug reports for GNU Emacs, the Swiss army knife of text
editors" <bug-gnu-emacs <at> gnu.org> writes:

> Stefan Kangas <stefankangas <at> gmail.com> writes:
>
>> How about increasing the default value of `doc-view-resolution' from 100
>> to something like 300?  In my use, I find that the default value gives
>> poor results, especially after `doc-view-enlarge', whereas a value of
>> 300 gives a nice, crisp display.  Monitors these days are certainly much
>> larger, and have much higher resolutions, than they used to.
>>
>> People in highly restricted environments might have to turn it back down
>> again, of course.  I think this is okay though, if the benefit is that
>> doc-view will look better in more typical cases.
>>
>> I also note that `doc-view-resolution' has had the same value since
>> 2007, when DocView mode was first added to Emacs.  After 15-20 years, it
>> might be time for a bump.
>
> How about making the resolution commensurate with that of the display
> itself?  Monitor density has not increased for lay folk, only those
> willing to spend prodigally on display hardware.

Would it make sense to set the resolution based on the resolution and
the dpi? Or how is scaling involved here?

> Compounding that, larger images will consume greater quantities of disk
> space and X server memory.  Bear in mind that /tmp is customarily small;
> only 4 GiB on my system, with 1.8GiB in use, whereof /tmp/docview1000
> consumes 971 MiB.

Should we store this data on Unixes in `$XDG_CACHE_HOME` Instead
of temp?
Doing so would also allow to reuse it if the particular file is viewed
again.

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

From: Po Lu <luangruo <at> yahoo.com>
To: Björn Bidar <bjorn.bidar <at> thaodan.de>
Cc: 66308 <at> debbugs.gnu.org, Stefan Kangas <stefankangas <at> gmail.com>,
 Tassilo Horn <tsdh <at> gnu.org>
Subject: Re: bug#66308: 30.0.50; DocView: Bump default value of
 doc-view-resolution
Date: Tue, 03 Oct 2023 18:34:25 +0800

Björn Bidar <bjorn.bidar <at> thaodan.de> writes:

> Would it make sense to set the resolution based on the resolution and
> the dpi? Or how is scaling involved here?

Just the display scale: dpyinfo->resx / PT_PER_INCH (in font.h), so long
as the consequent scale doesn't incur an unacceptable increase to disk
usage.

> Should we store this data on Unixes in `$XDG_CACHE_HOME` Instead
> of temp?

Unix systems don't all provide XDG directories, and furthermore, storage
considerations remain relevant there.

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

From: Stefan Kangas <stefankangas <at> gmail.com>
To: Björn Bidar <bjorn.bidar <at> thaodan.de>
Cc: Po Lu <luangruo <at> yahoo.com>, 66308 <at> debbugs.gnu.org,
 Tassilo Horn <tsdh <at> gnu.org>
Subject: Re: bug#66308: 30.0.50;
 DocView: Bump default value of doc-view-resolution
Date: Tue, 3 Oct 2023 05:03:30 -0700

Björn Bidar <bjorn.bidar <at> thaodan.de> writes:

> Should we store this data on Unixes in `$XDG_CACHE_HOME` Instead
> of temp?
> Doing so would also allow to reuse it if the particular file is viewed
> again.

Probably, yes, at least on XDG compliant systems.

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

From: Eli Zaretskii <eliz <at> gnu.org>
To: Po Lu <luangruo <at> yahoo.com>
Cc: 66308 <at> debbugs.gnu.org, bjorn.bidar <at> thaodan.de, stefankangas <at> gmail.com,
 tsdh <at> gnu.org
Subject: Re: bug#66308: 30.0.50;
 DocView: Bump default value of doc-view-resolution
Date: Tue, 03 Oct 2023 19:11:52 +0300

> Cc: 66308 <at> debbugs.gnu.org, Stefan Kangas <stefankangas <at> gmail.com>,
>  Tassilo Horn <tsdh <at> gnu.org>
> Date: Tue, 03 Oct 2023 18:34:25 +0800
> From:  Po Lu via "Bug reports for GNU Emacs,
>  the Swiss army knife of text editors" <bug-gnu-emacs <at> gnu.org>
> 
> > Should we store this data on Unixes in `$XDG_CACHE_HOME` Instead
> > of temp?
> 
> Unix systems don't all provide XDG directories, and furthermore, storage
> considerations remain relevant there.

We have the file-system-info function, which we could use to determine
how much storage is available.

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

From: Björn Bidar <bjorn.bidar <at> thaodan.de>
To: Stefan Kangas <stefankangas <at> gmail.com>
Cc: Po Lu <luangruo <at> yahoo.com>, 66308 <at> debbugs.gnu.org,
 Tassilo Horn <tsdh <at> gnu.org>
Subject: Re: bug#66308: 30.0.50; DocView: Bump default value of
 doc-view-resolution
Date: Wed, 04 Oct 2023 11:37:48 +0300

Stefan Kangas <stefankangas <at> gmail.com> writes:

> Björn Bidar <bjorn.bidar <at> thaodan.de> writes:
>
>> Should we store this data on Unixes in `$XDG_CACHE_HOME` Instead
>> of temp?
>> Doing so would also allow to reuse it if the particular file is viewed
>> again.
>
> Probably, yes, at least on XDG compliant systems.

So e.g. Linux or *BSD.

On MacOS or Windows there are similar locations.

The Qt StandardPaths Docs provide a good overview of those:
https://doc.qt.io/qt-5/qstandardpaths.html#StandardLocation-enum

E.g. on MacOS there is ~/Library/Caches/<APPNAME> for CacheLocation.

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

From: Richard Stallman <rms <at> gnu.org>
To: Björn Bidar <bjorn.bidar <at> thaodan.de>
Cc: luangruo <at> yahoo.com, 66308 <at> debbugs.gnu.org, stefankangas <at> gmail.com,
 tsdh <at> gnu.org
Subject: Re: bug#66308: 30.0.50;
 DocView: Bump default value of doc-view-resolution
Date: Thu, 05 Oct 2023 06:24:12 -0400

[[[ To any NSA and FBI agents reading my email: please consider    ]]]
[[[ whether defending the US Constitution against all enemies,     ]]]
[[[ foreign or domestic, requires you to follow Snowden's example. ]]]

  > >> Should we store this data on Unixes in `$XDG_CACHE_HOME` Instead
  > >> of temp?
  > >> Doing so would also allow to reuse it if the particular file is viewed
  > >> again.
  > >
  > > Probably, yes, at least on XDG compliant systems.

  > So e.g. Linux or *BSD.

[This is a side issue, but please be aware of it]

The first of those is actually the GNU system, which is
what I developed GNU Emacs to be part of.  Linux is what
it uses as the kernel.

See https://gnu.org/gnu/linux-and-gnu.html and
https://gnu.org/gnu/gnu-linux-faq.html, plus the history in
https://gnu.org/gnu/the-gnu-project.html.


-- 
Dr Richard Stallman (https://stallman.org)
Chief GNUisance of the GNU Project (https://gnu.org)
Founder, Free Software Foundation (https://fsf.org)
Internet Hall-of-Famer (https://internethalloffame.org)

Previous Next

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