Accent / Combining Mark placement differences between CoreText and own shaper

[drott]

When trying to switch to the own shaping backend on Mac, I see a couple of combining mark placement differences:

1. Lucida Grande Hebrew:

The OT shaper moves the sheva slightly to the left compared to CoreText.

$ ./hb-shape /System/Library/Fonts/LucidaGrande.ttc `../test/shaping/hb-unicode-encode U+05E1,U+05B0` --shaper=coretext
[shevahebrew=0+0|samekhhebrew=0+1361]

$ ./hb-shape /System/Library/Fonts/LucidaGrande.ttc `../test/shaping/hb-unicode-encode U+05E1,U+05B0` --shaper=ot 
[shevahebrew=0@-7,0+0|samekhhebrew=0+1361]

2. Lucida Grande m + accent grave

Coretext places U+0300 further north from the m glyph:

$ ./hb-shape /System/Library/Fonts/Helvetica.ttc `../test/shaping/hb-unicode-encode U+006D,U+0300` --shaper=coretext
[m=0+1422|gravecmb=0@0,96+283]

$ ./hb-shape /System/Library/Fonts/Helvetica.ttc `../test/shaping/hb-unicode-encode U+006D,U+0300` --shaper=ot
[m=0+1706|gravecmb=0@-284,10+0]

[brawer]

Neither Helvetica.ttc nor LucidaGrande.ttc contain an ankr table. Perhaps I’m mis-reading the HarfBuzz code, but does the kerx implementation currently fall back to taking anchor points from glyf when the font has no ankr? The very end of the kerx spec says:

If the font has an 'ankr' (anchor point) table, it is used to define the anchor points. Otherwise, the "anchor points" are the points defined by the 'glyf' (glyph data) table.

[behdad]

HarfBuzz implements all three ways the anchors can be encoded:

harfbuzz/src/hb-aat-layout-kerx-table.hh

Line 346 in 2e7c716

switch (action_type)

I have only tested the one using 'ankr' table though. I'll test these. If they use the glyph point method, then this might be that Skia doesn't implement that harfbuzz callback (get_contour_point).

[behdad]

The Helvetica in your example, does NOT have a GPOS table, and does NOT have a kerx table. So, no mark positioning in the font. We do our fallback mark positioning, which moves the mark lower. Apple doesn't do anything. So, feature, not bug, in that case. I'll check the other.

[behdad]

Same with LucidaGrande. Doesn't have kern even. No positioning info in the font. We do our fallback.

[avidrissman]

In the Chromium HarfBuzz 2.1 roll CL the discrepancy with Hebrew vowel positioning was linked to this issue, and dismissed as having "been discussed".

In this bug I see discussions about the sheva being positioned slightly to the left or right. The real problem is that the vowels bounce up and down within a word. That's quite wrong. Look at any well-typeset Hebrew text (random Google result) and you'll see the vowels line up across multiple words at the same height. This important property is lost in that CL roll. Please see my comment on that roll for a link to an annotated snapshot (Google link only though I can provide it).

Please do not ignore this. You cannot treat the vowels at just attached to the individual letters and allow them to be inconsistent across multiple letters. They have to line up across words.

[behdad]

This only happen with old and incomplete fonts. Any decent font controls accent positioning and our fallback logic wouldn't interfere. Cc @jfkthame

[avidrissman]

I'm looking at the before-and-after picture from the LayoutTest. LayoutTests/fast/text/atsui-spacing-features.html looks like it uses "Lucida Grande." Did they fix the positioning in the font with 10.11? Whatever CoreText is doing makes it look OK, and I'd definitely call the "after" picture a regression.

[avidrissman]

Any decent don't controls accent positioning

I'm supposing you mean "any decent font controls accent positioning"; please let me know if I misinterpret. How common are fonts that don't, like this font? If this is a one-off problem with Lucida Grande on 10.10, that would be very different than if it's a common problem with many fonts.

[ebraminio]

Don't worry Avi, we will try our best :) HarfBuzz is used widely on different OSes and the issue is limited to some fonts and is not like we decide what is better for fonts and font will decide (which considering adoption you can be sure nothing is horribly wrong) but sometimes there are real faults with the fonts (may or may not be with the case) which solving that from our side is somehow hack and we should consider if that hack won't hurt the other correct usages. I've filled #1356 also which is very similar to this and probably result will help us here also

[avidrissman]

I know that HarfBuzz is used all over, but I'm coming from the CL about replacing CT. If CT compensates for broken fonts and we want to replace CT, we may well have to hack around broken fonts too.

…

On Nov 4, 2018, at 4:04 AM, Ebrahim Byagowi ***@***.***> wrote: Don't worry Avi, we will try our best :) HarfBuzz is used widely on different OSes and the issue is limited to some fonts and is not like we decide what is better for fonts and font will decide (which considering adoption you can be sure nothing is horribly wrong) but sometimes there are real faults with the fonts (may or may not be with the case) which solving that from our side is somehow hack and we should consider if that hack won't hurt the other correct usages. I've filled #1356 also which is very similar to this and probably result will help us here also — You are receiving this because you commented. Reply to this email directly, view it on GitHub, or mute the thread.

[ebraminio]

As this happens with 10.13 version of Lucida Grande, how about disabling hb-ot-shape-fallback#position_mark with AAT fonts at all Behdad?

[ebraminio]

Hmm, disabling hb-ot-shape-fallback#position_mark makes Lucida Grandeto work as expected but losing Helvetica's grave, I supposed to think theu use similar logic in lack of kern, but they don't?