> Cc: 79285@debbugs.gnu.org
> Date: Sun, 31 Aug 2025 12:25:32 +0300
> From: Eli Zaretskii <eliz@gnu.org>
>
> If I'm right, then we will need to make changes in display-engine
> functions like composition_compute_stop_pos, composition_reseat_it,
> find_composition, and others, to force the text which has such a face
> attribute to be handed to HarfBuzz for shaping. An alternative is to
> require that use of this face attribute needs special setup of
> composition-function-table, but that is IMO worse because it will slow
> down display of the relevant characters even if they don't have the
> face with this attribute.
Or maybe it will be enough to make the change in
get_glyph_face_and_encoding, as the etc/TODO item suggests:
instead of calling the 'encode_char' method of the font driver, we
should invoke the 'shape' method
But this will only work if the effect of the relevant font features is
per-character, i.e. HarfBuzz doesn't need to see the entire word to
shape the characters according to the requested feature(s). Do you
happen to know if all the features that are relevant for us can be
applied on a character-by-character basis?
I was diving into a bit more detail of how text is rendered in Emacs. If I understand correctly the your suggestion is bypassing the composite.el and constructing the glyph string directly in xdisp.c and pass it to all kinds of shape function in different backend directly?
I’d need to wrap my head around the display engine first to have more constructive discussion. A bit more direction from you on what to look for will be very helpful.