all messages for Emacs-related lists mirrored at yhetil.org
 help / color / mirror / code / Atom feed
From: Eli Zaretskii <eliz@gnu.org>
To: JD Smith <jdtsmith@gmail.com>
Cc: 67533@debbugs.gnu.org
Subject: bug#67533: SVG images confound position pixel measurements
Date: Sun, 03 Dec 2023 15:02:21 +0200	[thread overview]
Message-ID: <83r0k3782q.fsf@gnu.org> (raw)
In-Reply-To: <616C9D31-F265-4735-B73E-C0574D79F7F1@gmail.com> (message from JD Smith on Sat, 2 Dec 2023 22:04:25 -0500)

> From: JD Smith <jdtsmith@gmail.com>
> Date: Sat, 2 Dec 2023 22:04:25 -0500
> Cc: 67533@debbugs.gnu.org
> 
> Progress.  The latest patch had two small hunks fail (see below), but they were simple enough that I was able to insert them by hand and recompile.
> 
> The good news is that this patch does on my end fix all the problems with the generated SVGs buffer from my recent test, at all window widths.  Unfortunately, checking my original file where this issue was revealed, there are still quite a few “false zero height above” reports.  Happily in that file there are no longer any of the “overly large height” variety, so this particular issue has apparently has been fixed by your patch.
> 
> I’ve placed a new test that generates a minimal buffer with a single :file-based SVG overlay at the same gist, and copied/attached them below, for posterity.  I’ve also fixed the bug in my/check-buffer-pixel-values which caused the report buffer not to appear (due to end-of-buffer being signaled), so please update that.  And please note the new svg_test.svg file, to be placed in the same directory.
> 
> I don’t think there should be anything special about this particular SVG file; it was automatically generated from the underlying latex fragment.  But it seems to be confusing the display engine somehow (as do many others).

There _is_ something special about that SVG: it is wider that 1/4th of
the default frame width.  If you widen the frame to be wider than
4*209=836 pixels, the problem disappears.  Such wide images are
handles specially by the display engine.

The cumulative patch below should fix all the problems you threw on me
till now.

diff --git a/src/xdisp.c b/src/xdisp.c
index 0b2508c..ca85838 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,14 +11527,29 @@ 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);
 	      it.max_descent = max (it.max_descent, it.descent);
 	    }
 	}
+      else if (IT_CHARPOS (it) > end
+	       && it.line_wrap == TRUNCATE
+	       && it.current_x - it.first_visible_x >= it.last_visible_x)
+	{
+          /* If the display property at END is at the beginning of the
+             line, and the previous line was truncated, we are at END,
+             but it.current_y is not yet updated to reflect that.  */
+          it.current_y += max (it.max_ascent, it.ascent)
+                          + max (it.max_descent, it.descent);
+	}
     }
   else
     bidi_unshelve_cache (it2data, true);
@@ -31343,9 +31360,13 @@ produce_image_glyph (struct it *it)
 
   take_vertical_position_into_account (it);
 
-  /* Automatically crop wide image glyphs at right edge so we can
-     draw the cursor on same display row.  */
-  if ((crop = it->pixel_width - (it->last_visible_x - it->current_x), crop > 0)
+  /* Automatically crop wide image glyphs at right edge so we can draw
+     the cursor on same display row.  But don't do that under
+     word-wrap, unless the image starts at column zero, because
+     wrapping correctly needs the real pixel width of the image.  */
+  if ((it->line_wrap != WORD_WRAP || it->hpos == 0)
+      && (crop = it->pixel_width - (it->last_visible_x - it->current_x),
+	  crop > 0)
       && (it->hpos == 0 || it->pixel_width > it->last_visible_x / 4))
     {
       it->pixel_width -= crop;





  reply	other threads:[~2023-12-03 13:02 UTC|newest]

Thread overview: 40+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2023-11-29 19:02 SVG images confound position pixel measurements JD Smith
2023-11-29 20:31 ` bug#67533: " JD Smith
2023-11-30 17:32   ` Eli Zaretskii
2023-11-30 21:00     ` JD Smith
2023-12-01  7:08       ` Eli Zaretskii
2023-12-01 22:04         ` JD Smith
2023-12-02  7:30           ` Eli Zaretskii
2023-12-02 13:36             ` JD Smith
2023-12-02 14:18               ` Eli Zaretskii
2023-12-02 19:39                 ` Eli Zaretskii
2023-12-02 21:44                   ` JD Smith
2023-12-03  3:04                     ` JD Smith
2023-12-03 13:02                       ` Eli Zaretskii [this message]
2023-12-03 15:48                         ` JD Smith
2023-12-03 15:52                           ` Eli Zaretskii
2023-12-03 16:31                             ` Eli Zaretskii
2023-12-03 21:25                               ` JD Smith
2023-12-03 23:14                                 ` JD Smith
2023-12-04  3:27                                 ` Eli Zaretskii
2023-12-04  4:32                                   ` JD Smith
2023-12-04 13:11                                     ` Eli Zaretskii
2023-12-04 14:14                                       ` JD Smith
2023-12-16  9:32                                         ` Eli Zaretskii
2023-12-16 15:07                                           ` JD Smith
2023-12-16 15:23                                             ` Eli Zaretskii
2023-12-03 15:49                         ` JD Smith
2023-12-03 16:33                           ` Eli Zaretskii
2023-12-03 18:58                             ` JD Smith
2023-12-01 14:40     ` Manuel Giraud via Bug reports for GNU Emacs, the Swiss army knife of text editors
2023-12-01 14:55       ` Eli Zaretskii
2023-12-01 15:21         ` JD Smith
2023-12-01 15:36           ` Eli Zaretskii
2023-12-01 15:45             ` JD Smith
2023-12-01 15:59               ` Eli Zaretskii
2023-12-01 16:17                 ` JD Smith
2023-12-01 16:30                   ` Eli Zaretskii
2023-12-01 16:27         ` Manuel Giraud via Bug reports for GNU Emacs, the Swiss army knife of text editors
2023-12-01 16:31           ` Eli Zaretskii
2023-12-01  8:36 ` Manuel Giraud via Emacs development discussions.
2023-12-01 14:11   ` JD Smith

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=83r0k3782q.fsf@gnu.org \
    --to=eliz@gnu.org \
    --cc=67533@debbugs.gnu.org \
    --cc=jdtsmith@gmail.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
Code repositories for project(s) associated with this external index

	https://git.savannah.gnu.org/cgit/emacs.git
	https://git.savannah.gnu.org/cgit/emacs/org-mode.git

This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.