unofficial mirror of bug-gnu-emacs@gnu.org 
 help / color / mirror / code / Atom feed
From: Po Lu via "Bug reports for GNU Emacs, the Swiss army knife of text editors" <bug-gnu-emacs@gnu.org>
To: Stefan Kangas <stefankangas@gmail.com>
Cc: 66308@debbugs.gnu.org, Tassilo Horn <tsdh@gnu.org>
Subject: bug#66308: 30.0.50; DocView: Bump default value of doc-view-resolution
Date: Tue, 03 Oct 2023 16:49:07 +0800	[thread overview]
Message-ID: <87wmw4jdks.fsf@yahoo.com> (raw)
In-Reply-To: <CADwFkmmzC6X9Khf_iu5=yYmK87LStsB94KRAFeyA=zsE26xa4A@mail.gmail.com> (Stefan Kangas's message of "Mon, 2 Oct 2023 07:55:47 -0700")

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.





  reply	other threads:[~2023-10-03  8:49 UTC|newest]

Thread overview: 9+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2023-10-02 14:55 bug#66308: 30.0.50; DocView: Bump default value of doc-view-resolution Stefan Kangas
2023-10-03  8:49 ` Po Lu via Bug reports for GNU Emacs, the Swiss army knife of text editors [this message]
2023-10-03  9:28   ` Stefan Kangas
2023-10-03 10:19   ` Björn Bidar via Bug reports for GNU Emacs, the Swiss army knife of text editors
2023-10-03 10:34     ` Po Lu via Bug reports for GNU Emacs, the Swiss army knife of text editors
2023-10-03 16:11       ` Eli Zaretskii
2023-10-03 12:03     ` Stefan Kangas
2023-10-04  8:37       ` Björn Bidar via Bug reports for GNU Emacs, the Swiss army knife of text editors
2023-10-05 10:24         ` Richard Stallman

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

  List information: https://www.gnu.org/software/emacs/

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=87wmw4jdks.fsf@yahoo.com \
    --to=bug-gnu-emacs@gnu.org \
    --cc=66308@debbugs.gnu.org \
    --cc=luangruo@yahoo.com \
    --cc=stefankangas@gmail.com \
    --cc=tsdh@gnu.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
Code repositories for project(s) associated with this public inbox

	https://git.savannah.gnu.org/cgit/emacs.git

This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).