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

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


  • What is RS2?  Please give more details.
  • Belleve InvisBelleve Invis Posts: 184
    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.
  • ttfautohint --help shows the following at the very end:

    Report bugs to:

    so you should do this :smile:

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

  • Belleve InvisBelleve Invis Posts: 184
    @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 InvisBelleve Invis Posts: 184
    @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 LembergWerner Lemberg Posts: 33
    edited June 22
    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 :smile:
  • Belleve InvisBelleve Invis Posts: 184
    @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...
  • 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 InvisBelleve Invis Posts: 184
    @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 InvisBelleve Invis Posts: 184
    edited June 23
  • 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 InvisBelleve Invis Posts: 184
    @Werner Lemberg
    Do you have a doc about them?
    I saw "edges", so where can I find correspondences from edges to points?
  • 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.
Sign In or Register to comment.