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

Previous Next

Full log

Message #35 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, Manuel Giraud <manuel <at> ledu-giraud.fr>
Subject: Re: bug#67533: SVG images confound position pixel measurements
Date: Fri, 1 Dec 2023 11:17:49 -0500

> On Dec 1, 2023, at 10:59 AM, Eli Zaretskii <eliz <at> gnu.org> wrote:
>>>>> 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.
>>> 
>>> Why zero?  Why not consider that undefined behavior?
>> 
>> Depends on what the natural height on a non-existent line is.  Zero makes sense to me.  But I suppose returning height=nil or something else to indicate “I gave up” would also be reasonable.
> 
> A non-existent line can have any height, including an infinite one.
> Since that line doesn't exist, any assertion about it cannot be
> disproved.

As a general statement, of course.  But since the docs say:

> The optional argument FROM, if non-nil, specifies the first text
> position to consider, and defaults to the minimum accessible position
> of the buffer.


would it not be reasonable that (FROM . (- too-many-pixels)) would also “default to the minimum accessible position”, should the offset prove to be too-many-pixels?  Then, by symmetry, asking for pixel measurements beyond the final accessible line should "default
to the maximum accessible position of the buffer”.  Basically clip the request at the window’s boundaries.  But in any case, the answer to this specific question is I believe a side issue for this bug.

Previous Next

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