* [aat] Correct array indexing when looking up actions in KerxSubTableFormat4.
- For action_type 0 and 1, there are 2 values per action record; for action_type 2, there are 4. So we need to account for these factors when indexing into the ankrData array.
Fixes https://github.com/harfbuzz/harfbuzz/issues/2531.
* [aat] Fix implementation of AAT kerning for Geeza Pro.
Despite what the comment in the code used to say, it appears that Geeza Pro
does rely on accumulating kerning values from successive subtables. With
this change, the results now match Core Text rendering (and avoid the clear
visual breakage reported in #2358).
Testcase: U+0644,U+064E,U+0645,U+064E,U+0651,U+0627
Fixes#2358.
* [aat] Update test expectations, add new testcase.
The test is added in 7035c9cd but the same font is available in older versions of macOS
so let's run it in older versions also.
It doesn't matter much, more for consistency reasons.
A few simple testcases to confirm that setting liga=0 does not break shaping with
the Tibetan AAT font Kokonor, but does still disable common ligatures in Times.
* The ‘height’ needs to be negated since the API returns “distance from
top to bottom side”.
* Similarly, the ‘y_offset‘ needs to be added to the height to get the
‘y_bearing’, since sbix’s offset is “the point in the glyph relative
to its lower-left corner which corresponds to the origin” while
‘y_bearing’ is the “top side of glyph from origin”.
With these changes the sbix glyph metrics return values similar to other
tables, as they were otherwise unusable.
Core Text doesn't actually have a concept of DPI internally, as it
doesn't rasterize anything by itself, it just generates vector paths
that get passed along to Core Graphics.
In practice this means Core Text operates in the classical macOS
logical DPI of 72, with one typographic point corresponding to one
point in the Core Graphics coordinate system, which for a normal
bitmap context then corresponds to one pixel -- or two pixels for
a "retina" context with a 2x scale transform.
Scaling the font point sizes given to HarfBuzz to an assumed DPI
of 96 is problematic with this in mind, as fonts with optical
features such as 'trak' tables for tracking, or color glyphs,
will then base the metrics off of the wrong point size compared
to what the client asked for.
This in turn causes mismatches between the metrics of the shaped
text and the actual rasterization, which doesn't include the 72
to 96 DPI scaling.
If a 96 DPI is needed, such as on the Web, the scaling should be
done outside of HarfBuzz, allowing the client to keep the DPI of
the shaping in sync with the rasterization.
The recommended way to do that is by scaling the font point size,
not by applying a transform to the target Core Graphics context,
to let Core Text choose the right optical features of the target
point size, as described in WWDC 2015 session 804:
https://developer.apple.com/videos/play/wwdc2015/804/
