From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.io!.POSTED.blaine.gmane.org!not-for-mail From: Po Lu via "Bug reports for GNU Emacs, the Swiss army knife of text editors" Newsgroups: gmane.emacs.bugs Subject: bug#59080: 29.0.50; preview-get-dpi produces surprising result on vertical monitor Date: Mon, 07 Nov 2022 09:30:16 +0800 Message-ID: <87r0yf8sbb.fsf@yahoo.com> References: <87mt94aylx.fsf@hyperspace> Reply-To: Po Lu Mime-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Injection-Info: ciao.gmane.io; posting-host="blaine.gmane.org:116.202.254.214"; logging-data="14076"; mail-complaints-to="usenet@ciao.gmane.io" User-Agent: Gnus/5.13 (Gnus v5.13) Cc: 59080@debbugs.gnu.org To: Tony Zorman Original-X-From: bug-gnu-emacs-bounces+geb-bug-gnu-emacs=m.gmane-mx.org@gnu.org Mon Nov 07 02:31:30 2022 Return-path: Envelope-to: geb-bug-gnu-emacs@m.gmane-mx.org Original-Received: from lists.gnu.org ([209.51.188.17]) by ciao.gmane.io with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.92) (envelope-from ) id 1orqz4-0003So-7s for geb-bug-gnu-emacs@m.gmane-mx.org; Mon, 07 Nov 2022 02:31:30 +0100 Original-Received: from localhost ([::1] helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1orqyd-000498-UZ; Sun, 06 Nov 2022 20:31:03 -0500 Original-Received: from eggs.gnu.org ([2001:470:142:3::10]) by lists.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1orqyc-00048m-Il for bug-gnu-emacs@gnu.org; Sun, 06 Nov 2022 20:31:02 -0500 Original-Received: from debbugs.gnu.org ([209.51.188.43]) by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_128_GCM_SHA256:128) (Exim 4.90_1) (envelope-from ) id 1orqyc-0001X3-Ag for bug-gnu-emacs@gnu.org; Sun, 06 Nov 2022 20:31:02 -0500 Original-Received: from Debian-debbugs by debbugs.gnu.org with local (Exim 4.84_2) (envelope-from ) id 1orqyb-0008HB-Pf for bug-gnu-emacs@gnu.org; Sun, 06 Nov 2022 20:31:01 -0500 X-Loop: help-debbugs@gnu.org Resent-From: Po Lu Original-Sender: "Debbugs-submit" Resent-CC: bug-gnu-emacs@gnu.org Resent-Date: Mon, 07 Nov 2022 01:31:01 +0000 Resent-Message-ID: Resent-Sender: help-debbugs@gnu.org X-GNU-PR-Message: followup 59080 X-GNU-PR-Package: emacs Original-Received: via spool by 59080-submit@debbugs.gnu.org id=B59080.166778463431774 (code B ref 59080); Mon, 07 Nov 2022 01:31:01 +0000 Original-Received: (at 59080) by debbugs.gnu.org; 7 Nov 2022 01:30:34 +0000 Original-Received: from localhost ([127.0.0.1]:60958 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1orqy9-0008GQ-GL for submit@debbugs.gnu.org; Sun, 06 Nov 2022 20:30:33 -0500 Original-Received: from sonic313-10.consmr.mail.ne1.yahoo.com ([66.163.185.33]:41389) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1orqy7-0008GA-1K for 59080@debbugs.gnu.org; Sun, 06 Nov 2022 20:30:32 -0500 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.com; s=s2048; t=1667784623; bh=ydmU2yPVuX13LNcuJTNMV65jbSwz//GCF1Xl12f20Hs=; h=From:To:Cc:Subject:In-Reply-To:References:Date:From:Subject:Reply-To; b=LZSvNi/MVlIqerTScBnXsO8SZtIARjsdpl27DgaU4u4K7hb4lumhBkslYXe9yful27+trUFDLUWTp3JqbmIwy2XkT7HdKYv3/abr1L2yOB3HZiUieiI7QO+E/NvZ/lZLsR7b0TdljubZ/Xi0pTPPBnLuggXCaAVgnYSZgXJuIWpV302SoXVXoakuc/9HN5dnTSx6VlS1Jt4w1xbm+PERHjiOfPUD2UGAHCW/E2mOgcodvjg6oBJVxlexN5aJ8hP13J02tAz6FOuHGbcOWM5WteTHCjm+MUWarm1t+alOvig/P1PWEDSnVDsafxAXI6mQOPQZNwkRYl+oTW9QUExzhQ== X-SONIC-DKIM-SIGN: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.com; s=s2048; t=1667784623; bh=xTluJT+pFdVe/2dqm2w6/WhpB5CdwJiRcFr23c15HtQ=; h=X-Sonic-MF:From:To:Subject:Date:From:Subject; b=qOlJe2VDmSHm3wL2GEK2papIZ4cExsREckZ33UlvzAxh8MySJPL9dDkqXf3Vp+4OUwdBSqNafm2JEVxos6K20PnqWTFoJwoEoxsQyG+cEluPP2qqCO0e5B74gK/6ONWzFHEUsD62Gb2VdOHjEoXwHHHqHKtiuZBVWaJYHc30WQUfSodQHAjxgiLiwh96Wa2GaNjypz94HflHYpLb7XG2RImdA7ouCIPVffA8vYPQ2EPrkTmYLn9S0Nsfb9iLgMf34HfCPO1jz+g0FOY7F8Pg1VudpiQMiltO66UzFE3/ZGPtGzdutGf/pm/kpF9fsmE0axy4Kg/mKczhExlYYOGHFw== X-YMail-OSG: pYK.aooVM1nd9gEcSDOtup5syD1IPPhf1Y5KVbPTx7Tf_dsq9sXkqHFeSzJNy86 _3jgOCByE8emW79So_lU91erZl7jTPuFWE3ZzCVjTUEEHC7fbhvgEVg3UuIZ1K6r3B2AbSpHge_G ye3QSw8SQml2Cotp4UO3M7aXlx9OFkb5XUCE7qj0Ybp_3BaSO3mvw2kn0Xkacb2_mgPZPcrbp3bM LBe5Nh2JILA63PY9rFqguzzxyW29l7vbyVY15GDJWUejvMoq.dlUuBLBv2PDtdBf1ET5Vkznsf9J UQFI8yPu7tyqobbLgBL6pGFw.jibsWD7Pi_AA8EBxmx3wcmIUuHDc4tSVyaxwj_lR4KwORX.B0Z8 HfnyD.JPsRrRUsyw.LO0PzaohItgJr4BhQnAl0Gq_TJ7k5vNdQpGlXh6j2O4wV8x7818ZnwsFY69 6BsfsZKc1YIT8S4VMePLrGD8pFo_x5weyyGJd_5wNT.n2S0IG.TVI420AZEUJ05uD7oJiV7taaVF usmn7yHpmfFGNM3HmjA6EjT7i8hS6BUTgY9xwak6DeBcZYoag.2qcdwwQ08M2MWRGfKeQxhkcIOG la3wFHLMIVYeMEZBmGfCvhbtWuFg2P39HCAAtxXe0Gb_zuyKUTEW2J7JXGs0f7a5Mq9jDsQORpda ugMgFnhB1BVOr_aHYixaExgAInQBbGqOdSO9dFymuX.sgv48JS9kRfGsTXhZna6crmESYNBmPH__ 79N8HxyqJFQVEYxV4UPEzmXHu95LgjmNRuPdpp5vX8yzPr.5N.lVCH6ClljlzQdctHCRoAHUALMG V3r01Z9wxlRPRkmFMMBOK5ZyTRC5krUnWM.4VngMuQ X-Sonic-MF: Original-Received: from sonic.gate.mail.ne1.yahoo.com by sonic313.consmr.mail.ne1.yahoo.com with HTTP; Mon, 7 Nov 2022 01:30:23 +0000 Original-Received: by hermes--production-sg3-6c8895b545-26lc9 (Yahoo Inc. Hermes SMTP Server) with ESMTPA ID c247f06c0eb9bc47850c694bb809be2b; Mon, 07 Nov 2022 01:30:21 +0000 (UTC) In-Reply-To: <87mt94aylx.fsf@hyperspace> (Tony Zorman's message of "Sun, 06 Nov 2022 16:31:22 +0100") X-Mailer: WebService/1.1.20826 mail.backend.jedi.jws.acl:role.jedi.acl.token.atz.jws.hermes.yahoo X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list X-BeenThere: bug-gnu-emacs@gnu.org List-Id: "Bug reports for GNU Emacs, the Swiss army knife of text editors" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: bug-gnu-emacs-bounces+geb-bug-gnu-emacs=m.gmane-mx.org@gnu.org Original-Sender: bug-gnu-emacs-bounces+geb-bug-gnu-emacs=m.gmane-mx.org@gnu.org Xref: news.gmane.io gmane.emacs.bugs:247248 Archived-At: Tony Zorman writes: > Hi, > > tl;dr: the `preview-get-dpi' function compares the wrong values for > horizontal monitors (i.e., ones that are flipped by 90/270 degrees). > > When previewing LaTeX fragments via AUCTeX's `preview.el' library, > things get quite messed up when one or more monitors are set up in > "portrait mode". I have attached three images that show this; bug1.png > shows a rendered equation for two vertical monitors, bug2.png for a > single one, and horiz.png displays that same equation being rendered on > a horizontal monitor (i.e., this is the expected result). > > Looking into `preview.el', it seems like that `preview-get-dpi' (called > by `preview-get-geometry', which is in turn called by > `preview-generate-preview') calculates the wrong "resolution". The > relevant implementation is > > (defun preview-get-dpi () > (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 (cl-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)))) > > An example output of `frame-monitor-attributes' for a horizontal > monitor: > > '((name . "DP1") > (geometry 0 0 1920 1080) > (workarea 0 0 1920 1080) > (mm-size 530 300) > (frames <>) > (source . "XRandR 1.5")) > > The same monitor in "vertical-mode" returns: > > '((name . "DP1") > (geometry 0 0 1080 1920) > (workarea 0 0 1080 1920) > (mm-size 530 300) > (frames <>) > (source . "XRandR 1.5")) > > Crucially, the returned physical width and height of the monitor don't > change, but the geometry=E2=80=94what will be the pixel width and height= =E2=80=94does. > However, turning the monitor by 90 degrees obviously switches the > physical width an height around as well, although that perhaps can't be > reported property. In such a situation, we actually compare the pixel > _width_ of the monitor with its physical _height_, as well as its pixel > height with its width. Naturally, and depending on the specific setup, > this produces too narrow or too wide previews. > > I have fixed this locally by only comparing comparable values; i.e., > instead of > > (cons (/ (* 25.4 pixel-width) mm-width) > (/ (* 25.4 pixel-height) mm-height)) > > I wrote something like > > (cons (/ (* 25.4 (max pixel-width pixel-height)) (max mm-width mm-hei= ght)) > (/ (* 25.4 (min pixel-width pixel-height)) (min mm-width mm-hei= ght))) > > This fixed the problem for me, but I don't know if there is some > situation (or strange resolution) in which it would be correct to > compare some other combination of values. > > Hopefully this was comprehensible. If not, feel free to ask for more > information. > > Best, > Tony Thanks. The problem here is under version 1.5 of the RandR extension, monitors can have multiple outputs attached to multiple CRTCs, each with its own transform. So the X server has to stretch itself very hard to calculate the actual width and height of the monitor area. I suggest filing a bug under xorgproto asking to clarify how the physical width and height of a monitor can be reconciled with the transforms of each of its outputs CRT controllers. Under version 1.3 of the extension, Emacs should flip the physical monitor width and height itself. Unfortunately, version 1.3 is obsolete and does not really take modern features (such as outputs that do not display desktop contents) into account.