TRAK support for .SFNSText disagrees with CoreText

[drott]

Using ToT HarfBuzz in Chromium after the kerning fixes still results in about ~420 layout test failures, many of them related to CSS system-font usage or themed UI controls rendering with differing spacing. Also the designated TRAK test that we have to compare tracking to Safari fails. HarfBuzz seems to apply some tracking, which still results in a non-linear run-width to font-size ratio, but the values are very different from Safari.

I am testing with .SFNSText, which has the following trak info:

$ ttx -o- -ttrak /System/Library/Fonts/SFNSText.ttf 
Dumping "/System/Library/Fonts/SFNSText.ttf" to "-"...
<?xml version="1.0" encoding="UTF-8"?>
<ttFont sfntVersion="\x00\x01\x00\x00" ttLibVersion="3.22">

Dumping 'trak' table...
  <trak>
    <version value="1.0"/>
    <format value="0"/>
    <horizData>
      <!-- nTracks=3, nSizes=20 -->
      <trackEntry value="-1.0" nameIndex="291">
        <track size="6.0" value="54"/>
        <track size="9.0" value="10"/>
        <track size="10.0" value="-4"/>
        <track size="11.0" value="-16"/>
        <track size="12.0" value="-28"/>
        <track size="13.0" value="-40"/>
        <track size="14.0" value="-50"/>
        <track size="15.0" value="-60"/>
        <track size="16.0" value="-68"/>
        <track size="17.0" value="-75"/>
        <track size="20.0" value="-83"/>
        <track size="22.0" value="-88"/>
        <track size="28.0" value="-94"/>
        <track size="32.0" value="-96"/>
        <track size="36.0" value="-98"/>
        <track size="50.0" value="-106"/>
        <track size="64.0" value="-114"/>
        <track size="80.0" value="-120"/>
        <track size="100.0" value="-120"/>
        <track size="138.0" value="-120"/>
      </trackEntry>
      <trackEntry value="0.0" nameIndex="290">
        <track size="6.0" value="82"/>
        <track size="9.0" value="38"/>
        <track size="10.0" value="24"/>
        <track size="11.0" value="12"/>
        <track size="12.0" value="0"/>
        <track size="13.0" value="-12"/>
        <track size="14.0" value="-22"/>
        <track size="15.0" value="-32"/>
        <track size="16.0" value="-40"/>
        <track size="17.0" value="-47"/>
        <track size="20.0" value="-55"/>
        <track size="22.0" value="-60"/>
        <track size="28.0" value="-66"/>
        <track size="32.0" value="-68"/>
        <track size="36.0" value="-70"/>
        <track size="50.0" value="-78"/>
        <track size="64.0" value="-86"/>
        <track size="80.0" value="-92"/>
        <track size="100.0" value="-92"/>
        <track size="138.0" value="-92"/>
      </trackEntry>
      <trackEntry value="2.0" nameIndex="292">
        <track size="6.0" value="74"/>
        <track size="9.0" value="30"/>
        <track size="10.0" value="16"/>
        <track size="11.0" value="4"/>
        <track size="12.0" value="-8"/>
        <track size="13.0" value="-20"/>
        <track size="14.0" value="-30"/>
        <track size="15.0" value="-40"/>
        <track size="16.0" value="-48"/>
        <track size="17.0" value="-55"/>
        <track size="20.0" value="-76"/>
        <track size="22.0" value="-84"/>
        <track size="28.0" value="-93"/>
        <track size="32.0" value="-98"/>
        <track size="36.0" value="-103"/>
        <track size="50.0" value="-116"/>
        <track size="64.0" value="-124"/>
        <track size="80.0" value="-124"/>
        <track size="100.0" value="-124"/>
        <track size="138.0" value="-124"/>
      </trackEntry>
    </horizData>
    <vertData>
      <!-- nTracks=0, nSizes=0 -->
    </vertData>
  </trak>

</ttFont>

Running the following test script:

#!/bin/bash
for ptem_size in 6 9 10 11 12 13 14 15 16 17 20 22 28 32 36 50 64 80 100 138
do
    printf "\nfont-ptem %d:\n" $ptem_size
    for shaper in coretext ot
    do
        printf "%8s: %s\n" $shaper `./hb-shape --font-ptem=$ptem_size --shaper=$shaper /System/Library/Fonts/SFNSText.ttf "YoVa"`
    done
done

outputs:

font-ptem 6:
coretext: [gid345=0+1226|gid771=1+1162|gid332=2+1332|gid572=3+1182]
      ot: [gid345=0@12,0+1369|gid771=1@12,0+1235|gid332=2@12,0+1405|gid572=3@12,0+1155]

font-ptem 9:
coretext: [gid345=0+1174|gid771=1+1110|gid332=2+1280|gid572=3+1130]
      ot: [gid345=0@-14,0+1316|gid771=1@-14,0+1182|gid332=2@-14,0+1352|gid572=3@-14,0+1102]

font-ptem 10:
coretext: [gid345=0+1159|gid771=1+1095|gid332=2+1265|gid572=3+1115]
      ot: [gid345=0@-22,0+1301|gid771=1@-22,0+1167|gid332=2@-22,0+1337|gid572=3@-22,0+1087]

font-ptem 11:
coretext: [gid345=0+1146|gid771=1+1082|gid332=2+1252|gid572=3+1102]
      ot: [gid345=0@-28,0+1287|gid771=1@-28,0+1153|gid332=2@-28,0+1323|gid572=3@-28,0+1073]

font-ptem 12:
coretext: [gid345=0+1134|gid771=1+1070|gid332=2+1240|gid572=3+1090]
      ot: [gid345=0@-34,0+1276|gid771=1@-34,0+1142|gid332=2@-34,0+1312|gid572=3@-34,0+1062]

font-ptem 13:
coretext: [gid345=0+1127|gid771=1+1063|gid332=2+1233|gid572=3+1083]
      ot: [gid345=0@-38,0+1268|gid771=1@-38,0+1134|gid332=2@-38,0+1304|gid572=3@-38,0+1054]

font-ptem 14:
coretext: [gid345=0+1123|gid771=1+1059|gid332=2+1229|gid572=3+1079]
      ot: [gid345=0@-40,0+1265|gid771=1@-40,0+1131|gid332=2@-40,0+1301|gid572=3@-40,0+1051]

font-ptem 15:
coretext: [gid345=0+1174|gid771=1+1110|gid332=2+1280|gid572=3+1130]
      ot: [gid345=0@-42,0+1261|gid771=1@-42,0+1127|gid332=2@-42,0+1297|gid572=3@-42,0+1047]

font-ptem 16:
coretext: [gid345=0+1174|gid771=1+1110|gid332=2+1280|gid572=3+1130]
      ot: [gid345=0@-43,0+1258|gid771=1@-43,0+1124|gid332=2@-43,0+1294|gid572=3@-43,0+1044]

font-ptem 17:
coretext: [gid345=0+1174|gid771=1+1110|gid332=2+1280|gid572=3+1130]
      ot: [gid345=0@-44,0+1255|gid771=1@-44,0+1121|gid332=2@-44,0+1291|gid572=3@-44,0+1041]

font-ptem 20:
coretext: [gid345=0+1174|gid771=1+1110|gid332=2+1280|gid572=3+1130]
      ot: [gid345=0@-46,0+1251|gid771=1@-46,0+1117|gid332=2@-46,0+1287|gid572=3@-46,0+1037]

font-ptem 22:
coretext: [gid345=0+1174|gid771=1+1110|gid332=2+1280|gid572=3+1130]
      ot: [gid345=0@-47,0+1249|gid771=1@-47,0+1115|gid332=2@-47,0+1285|gid572=3@-47,0+1035]

font-ptem 28:
coretext: [gid345=0+1174|gid771=1+1110|gid332=2+1280|gid572=3+1130]
      ot: [gid345=0@-49,0+1245|gid771=1@-49,0+1111|gid332=2@-49,0+1281|gid572=3@-49,0+1031]

font-ptem 32:
coretext: [gid345=0+1174|gid771=1+1110|gid332=2+1280|gid572=3+1130]
      ot: [gid345=0@-51,0+1242|gid771=1@-51,0+1108|gid332=2@-51,0+1278|gid572=3@-51,0+1028]

font-ptem 36:
coretext: [gid345=0+1174|gid771=1+1110|gid332=2+1280|gid572=3+1130]
      ot: [gid345=0@-52,0+1239|gid771=1@-52,0+1105|gid332=2@-52,0+1275|gid572=3@-52,0+1025]

font-ptem 50:
coretext: [gid345=0+1174|gid771=1+1110|gid332=2+1280|gid572=3+1130]
      ot: [gid345=0@-58,0+1229|gid771=1@-58,0+1095|gid332=2@-58,0+1265|gid572=3@-58,0+1015]

font-ptem 64:
coretext: [gid345=0+1174|gid771=1+1110|gid332=2+1280|gid572=3+1130]
      ot: [gid345=0@-60,0+1224|gid771=1@-60,0+1090|gid332=2@-60,0+1260|gid572=3@-60,0+1010]

font-ptem 80:
coretext: [gid345=0+1174|gid771=1+1110|gid332=2+1280|gid572=3+1130]
      ot: [gid345=0@-60,0+1224|gid771=1@-60,0+1090|gid332=2@-60,0+1260|gid572=3@-60,0+1010]

font-ptem 100:
coretext: [gid345=0+1174|gid771=1+1110|gid332=2+1280|gid572=3+1130]
      ot: [gid345=0@-60,0+1224|gid771=1@-60,0+1090|gid332=2@-60,0+1260|gid572=3@-60,0+1010]

font-ptem 138:
coretext: [gid345=0+1174|gid771=1+1110|gid332=2+1280|gid572=3+1130]
      ot: [gid345=0@-80,0+1184|gid771=1@-80,0+1050|gid332=2@-80,0+1220|gid572=3@-80,0+970]

So CoreText and OT seem to vastly disagree on the spacing here. I don't have a plausible interpretation on what's going on.

[brawer]

For testing, I’ve made an OFL-licensed font with a trak table; H is its only glyph: https://github.com/unicode-org/text-rendering-tests/blob/master/fonts/TestTRAKOne.ttf

[behdad]

For testing, I’ve made an OFL-licensed font with a trak table; H is its only glyph: https://github.com/unicode-org/text-rendering-tests/blob/master/fonts/TestTRAKOne.ttf

There's also one @ebraminio and I made for HarfBuzz. It's in the repo test/shaping/data/in-house/fonts/TestTRAK.ttf if you want to grab. It has morx table and support ABC glyphs.

[drott]

This issue seems more pronounced when kern and trak are present, as in the SFNSText.ttf example with the heavily kerned "YoVa" test string. Certainly we should be able to bring both, trak only and kern + trak into alignment with the respective CoreText results or at the very least have a good explanation of why we differ.

[behdad]

Can you paste a few samples of coretext output w kern and trak?

[drott]

I'm saying the font I'm using has both Kern and trak, the output above should have both features on by default.

[behdad]

Okay. I found a bug in my implementation and fixed it. However, for in your output looks like CoreText stops applying trak at 16ptem. That is when the trak values start getting negative. I don't know, do we want to match that?

[behdad]

Also, looks like we apply trak to the sides of the text run as well, while CoreText doesn't. I think our behavior is more correct.

[behdad]

Reopening while we figure out the rest. But please give it a run with these changes.

[behdad]

Note that CoreText points are equal to CSS pixels, equal to 4./3. typographic points. So, when you put --font-ptem=9, it matches the number 12 in the trak table, which happens to be 0-tracking value.

[behdad]

BTW, you can use --ned to get absolute glyph positions. That better matches CoreText output.

[drott]

Thanks for the fix! So which tracking table will be used and how can I control that? Is the 0 entry now used by default?

Note that CoreText points are equal to CSS pixels, equal to 4./3. typographic points. So, when you put --font-ptem=9, it matches the number 12 in the trak table, which happens to be 0-tracking value.

What does that mean for my testing?

I thought we noticed that Safari's CSS font px sizes are directly used without conversion for the trak table, aren't they?
In the test case expectations that we recorded from Safari:
https://cs.chromium.org/chromium/src/third_party/WebKit/LayoutTests/fast/text/mac-system-ui-trak.html?q=ui+trak+layout+tests&sq=package:chromium&dr=C&l=38
There is non-linear scaling down to 6px/Mac-Points, so I don't think CoreText stops applying tracking lower down.

[ebraminio]

So which tracking table will be used and how can I control that? Is the 0 entry now used by default?

Currently only table with value="0" is used, like Firefox. We need bilinear interpolation for supporting other tables.

What does that mean for my testing?

Probably nothing, just rebase the tests if visually not noticeable. (at least that is what I understand)

I don't think CoreText stops applying tracking lower down.

We are doing extrapolation AFAIK, Behdad has fixed that.