"5", "7" don't reach cap height at 16–27 ppem

[ortoslon]

"5" or "7" or sometimes both are 1 pixel short of cap height at 16, 17, 20–23, 26, 27 ppem. For comparison, tops of lining figures in Castoro-Regular.ttf b17 look aligned at 12–30 ppem in the same renderer.

STIXTwoText-Medium.ttf v2.11 b159 in Chrome 88 on Win10:

[tiroj]

This is a feature of the design of these glyphs in the STIX fonts—they are slightly shorter than the capital height to optically compensate for the flat horizontal stroke. However, what we’re getting in the TTFs is pixel rounding at various ppem sizes. The new build process for TTFs (earlier STIX build versions were CFF format only) uses ttfautohint, so we have limited control over this level of rendering detail. I suspect the only way to address this would be to actually adjust the design of these glyphs to reduce rounding differences.

[ortoslon]

The way rounding works seems to affect other features too. For example, from 19 to 20 ppem the cap height jumps from 12 to 14 px and H's crossbar goes from above the geometric center to below.

[tiroj]

The build process uses ttfautohint with its default settings. In theory, we could add a configuration file to the process that would tweak some ttfautohint settings, that might produce better results, although I am not super familiar with those settings so would need to investigate.

I see that quite a lot of open source TTF projects include both hinted and unhinted packages. Given the prevalence of higher resolution devices, hinting is less necessary than it used to be, and as we’re seeing here the results of autohinting can be more problematic than helpful.

Have you tested the CFF (.otf) versions of the fonts? Initially, the STIX Two fonts were only available in that flavour, and it is still what I think of as the standard format for the family. We added the TTFs mostly because of the new variable font build, which is TTF, and the fact that we were already generating static TTFs as a processing step to the CFF fonts.

[ortoslon]

For now I've selected non-lining figures via CSS as a workaround for the TTF's.

Overshoots of "C", "G", "S" look exaggerated in OTF's at 27, 26, 24, 21 ppem. Also there's a jump in relative ascender length between 23 and 24 ppem which isn't seen in the TTF's.

STIXTwoText-Medium.otf v2.11 b159 in Chrome 89 on Win10:

I should note that I'm testing these on a ~100-ppi display that isn't "properly" gamma-calibrated and I'm more used to sharp rendering of hand-hinted TTF's.

[tiroj]

I’ve had a colleague do some investigation of options to tweak the ttfautohint settings during the build process. We will look at this again in the context of v2.20. No definite plans yet, though.