[Emacs-diffs] master 769e9fa 1/2: Fix text shaping of precomposed characters with HarfBuzz

[Eli Zaretskii]

branch: master
commit 769e9fa5ae2779f9eacc835784b88aea5cc5a396
Author: Eli Zaretskii <address@hidden>
Commit: Eli Zaretskii <address@hidden>

    Fix text shaping of precomposed characters with HarfBuzz
    
    * src/hbfont.c (hbfont_shape): Fix setting TO of lglyph for
    the case when Lisp shape-gstring function performed some
    compositions by itself.  This happens with hebrew.el.  See
    https://lists.freedesktop.org/archives/harfbuzz/2019-June/007396.html
    for the details of the problem this solves.
---
 src/hbfont.c | 12 +++++++++++-
 1 file changed, 11 insertions(+), 1 deletion(-)

diff --git a/src/hbfont.c b/src/hbfont.c
index 5923efd..623bee6 100644
--- a/src/hbfont.c
+++ b/src/hbfont.c
@@ -435,7 +435,17 @@ hbfont_shape (Lisp_Object lgstring, Lisp_Object direction)
 
       /* All the glyphs in a cluster have the same values of FROM and TO.  */
       LGLYPH_SET_FROM (lglyph, from);
-      LGLYPH_SET_TO (lglyph, to);
+      /* This heuristic is for when the Lisp shape-gstring function
+        substitutes known precomposed characters for decomposed
+        sequences.  E.g., hebrew.el does that.  This makes TEXT_LEN
+        be smaller than the original length of the composed character
+        sequence.  In that case, we must not alter the largest TO,
+        because the display engine must know that all the characters
+        in the original sequence were processed by the composition.
+        If we don't do this, some of the composed characters will be
+        displayed again as separate glyphs.  */
+      if (!(to == text_len - 1 && LGLYPH_TO (lglyph) > to))
+       LGLYPH_SET_TO (lglyph, to);
 
       /* Not every glyph in a cluster maps directly to a single
         character; in general, N characters can yield M glyphs, where