TTFAutohint seems incorrectly detecting whether a rasterizer supports Y-axis anti-aliasing.

Belleve Invis

It actually detects whether a rasterizer supports fractional advance instead of y-axis anti-aliasing, however GDI in RS2 supported Y-AA without fractional advance.

cc. @Werner Lemberg

Werner Lemberg

What is RS2?  Please give more details.

Belleve Invis

Werner Lemberg said:

What is RS2?  Please give more details.

The latest Windows 10's update (Creators').
In this version GDI get the support of Y-axis anti-aliasing, without fractional advance width. And I've observed that TTFA applied the old GDI hinting strategy to this novel environment, causing it being incorrect.
ps. How can i raise a bug to TTFA? It does not have GitHub or things like that.

Werner Lemberg

ttfautohint --help shows the following at the very end:

Report bugs to: freetype-devel@nongnu.org

so you should do this

Please show a (readable) snapshot of the data section of this page so that I know exactly the environment parameters.

Belleve Invis

@Werner Lemberg

Perhaps asking Greg directly about the GETINFO[] results would be easier (or... infer that by reading the Windows source?)
I'd like to tell you asap.

Belleve Invis

@Werner Lemberg
There are no web browsers still using GDI so I used notepad to show "0123456789:;" one character per line and this is the results. You can see that subpixel positioning is off while symmetrical smoothing is on.

Werner Lemberg

Thanks for the details.  This issue now fixed in the git repository of ttfautohint.  The previous code for the smooth/strong algorithm detection was about five years old, predating TrueType interpreter v40, which introduced a new flag for directly testing whether symmetric smoothing is available.

And please test

Belleve Invis

@Werner Lemberg

And, do you have any plan to export TTFA's "decision" directly into some... plain format?
Currently I am figuring out how to combine TTFA's decision with VTTTalk...

Werner Lemberg

What do you mean with plain format?

Here is a comment in ttfautohint's source code that explains what it exactly does.

ttfautohint provides two different functions for stem width computation and blue zone rounding: `smooth' and `strong'. The former tries to align stem widths and blue zones to some discrete, possibly non-integer values. The latter snaps everything to integer pixels as much as possible.

We test ClearType capabilities to find out which of the two functions should be used. Due to the various TrueType interpreter versions this is quite convoluted.

version <= 35: this version predates ClearType -> smooth

version 36, 37: use bit 6 in the GETINFO instruction to check whether ClearType is enabled; if set, we have (old) GDI ClearType -> strong, otherwise grayscale rendering -> smooth

version 38, 39: if ClearType is enabled, use bit 10 in the GETINFO instruction to check whether ClearType sub-pixel positioning is available; if set, we have DW ClearType -> smooth, else GDI ClearType -> strong

version >= 40: if ClearType is enabled, use bit 11 in the GETINFO instruction to check whether ClearType symmetric rendering is available; if not set, the engine behaves like a B/W renderer along the y axis -> strong, else it does vertical smoothing -> smooth

ClearType on Windows was introduced in 2000 for the GDI framework (no symmetric rendering, no sub-pixel positioning). In 2008, Windows got the DirectWrite (DW) framework which uses symmetric rendering and sub-pixel positioning.

Note that in 2017 GDI on Windows 10 has changed rendering parameters: it now uses symmetric rendering but no sub-pixel positioning. Consequently, we treat this as `DW ClearType' also.

Belleve Invis

@Werner Lemberg
That's another issue: Could TTFA provide a text format of its "decisions" about how to alter the glyphs: like anchor what point to what position, link what two points into a stem, etc...
MS has some plan about making VTT the standard, exchangeable format to describe TT hinting.

Belleve Invis

[DUPLICATED]

Werner Lemberg

If you enable the --debug command line option you can see the 'high-level' decisions done by ttfautohint, e.g.,

glyph 23 (two)
==============

size 10
-------

latin horizontal edge hinting (style `latn_dflt')
  BLUE_ANCHOR: edge 0 (opos=0.47) snapped to 0.00, was 0.47 (anchor=edge 0)
  LINK: edge 1 (opos=1.06) linked to 0.59, dist was 0.59, now 0.59
  BLUE: edge 5 (opos=6.53) snapped to 6.00, was 6.53
  LINK: edge 4 (opos=6.06) linked to 5.53, dist was -0.47, now -0.47
  SERIF: edge 2 (opos=2.02) serif to 1 (opos=1.06) aligned to 1.55  
  SERIF_LINK1: edge 3 (opos=5.02) snapped to 4.50 from 2 (opos=2.02)

Belleve Invis

@Werner Lemberg
Do you have a doc about them?
I saw "edges", so where can I find correspondences from edges to points?

Werner Lemberg

Sorry for the late reply.

The debug output also produces table of edges (and its linked segments).

An explanation of edges and segments is given in the ttfautohint documentation.