Found some docs for pre-context in hb_buffer_add_utf, pointing to:
https://bugzilla.mozilla.org/show_bug.cgi?id=801410#c13
So we probably need to do something to use pre-context properly. Haven't figured out about post-context yet, nor if it's needed.
Updated test and screenshot, Blink, LayoutNG, and Gecko from left.
Some interesting observations:
* Kerning across elements doesn't work (compare the width of two "AVA").
* Ligature needs some new way in NGInlineItem because two items need to share a glyph.
* Arabic joining somehow works.
While this still looks improvements for Arabic and no changes for kerning/ligatures, the total width of NG with kerning are slightly worse then legacy in some tests. Need to look a bit more if the change is acceptable.
The pre-context is irrelevant. We already do that fine. The difference is that Firefox ignores color and some other changes and shapes the text as one hb_shape() call, and then colors some parts differently. That's why you see the cap of the second 'f' in the 'ffi' ligature also colored with the 'i'. We don't do that. We break the text when color changes.
Thank you for the comment, understood. I had an impression that giving pre-context will give us the same result as one hb_shape() call, but thinking more, it's not possible at least for ligatures.
I'm getting close to switching to one hb_shape() call in LayoutNG.
> For ligatures, Gecko distributes one glyph to multiple elements
by using the number of code units or code points in each element
It's not number of codepoints. It's number of graphemes. We have similar code for other things, like cursor positions.
Comment 1 by kojii@chromium.org
, Dec 21 2017