]> git.eshelyaron.com Git - emacs.git/commitdiff
Fix text shaping of precomposed characters with HarfBuzz
authorEli Zaretskii <eliz@gnu.org>
Thu, 13 Jun 2019 08:49:30 +0000 (11:49 +0300)
committerEli Zaretskii <eliz@gnu.org>
Thu, 13 Jun 2019 08:49:30 +0000 (11:49 +0300)
* 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

index 5923efd488d5d6111bdc8ff1e8595a413e464898..623bee61cc857de38fb243da430ab6612de41c9b 100644 (file)
@@ -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