bug#67533: SVG images confound position pixel measurements

[Eli Zaretskii]

> From: JD Smith <jdtsmith@gmail.com>
> Date: Thu, 30 Nov 2023 16:00:09 -0500
> Cc: 67533@debbugs.gnu.org
> 
> > On Nov 30, 2023, at 12:32 PM, Eli Zaretskii <eliz@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.

Thanks, but I need recipes I could reproduce on my system, and
reproduce relatively easily.  Debugging this usually takes numerous
runs under GDB, so the recipe should be reasonably easy to run, so it
doesn't take too long to set up a debugging session, and preferably it
should not require installation of optional packages.  It also cannot
depend on something that doesn't work on MS-Windows, because this is
the only system where I can debug a GUI Emacs.  So, for example, using
LaTeX Preview and dvigsm is out of the question; I need ready image
files prepared by LaTeX Preview and Lisp code to display them in a way
that causes problems.

So please try to provide recipes for the problems you still see, after
applying the patch I sent, as simple and preferably stand-alone Lisp
programs that don't require to install and run all of your code.  If
necessary, please emulate what your package does with simplified Lisp
code that just inserts text with display properties and overlays, to
produce the same result as the package does.

I'm sorry to insist on this and asking you to do extra work, but IME
this is the only way I can debug these issues efficiently enough to
solve them.  I appreciate the offer to test on your end, but such
testing is only useful when I have a tentative solution in hand for
you to test.  Such a tentative solution must be based on some problem
I found and fixed here, and for that I must be able to step through
the offending code in GDB.

Thanks.