[Top][All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: bug#45596: 12.2.4; Wrong DPI calculation for mixed-DPI multi-monitor

From: Braun, Michael
Subject: Re: bug#45596: 12.2.4; Wrong DPI calculation for mixed-DPI multi-monitor setups
Date: Wed, 15 Jun 2022 17:59:03 +0000


I did not expect my two issues to intersect like this, but the discussion about frame dimensions and DPI seems relevant to an issue I had a couple of years ago. Preview-latex certainly has been working on Aquamacs (emacs 25), but not exactly perfectly.  I’m not much of a developer, but I thought you might find this experience of an Aquamacs end-user helpful.

The problem was that in Aquamacs, previews were not being generated with the correct aspect ratios and resolutions.  At the time it seemed like a Retina display problem, and a mailing list thread from 2016 indicated that Retina-specific issues would not be fixed on the AucTeX side because of GNU policies (it’s a long thread, but maybe start here?

So I came up with a workaround on the Aquamacs side, such as this pull request, which seems related to the discussion about updating

But none of that helped with preview resolution, either because 96 DPI was hard-coded in,  and/or because AucTeX was using the pixel dimensions both to determine the resolution of the image (as generated from Ghostscript), *and* to determine how big the image should be on the screen.  And the problem looks worse on Retina displays because even though my 15in MBP’s display is physically capable of 2880 x 1800, the maximum MacOS-allowed resolution was 1920 x 1200.  I work at 1680 x 1050, and 1680 is exactly what (display-pixel-width) returns.

As another workaround, I defined preview-scale-function with the following, so I can use the same .emacs on my desktop and laptop.

(defun mb-preview-scale ()
  (if (< (display-pixel-width) 2500) .8 1)

This was all back in 2020.  Since Aquamacs is in the process of being updated to Emacs 28, I put the issue off to the side (perhaps svg support would be an option?).  Maybe it’s time to revisit.


On Jun 15, 2022, at 11:47 AM, Ikumi Keita <> wrote:


Hi Tassilo,

Tassilo Horn <> writes:
Grzegorz Kowzan <> writes:
Hi Grzegorz,

I guess the problem is that mm-size in the `frame-monitor-attributes'
return value differs from `display-mm-height' and `display-mm-width'.

1) Yes, `display-pixel/mm-width/height` functions are defined in terms
of Xlib calls, whereas `frame-monitor-attributes` calls Gdk functions
(if Emacs was compiled with Gtk support) and only as a fallback it
calls Xlib. This is why we have this inconsistency. The standard DPI
for Xorg server is 96 regardless of the actual value, so for a given
resolution and assumed DPI Xorg gives fake mm width and
height. Essentially, the current calculation of DPI in auctex looks
pointless to me...

Ok, I see.

With pure Gtk port we get actual physical pixel width/height and
actual mm width/height, so I guess when auctex detects pgtk port, it
can either ignore these values and hardcode DPI of 96 or make use of
the actual DPI. I suppose there is something to be said for not
changing auctex's behaviour and hardcoding the value, but I would
prefer to use the actual DPI at least as an option (see below).

That's what I did.  Essentially I've applied your patch with an
additional fboundp check for `frame-monitor-attributes'.  If it's
available (24.4), then your variant is used, if not, the previous
variant basically always saying 96 DPI is used.

Isn't it a good time to carry out this TODO in ;-)
| (defun preview-get-dpi ()
|   ;; TODO: Remove false-case when required emacs version is bumped to
|   ;; 24.4 or newer as this is the version where
|   ;; `frame-monitor-attributes' has been introduced.
|   (if (fboundp 'frame-monitor-attributes)
|       (let* ((monitor-attrs (frame-monitor-attributes))
|              (mm-dims (cdr (assoc 'mm-size monitor-attrs)))
|              (mm-width (nth 0 mm-dims))
|              (mm-height (nth 1 mm-dims))
|              (pixel-dims (cdddr (assoc 'geometry monitor-attrs)))
|              (pixel-width (nth 0 pixel-dims))
|              (pixel-height (nth 1 pixel-dims)))
|         (cons (/ (* 25.4 pixel-width) mm-width)
|               (/ (* 25.4 pixel-height) mm-height)))
|     (cons (/ (* 25.4 (display-pixel-width))
|              (display-mm-width))
|           (/ (* 25.4 (display-pixel-height))
|              (display-mm-height)))))

And I'd like to comment on two minor aspects.
1. The function `cdddr' used above isn't yet available for emacs 25.1,
  so it should be replaced with `cl-cdddr'. I noticed this thanks to a
  byte compile log which Michael Braun sent me off list. Thank you,
  Michael! (And this means that preview-latex didn't work at all for
  emacs 25.1 for this 1.5 years!)

2. Though bug#20171[1] is still open, I hope it has already been
  resolved as well with this bug#45596. If so, let's close it, too.

Ikumi Keita
#StandWithUkraine #StopWarInUkraine


reply via email to

[Prev in Thread] Current Thread [Next in Thread]