Deprecated ttfautohint flag

[paride]

While building the ttf font I'm getting this warning:

Warning: Option `-w' is deprecated!  Use option `-a' instead
master_ttf/Hack-Regular.ttf - successful hinting with ttfautohint
Warning: Option `-w' is deprecated!  Use option `-a' instead
master_ttf/Hack-Bold.ttf - successful hinting with ttfautohint
Warning: Option `-w' is deprecated!  Use option `-a' instead
master_ttf/Hack-Italic.ttf - successful hinting with ttfautohint
Warning: Option `-w' is deprecated!  Use option `-a' instead
master_ttf/Hack-BoldItalic.ttf - successful hinting with ttfautohint

This is my version of ttfautohint:

$ ttfautohint --version
ttfautohint 1.8.1
Copyright (C) 2011-2017 Werner Lemberg <wl@gnu.org>.
License: FreeType License (FTL) or GNU GPLv2.
This is free software: you are free to change and redistribute it.
There is NO WARRANTY, to the extent permitted by law.

Nothing harmful or urgent, but fixing it would be a nice improvement for the next release.

[chrissimpkins]

Thanks Paride. Here is what I am seeing in the v1.8.0 changelog for the change to ttfautohint:

A new option -a has been implemented to select the stem width mode for the three rendering targets (grayscale, GDI ClearType, DW ClearType). This supersedes option -g, which is now deprecated.

and here is the documentation on the new -a option:

--stem-width-mode=string, -a string

ttfautohint provides three different algorithms for computing horizontal stem widths and the positioning of blue zones.

‘natural’: No adjustments to stem widths, discrete blue zone positioning. This is what FreeType uses for its ‘light’ (auto-)hinting mode. Essentially no glyph shape distortion, low contrast.

‘quantized’: Both stem widths and blue zone positions are slightly quantized to take discrete values. For example, stem values 50, 51, 72, 76, and 100 would become 50, 74, and 100 (or something similar). More glyph shape distortion but increased contrast.

’strong': If active, stem widths and blue zones are snapped and positioned to integer pixel values as much as possible. This gives high contrast, but glyph shape distortion can be significant.

These three algorithms are mapped onto three possible rendering targets.

Grayscale rendering, with or without optimization for subpixel positioning (e.g., Android).

‘GDI ClearType’ rendering: the rasterizer version, as returned by the GETINFO bytecode instruction, is in the range 36 <= version <= 38 and ClearType is enabled (e.g., Windows XP).

‘DirectWrite ClearType’ rendering: the rasterizer version, as returned by the GETINFO bytecode instruction, is >= 39, ClearType is enabled, and subpixel positioning is enabled also (e.g., Internet Explorer 9 running on Windows 7).

GDI ClearType uses a mode similar to B/W rendering along the vertical axis, while DW ClearType applies grayscale rendering. Additionally, only DW ClearType provides subpixel positioning along the x axis. For what it’s worth, the rasterizers version 36 and version 38 in Microsoft Windows are two completely different rendering engines.

[Note that the GDI framework on Windows 10 no longer uses B/W rendering along the vertical axis; we consequently treat it as DW ClearType also. We test this by looking at bit 11 of the GETINFO instruction, which was introduced in rasterizer version 40.]

The command line option expects string to contain exactly three letters with possible values ‘n’ for natural, ‘q’ for quantized, and ‘s’ for strong stem width and positioning mode. The first, second, and third letter correspond to grayscale, GDI ClearType, and DW ClearType rendering, respectively. The default value is qsq, which means that the ‘quantized’ algorithm gets used for grayscale and DW ClearType, and the ‘strong’ algorithm for GDI ClearType. For example, to use the ‘natural’ algorithm for all three rendering targets, use option -a nnn.

@lemzwerg The documentation for the lowercase -w option appears to be gone as of the v1.8.1 release. Is there a comparable conversion from the old -w G setting to the new -a option or should we be modifying and visually testing the glyphs due to this change?

[chrissimpkins]

@paride we are currently pinned at v1.7 of ttfautohint in our upstream build.

https://github.com/source-foundry/Hack/blob/03ad8791745aa4985db0b0c71a1c9bde214b485f/tools/scripts/install/ttfautohint-build.sh#L42

Possible to pin your build on this version until this issue is sorted out? This may require some testing (manual visual) to confirm that we get this right. Let's see what Werner has to say when we hear back.

[lemzwerg]

As already observed, it's just a harmless warning because the new flag is more versatile. -w G is translated to -a qsq. If in doubt, simply call ttfautohint with the -I -w XXX flags and look into the created font to check what the -w XXX flag gets translated to.

[paride]

@chrisclauss pinning to ttfautohint 1.7 is not so easy, as that version has never been Debian packaged (we jumped from v1.6 to v1.8). It's probably better to have a look at how the font hinted with v1.8.

For the record, Hack 3 is finally coming in Debian. I can now build the ttf fonts, but for the web fonts there still one missing dependency: sfnt2woff-zopfli. I already prepared the Debian package for it and waiting for it to be sponsored, accepted and uploaded.

[chrissimpkins]

@lemzwerg Thanks Werner. Will look into the -I -w XXX flags. You mean to examine a ttx dump of the assembly code and diff against our current build approach with v1.7?

[chrissimpkins]

@paride OK, that is fine Paride. I suggest that you keep the -w G flag for now since it has not been removed from the v1.8.1 release of ttfautohint. I am not likely to get to this issue before we push v3.003 and will put this on for work in the v3.004 release. It's not clear (to me) yet what this change might do so if you decide to move forward with Werner's suggestion to transition to -a qsq at this point, I would recommend that you perform some manual, visual QA on the shapes (at the very least in the ASCII set) before you push to the Debian package. Will update here when we have more information about the change. I am assuming that we can expect that the -w flag will be available to maintain backwards compatibility until a v2.0 release of ttfautohint emerges.

And thanks for noting this Paride. We haven't made the move to ttfautohint v1.8.1 yet so the deprecation warning was not showing for us. I am a bit gun shy with ttfautohint changes after the v3.001 release issue that we encountered :) There is not a simple approach to evaluate for changes. The text dumps of these binary OT tables are tens of thousands of lines in length per font file and the diffs can be lengthy...

[lemzwerg]

@chrissimpkins: No, I mean that you literally look into the (binary) output TTF with an editor. Search for 'ttfautohint' and check the listed command line arguments. You can of course do the same with the output of ttx.

[chrissimpkins]

@lemzwerg ah, got it. OK thanks for your help Werner. I really appreciate it.