From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.io!.POSTED.blaine.gmane.org!not-for-mail From: JD Smith Newsgroups: gmane.emacs.devel Subject: Re: SVG images confound position pixel measurements Date: Fri, 1 Dec 2023 09:11:56 -0500 Message-ID: References: <877clyb9q8.fsf@ledu-giraud.fr> Mime-Version: 1.0 (Mac OS X Mail 16.0 \(3774.200.91.1.1\)) Content-Type: multipart/alternative; boundary="Apple-Mail=_39410B18-29A7-4D22-AA25-A8412F42A80D" Injection-Info: ciao.gmane.io; posting-host="blaine.gmane.org:116.202.254.214"; logging-data="5459"; mail-complaints-to="usenet@ciao.gmane.io" Cc: emacs-devel@gnu.org To: Manuel Giraud Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane-mx.org@gnu.org Fri Dec 01 15:16:40 2023 Return-path: Envelope-to: ged-emacs-devel@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 1r94Js-0001C7-2e for ged-emacs-devel@m.gmane-mx.org; Fri, 01 Dec 2023 15:16:40 +0100 Original-Received: from localhost ([::1] helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1r94It-0006Go-Hp; Fri, 01 Dec 2023 09:15:39 -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 1r94Ip-0006GR-K9 for emacs-devel@gnu.org; Fri, 01 Dec 2023 09:15:35 -0500 Original-Received: from mail-io1-xd2e.google.com ([2607:f8b0:4864:20::d2e]) by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_128_GCM_SHA256:128) (Exim 4.90_1) (envelope-from ) id 1r94In-0004eW-7o for emacs-devel@gnu.org; Fri, 01 Dec 2023 09:15:35 -0500 Original-Received: by mail-io1-xd2e.google.com with SMTP id ca18e2360f4ac-7b3b819f8a3so63075239f.1 for ; Fri, 01 Dec 2023 06:15:32 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20230601; t=1701440131; x=1702044931; darn=gnu.org; h=references:to:cc:in-reply-to:date:subject:mime-version:message-id :from:from:to:cc:subject:date:message-id:reply-to; bh=ZVlHN1hSL1PUkbQkgqmERQUqni+kjUkZqGYbds+wtjk=; b=KVI64YntKTpP4kzFIzz93GQha4ho8RuuJTMvyLUurKBQCaEBtcKoeDe6ivpFiBfJnJ WFJdboWAl/MGtTZ5hHoWK0mdMiivwLyYVSKwVURlmyD2nWQ2IZRGUfLOo6bN2NXCIjtn IvlrrGcHDGIGXzpAO5zr62pNzDLhOPdYANP9FFKn6ivLx7JsPrmvjPixmFKKK72bGZ/w nudAHtIpmoVyp3I+lVTe5dArdZBnF1L5/Izh0k1yaNuqhYqjv4UKWiqZ2KcBPgJkbzm3 6p7kCroz5FVurDcDLtfJ4rYvke6pab9ZJEhMFlkvU39sINWNZUdTFAa+tXTqWaSFfBXY YDbw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1701440131; x=1702044931; h=references:to:cc:in-reply-to:date:subject:mime-version:message-id :from:x-gm-message-state:from:to:cc:subject:date:message-id:reply-to; bh=ZVlHN1hSL1PUkbQkgqmERQUqni+kjUkZqGYbds+wtjk=; b=jKFMpMrDBcSAdqdAcTBmcuDkRbbMHVz3sQAYBTeLYWXaj4qc9sV2MsQDGd/bMxl4+Z cuqt80rIVd0VK804iATvNE2QCk/9aaIHFksKIl3Vk8ZOW/idtOIaSOBAVBmwuzT4LO6y V+o1cqXkBB8h1sRFr7j42yycDp3BPRGLkyZ3MgZG1Fi4c0kGXkofRC+7hSE/SkGI0co7 YyxsqcAlk5iw6U1JHdJGpKq4g2nTnrRWkHgzRhbGbTqLfUmMQ3Tt0Qs5ePFKV3P89FHV xjWQVQkAO8tzYeXTTv9Vru4eqLiuMXguMidUldTDJ7vnrMahJcYrWIAbEetYodjKHf85 XS9A== X-Gm-Message-State: AOJu0Yx01maBYhS1uH1iyc6eCF9NOOF7U1ElybCzf6BNFbe/AJVKgIXD NDUf4NelVOle/zNJdsGjeN5Eb2zvRUM= X-Google-Smtp-Source: AGHT+IEA3tavOr46NvVch3S1pdzJmYtj+RSYIXFiatkuZ+DgyOeSPME0Oeuks5SSC8vY8iKpTjFz1A== X-Received: by 2002:a05:6602:810:b0:7a9:a9c6:d6b0 with SMTP id z16-20020a056602081000b007a9a9c6d6b0mr27192978iow.12.1701440130611; Fri, 01 Dec 2023 06:15:30 -0800 (PST) Original-Received: from smtpclient.apple (cm-24-53-187-34.buckeyecom.net. [24.53.187.34]) by smtp.gmail.com with ESMTPSA id r15-20020a02c84f000000b00466becb39b2sm889929jao.91.2023.12.01.06.15.29 (version=TLS1_2 cipher=ECDHE-ECDSA-AES128-GCM-SHA256 bits=128/128); Fri, 01 Dec 2023 06:15:30 -0800 (PST) In-Reply-To: <877clyb9q8.fsf@ledu-giraud.fr> X-Mailer: Apple Mail (2.3774.200.91.1.1) Received-SPF: pass client-ip=2607:f8b0:4864:20::d2e; envelope-from=jdtsmith@gmail.com; helo=mail-io1-xd2e.google.com X-Spam_score_int: -20 X-Spam_score: -2.1 X-Spam_bar: -- X-Spam_report: (-2.1 / 5.0 requ) BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, T_SCC_BODY_TEXT_LINE=-0.01 autolearn=ham autolearn_force=no X-Spam_action: no action X-BeenThere: emacs-devel@gnu.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "Emacs development discussions." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: emacs-devel-bounces+ged-emacs-devel=m.gmane-mx.org@gnu.org Original-Sender: emacs-devel-bounces+ged-emacs-devel=m.gmane-mx.org@gnu.org Xref: news.gmane.io gmane.emacs.devel:313440 Archived-At: --Apple-Mail=_39410B18-29A7-4D22-AA25-A8412F42A80D Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=utf-8 Thanks for checking this, Manuel. I=E2=80=99ve already filed a bug = report and Eli has found a fix, but unfortunately only for this very = specific case with line truncation. The general issue remains. We are = seeking a self-contained reproducer for the more general case in other = wrap modes (visual-line, normal wrapping). =20 Please see https://debbugs.gnu.org/cgi/bugreport.cgi?bug=3D67533 to = continue the discussion there. > On Dec 1, 2023, at 3:36=E2=80=AFAM, Manuel Giraud = wrote: >=20 > JD Smith > writes: >=20 >> In developing a new pixel-precise smooth scrolling mode, I=E2=80=99ve = noticed >> that inline SVG images confuse Emacs regarding pixel positions of >> surrounding elements. You sometimes also experience this while >> visiting SVG image-rich files (think org-latex-preview) while in >> visual line mode. In this case, previous/next-line sometimes jump >> from one side of the window to the other. >>=20 >> But it=E2=80=99s easiest to reproduce with line-truncation in effect. = Run the >> snippet below with your frame either expanded wide enough to >> accommodate the full width of the 1st line of text, or too narrow >> (eliciting truncation). While truly truncated and with point on the >> SVG, pixel text measurements above are erroneous (reporting zero = pixel >> height above), as if it thinks it=E2=80=99s on the prior line. At = other >> points in line 2, the pixel-size values are correct. >=20 > Hi, I can reproduce this on master. Below I modified your example > slightly and I also observe different pixel width for the same text > line. >=20 > I think you should file a bug report with this issue. Thanks. >=20 > --8<---------------cut here---------------start------------->8--- > ;;; test-svg-pixel-position --- test pixel position for SVG images >=20 > ;;; This small code creates a buffer with two lines, the first of > ;;; which is long, and the second of which has an SVG image at start. > ;;; Line truncation is turned on. `window-text-pixel-size` returns > ;;; differing results depending on whether truncation is actually in > ;;; effect (alter the frame width to see this). >=20 > ;;; Code: > (require 'svg) > (let ((buf "svg-pixel-demo") > (svg (svg-create 50 25))) > (svg-circle svg 25 25 25 :stroke-color "green") > (with-current-buffer (get-buffer-create buf) > (erase-buffer) > (insert "Pellentesque condimentum, magna ut suscipit hendrerit, = ipsum augue ornare nulla, non luctus diam neque sit amet urna.\n") > (insert "Pellentesque condimentum, magna ut suscipit hendrerit, = ipsum augue ornare nulla, non luctus diam neque sit amet urna.\n") > (insert (propertize "THISISACIRCLE" 'display (svg-image svg))) > (insert " Aliquam posuere.\n") > (pop-to-buffer buf) > (goto-char (point-max)) > (forward-line -1) > (toggle-truncate-lines 1) > (let ((above-image (window-text-pixel-size nil (cons (point) -1) = (point) nil nil nil t))) > (forward-line -1) > (message "FIRST LINE: %S; ABOVE IMAGE: %S" > (window-text-pixel-size nil (cons (point) -1) (point) nil = nil nil t) > above-image)))) > --8<---------------cut here---------------end--------------->8--- > --=20 > Manuel Giraud --Apple-Mail=_39410B18-29A7-4D22-AA25-A8412F42A80D Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=utf-8 Thanks for = checking this, Manuel.  I=E2=80=99ve already filed a bug report and = Eli has found a fix, but unfortunately only for this very specific case = with line truncation.  The general issue remains.  We are = seeking a self-contained reproducer for the more general case in other = wrap modes (visual-line, normal wrapping). =  

Please see https://deb= bugs.gnu.org/cgi/bugreport.cgi?bug=3D67533 to continue the = discussion there.

On Dec 1, 2023, at 3:36=E2=80=AFAM, Manuel Giraud = <manuel@ledu-giraud.fr> wrote:

JD Smith <jdtsmith@gmail.com> = writes:

In developing a new pixel-precise smooth = scrolling mode, I=E2=80=99ve noticed
that inline SVG images confuse = Emacs regarding pixel positions of
surrounding elements.  You = sometimes also experience this while
visiting SVG image-rich files = (think org-latex-preview) while in
visual line mode.  In this = case, previous/next-line sometimes jump
from one side of the window = to the other.

But it=E2=80=99s easiest to reproduce with = line-truncation in effect.  Run the
snippet below with your = frame either expanded wide enough to
accommodate the full width of = the 1st line of text, or too narrow
(eliciting truncation). =  While truly truncated and with point on the
SVG, pixel text = measurements above are erroneous (reporting zero pixel
height above), = as if it thinks it=E2=80=99s on the prior line.  At other
points = in line 2, the pixel-size values are correct.

Hi, I can reproduce this on master. =  Below I modified your example
slightly and I also observe different pixel width for the = same text
line.

I think you should file a bug report with = this issue.  Thanks.

--8<---------------cut = here---------------start------------->8---
;;; test-svg-pixel-position --- test pixel = position for SVG images

;;; = This small code creates a buffer with two lines, the first of
;;; which is long, and the second of which = has an SVG image at start.
;;; = Line truncation is turned on.  `window-text-pixel-size` = returns
;;; differing results = depending on whether truncation is actually in
;;; effect (alter the frame width to see = this).

;;; Code:
(require 'svg)
(let ((buf "svg-pixel-demo")
     (svg = (svg-create 50 25)))
 (svg-circle svg 25 25 25 :stroke-color = "green")
 (with-current-buffer (get-buffer-create = buf)
   (erase-buffer)
   (insert "Pellentesque = condimentum, magna ut suscipit hendrerit, ipsum augue ornare nulla, non = luctus diam neque sit amet urna.\n")
   (insert "Pellentesque condimentum, magna = ut suscipit hendrerit, ipsum augue ornare nulla, non luctus diam neque = sit amet urna.\n")
   (insert (propertize "THISISACIRCLE" = 'display (svg-image svg)))
   (insert " Aliquam posuere.\n")
   (pop-to-buffer = buf)
   (goto-char (point-max))
   (forward-line = -1)
   (toggle-truncate-lines 1)
   (let ((above-image = (window-text-pixel-size nil (cons (point) -1) (point) nil nil nil = t)))
     (forward-line -1)
     (message = "FIRST LINE: %S; ABOVE IMAGE: %S"
=        (window-text-pixel-size = nil (cons (point) -1) (point) nil nil nil t)
      = ; above-image))))
--8<---------------cut = here---------------end--------------->8---
-- 
Manuel = Giraud

= --Apple-Mail=_39410B18-29A7-4D22-AA25-A8412F42A80D--