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

Previous Next

Package: emacs;

Reported by: JD Smith <jdtsmith <at> gmail.com>

Date: Wed, 29 Nov 2023 20:33:01 UTC

Severity: normal

Done: Eli Zaretskii <eliz <at> gnu.org>

Bug is archived. No further changes may be made.

Full log


Message #62 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: Sat, 2 Dec 2023 16:44:37 -0500
Thanks for your work.   The port I use has fallen a few weeks behind master and the patches to xdisp.c unfortunately don’t apply cleanly.  I’ll see about building an NS port and report back. 

> On Dec 2, 2023, at 2:39 PM, Eli Zaretskii <eliz <at> gnu.org> wrote:
> 
>> Cc: 67533 <at> debbugs.gnu.org
>> Date: Sat, 02 Dec 2023 16:18:28 +0200
>> From: Eli Zaretskii <eliz <at> gnu.org>
>> 
>>> From: JD Smith <jdtsmith <at> gmail.com>
>>> Date: Sat, 2 Dec 2023 08:36:07 -0500
>>> Cc: 67533 <at> debbugs.gnu.org
>>> 
>>> Strange.  Both of my ports here (NS and Mac) show the same issue.  Did you check the
>>> svg-pixel-demo-report buffer the header mentions, where the mismatch measurement information
>>> gets reported?  The specific problems encountered are listed in the report buffer, updated with
>>> my/check-buffer-pixel-values.  For example, at a standard width of 80 characters, I get this report:
>>> 
>>> SVG Position analysis for svg-pixel-demo (width 80, text-properties)
>>> 
>>> Incorrect at point= 34: line  2 at   (224 . 14) (image): expected 14 got 28
>>> Incorrect at point= 99: line  3 at   (244 . 43) (image): expected 29 got 46
>>> Incorrect at point=126: line  4 at    (42 . 75) (image): expected 32 got 46
>>> Incorrect at point=162: line  4 at   (345 . 75) (image): expected 32 got 52
>>> Incorrect at point=210: line  5 at  (133 . 110) (image): expected 35 got 49
>> 
>> I never understood I need to look in another buffer.  I will look into
>> these.
> 
> Please try the patch below and see if any problems remain.
> 
> diff --git a/src/xdisp.c b/src/xdisp.c
> index 0b2508c..cc95ab3 100644
> --- a/src/xdisp.c
> +++ b/src/xdisp.c
> @@ -11436,7 +11436,7 @@ window_text_pixel_size (Lisp_Object window, Lisp_Object from, Lisp_Object to,
>       /* Start at the beginning of the line containing FROM.  Otherwise
> 	 IT.current_x will be incorrectly set to zero at some arbitrary
> 	 non-zero X coordinate.  */
> -      reseat_at_previous_visible_line_start (&it);
> +      move_it_by_lines (&it, 0);
>       it.current_x = it.hpos = 0;
>       if (IT_CHARPOS (it) != start)
> 	{
> @@ -11513,6 +11513,8 @@ window_text_pixel_size (Lisp_Object window, Lisp_Object from, Lisp_Object to,
>      the width of the last buffer position manually.  */
>   if (IT_CHARPOS (it) > end)
>     {
> +      int end_y = it.current_y;
> +
>       end--;
>       RESTORE_IT (&it, &it2, it2data);
>       x = move_it_to (&it, end, to_x, max_y, -1, move_op);
> @@ -11525,8 +11527,13 @@ window_text_pixel_size (Lisp_Object window, Lisp_Object from, Lisp_Object to,
> 
> 	  /* DTRT if ignore_line_at_end is t.  */
> 	  if (!NILP (ignore_line_at_end))
> -	    doff = (max (it.max_ascent, it.ascent)
> -		    + max (it.max_descent, it.descent));
> +	    {
> +	      /* If END-1 is on the previous screen line, we need to
> +                 account for the vertical dimensions of previous line.  */
> +	      if (it.current_y < end_y)
> +		doff = (max (it.max_ascent, it.ascent)
> +			+ max (it.max_descent, it.descent));
> +	    }
> 	  else
> 	    {
> 	      it.max_ascent = max (it.max_ascent, it.ascent);





This bug report was last modified 1 year and 156 days ago.

Previous Next


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