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

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

[Stefan Kangas]

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.

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

[Po Lu via Bug reports for GNU Emacs, the Swiss army knife of text editors]

Stefan Kangas <stefankangas@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.

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

[Stefan Kangas]

Po Lu <luangruo@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.

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

[Björn Bidar via Bug reports for GNU Emacs, the Swiss army knife of text editors]

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

> Stefan Kangas <stefankangas@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.

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

[Po Lu via Bug reports for GNU Emacs, the Swiss army knife of text editors]

Björn Bidar <bjorn.bidar@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.

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

[Eli Zaretskii]

> Cc: 66308@debbugs.gnu.org, Stefan Kangas <stefankangas@gmail.com>,
>  Tassilo Horn <tsdh@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@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.

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

[Stefan Kangas]

Björn Bidar <bjorn.bidar@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.

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

[Björn Bidar via Bug reports for GNU Emacs, the Swiss army knife of text editors]

Stefan Kangas <stefankangas@gmail.com> writes:

> Björn Bidar <bjorn.bidar@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.

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

[Richard Stallman]

[[[ 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)