auctex-devel
[Top][All Lists]
Advanced

[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: Ikumi Keita
Subject: Re: bug#45596: 12.2.4; Wrong DPI calculation for mixed-DPI multi-monitor setups
Date: Sun, 26 Jun 2022 18:35:28 +0900

Hi Tassilo, can I expect you to take care of this issue?

(And in addition to bug#20171, I hope bug#25002 and bug#27213 can be
closed as well:
https://debbugs.gnu.org/cgi/bugreport.cgi?bug=25002
https://debbugs.gnu.org/cgi/bugreport.cgi?bug=27213
)

Regards,
Ikumi Keita
#StandWithUkraine #StopWarInUkraine

>>>>> Ikumi Keita <ikumi@ikumi.que.jp> writes:
>>>>> Tassilo Horn <tsdh@gnu.org> writes:
>> Grzegorz Kowzan <grzegorz@kowzan.eu> 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



reply via email to

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