bug-auctex
[Top][All Lists]
Advanced

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

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


From: Grzegorz Kowzan
Subject: bug#45596: 12.2.4; Wrong DPI calculation for mixed-DPI multi-monitor setups
Date: Mon, 04 Jan 2021 18:29:25 +0100
User-agent: mu4e 1.4.10; emacs 28.0.50

Hi, Tassilo,

On nie 03 sty 2021 at 10:55, Tassilo Horn <tsdh@gnu.org> wrote:
> I get very different values with the old and new calculation on my
> current single laptop screen setup
>
>   ((131.09677419354838 . 134.47058823529412) ;; New
>    (96.07565011820331 . 96.05042016806723))  ;; Old
>
> so that by using your version, the previews are much larger than they
> used to be, i.e., their font size appears to be much larger than my
> normal editing font.  This is with a current Emacs 28 (master branch,
> i.e., no pgtk) on a Wayland display.
>
> Could you please look into where this huge difference comes from?  Here
> is what `frame-monitor-attributes' and `display-mm-width' /
> `display-mm-height' return here:
>
> --8<---------------cut here---------------start------------->8---
> (frame-monitor-attributes)
> ;=> ((name . "XWAYLAND0")
>      (geometry 0 0 1600 900)
>      (workarea 0 0 1600 900)
>      (mm-size 310 170)
>      (frames #<frame  *Minibuf-1* - GNU Emacs at thinkpad-t440p 
> 0x5607eeb922f8> #<frame  0x5607eecefeb8> #<frame  0x5607f1829590>)
>      (source . "Gdk"))
>
> (display-mm-width)
> ;=> 423
>
> (display-mm-height)
> ;=> 238
> --8<---------------cut here---------------end--------------->8---
>
> 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...

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

2) I don't know how it is for you and other auctex users or developers, but for 
me auctex previews are too small and barely legible out of the box unless I 
manually set a scaling factor. (And then change it manually if I switch between 
different monitors...) Using standard auctex settings, preview-scale-function 
set to preview-scale-from-face, I get something like this for my 4k external 
monitor (https://ibb.co/7kJ39sb) and something like this for my laptop 
(https://ibb.co/VSfrcg4). With the definition above, I get more sensibly scaled 
previews without adjusting the scaling factor by hand, see 
(https://ibb.co/B4PHWvV) and (https://ibb.co/KjKX3Jk). These screenshots are 
all from current Emacs master X11/Gtk.

Best,
Grzegorz





reply via email to

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