GNU bug report logs - #79285
[Patch] support :font-features in face

Previous Next

Full log

View this message in rfc822 format

From: Eli Zaretskii <eliz <at> gnu.org>
To: Binbin YE <phantom2501 <at> gmail.com>
Cc: 79285 <at> debbugs.gnu.org
Subject: bug#79285: [Patch] support :font-features in face
Date: Wed, 03 Sep 2025 15:10:31 +0300

> From: Binbin YE <phantom2501 <at> gmail.com>
> Date: Wed, 3 Sep 2025 08:40:38 +0900
> Cc: 79285 <at> debbugs.gnu.org
> 
>  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?

That's the idea, yes.  It would mean to have a function in hbfont.c
that is the subset of hbfont_shape, and which accepts a single
character (not a Lisp string) and a font, and then constructs the
hb_buffer and submits that to hb_shape_full.

But please test if this should give good results by simulating it, as
follows:

 . make composition-function-table whose cells for several characters
   match only that one character, and see how a string of such
   characters is rendered using a font with relevant OpenType features
 . then compare that with rendering when composition-function-table
   has the same rule in the cell of each of those characters, matching
   any sequence of these characters (as in "[abcdefg]+")

If applying stylistic sets by rendering text one character at a time
produces different results from rendering them all as a single string,
then this idea is not workable, and we will need to use the (slower
and more complex) composite.c machinery instead.

If the idea does work, then presumably a change in
get_glyph_face_and_encoding for characters that have this special
face attribute will be all that's needed, perhaps together with some
flag in the 'struct it' to make that faster.  Details later, when we
know whether the idea works or not.

> 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. 

See above.  If the idea of shaping one character at a time doesn't
work, I will then tell you how to study the code which handles
character compositions.

Thanks.

Previous Next

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