bug#67533: SVG images confound position pixel measurements

[JD Smith]

> On Dec 1, 2023, at 9:55 AM, Eli Zaretskii <eliz@gnu.org> wrote:
> 
>> From: Manuel Giraud <manuel@ledu-giraud.fr>
>> Cc: JD Smith <jdtsmith@gmail.com>,  67533@debbugs.gnu.org
>> Date: Fri, 01 Dec 2023 15:40:59 +0100
>> 
>> Eli Zaretskii <eliz@gnu.org> writes:
>> 
>>> 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.)
>> 
>> Hi,
>> 
>> I have applied your patch to master and here are the results I get with
>> the recipe at the end of this message:
>> 
>> With a not large enough window:
>>  FIRST LINE: (925 24 1); ABOVE IMAGE: (925 24 119)
>> 
>> With a large enough window (i.e., that can display the whole first
>> line):
>>  FIRST LINE: (1053 24 1); ABOVE IMAGE: (1062 24 119)
> 
> Btw, I wonder what you and JD expect from the (cons (point) -1)
> argument.  The doc string says:
> 
>  If FROM is a cons, its car specifies a buffer position, and its cdr
>  specifies the vertical offset in pixels from that position to the
>  first screen line to be measured.
> 
> What is the meaning of negative offset from the first line of the
> buffer? there's no screen line at that offset, so what do you expect
> that to do?  Or what am I missing?

In that case I would expect zero pixel height is returned.  As you saw, the 
problem occurs at lines beyond the first visual line.  

My guiding assumption is that the display pixel dimensions returned from (cons 
(point) -1) to (point) (when omitting the height of the line including (point)) 
should be equal to the height of the prior visual line (line-pixel-height), 
unless it has zero height.

I’ll work up a simpler reproducer in non-truncated and/or visual-line-mode.