Ikumi: 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? https://lists.gnu.org/archive/html/auctex/2016-05/msg00021.html). So I came up with a workaround on the Aquamacs side, such as this pull request, which seems related to the discussion about updating preview.el.in. https://github.com/aquamacs-emacs/aquamacs-emacs/pull/208 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. Michael On Jun 15, 2022, at 11:47 AM, Ikumi Keita <[email protected]<mailto:[email protected]>> wrote: [EXTERNAL SENDER] Hi Tassilo, Tassilo Horn <[email protected]<mailto:[email protected]>> writes: Grzegorz Kowzan <[email protected]<mailto:[email protected]>> 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 preview.el.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. Best, Ikumi Keita #StandWithUkraine #StopWarInUkraine [1] https://debbugs.gnu.org/cgi/bugreport.cgi?bug=20171
