GNU bug report logs - #67533
SVG images confound position pixel measurements

Previous Next

Full log

Message #11 received at 67533 <at> debbugs.gnu.org (full text, mbox):

From: JD Smith <jdtsmith <at> gmail.com>
To: Eli Zaretskii <eliz <at> gnu.org>
Cc: 67533 <at> debbugs.gnu.org
Subject: Re: bug#67533: SVG images confound position pixel measurements
Date: Thu, 30 Nov 2023 16:00:09 -0500

[Message part 1 (text/plain, inline)]

> On Nov 30, 2023, at 12:32 PM, Eli Zaretskii <eliz <at> gnu.org> wrote:
> 
> Does the patch below fix the issue?  (It should fix the recipe you
> posted, but you hinted that this is just the simplest way of seeing a
> more general problem, so I wonder whether that more general problem is
> also fixed.)

Thanks for looking into it.  As you surmised, this patch fixes only the demo case with truncate-lines.  For the more general case, originally discovered with visual-line-mode on an org-mode file with many SVG preview overlays, the issue remains.  In that more general case, window-text-pixel-size sometimes gives 0 or (when the image is not at the start of the visual line) a value which is too large.  

The file I can pretty readily reproduce it on here is at https://gist.github.com/jdtsmith/de34aac901fc9f96f1a88a1b1b67d46e (I use dvigms for latex preview).  Only some of the preview overlay images (and other locations) exhibit the misbehavior, but more so for narrower frames with more wrapping.  I’m happy to test on this end, since my pixel scrolling code finds these types of incorrect results quite instantly.  As I change the window width and the text reflows, different positions exhibit the problems. 

The misbehavior extends to other regular text on the line, too, not just images.  There are various possibilities for what (window-text-pixel-size nil (cons (point) -1) (point) nil nil nil t) returns:

The correct value for position (start of line above) and (line-pixel-height) of that line.  Most text does this, but not when the visual line starts with a “bad” image.
Images at line start can (but don’t always) return their own position and zero height.
On an image further right of a line-starting “bad” image, it returns the bad image position, but the full height of the line. 
Some images on lines which do not start with an image return the correct position (on the prior line), but a height which is too large, as if they included some of their own height in the total.

Here’s a shot of a larger version of the file, with point on a position which gives misbehavior #2.



[Message part 2 (text/html, inline)]

[PastedGraphic-1.png (image/png, inline)]

Previous Next

GNU bug tracking system
Copyright (C) 1999 Darren O. Benham, 1997,2003 nCipher Corporation Ltd, 1994-97 Ian Jackson.