TTFAutohint seems incorrectly detecting whether a rasterizer supports Y-axis anti-aliasing.
Belleve Invis
Posts: 269
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
cc. @Werner Lemberg
0
Comments
-
What is RS2? Please give more details.0
-
Werner Lemberg said:What is RS2? Please give more details.
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.1 -
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.
0 -
@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.0 -
@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.
0 -
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 test1 -
@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...2 -
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.0 -
@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.0 -
[DUPLICATED]0
-
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)
0 -
@Werner Lemberg
Do you have a doc about them?
I saw "edges", so where can I find correspondences from edges to points?0 -
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.0
Categories
- All Categories
- 43 Introductions
- 3.7K Typeface Design
- 803 Font Technology
- 1K Technique and Theory
- 620 Type Business
- 444 Type Design Critiques
- 542 Type Design Software
- 30 Punchcutting
- 136 Lettering and Calligraphy
- 83 Technique and Theory
- 53 Lettering Critiques
- 484 Typography
- 302 History of Typography
- 114 Education
- 68 Resources
- 499 Announcements
- 80 Events
- 105 Job Postings
- 148 Type Releases
- 165 Miscellaneous News
- 270 About TypeDrawers
- 53 TypeDrawers Announcements
- 116 Suggestions and Bug Reports