[psstemhist] Huge stem values reported for very thin designs

[miguelsousa]

The attached ZIP contains 3 fonts. The digit in the file name represents the average stem thickness of the glyphs. When I run this command psstemhist -a stem_*.otf on each of the fonts, excessively big numbers are reported for the two thinnest ones. Results below.

thin_stems.zip

stem_2.otf

Horizontal Stem List
count    width    glyphs
    1      699    [O]
    1      536    [o]
    1      526    [t]
    1      362    [H]
    1      320    [H]
    1      136    [t]

Vertical Stem List
count    width    glyphs
    2      217    [T]
    1      517    [O]
    1      399    [o]
    1      394    [H]
    1      335    [h]
    1      148    [t]
    1       89    [t]

stem_4.otf

Horizontal Stem List
count    width    glyphs
    1      699    [O]
    1      536    [o]
    1      526    [t]
    1      363    [H]
    1      321    [H]
    1      138    [t]

Vertical Stem List
count    width    glyphs
    1      519    [O]
    1      401    [o]
    1      396    [H]
    1      337    [h]
    1      219    [T]
    1      218    [T]
    1      149    [t]
    1       91    [t]

stem_8.otf

Horizontal Stem List
count    width    glyphs
    6        8    [H O T h o t]
    3        7    [O o t]

Vertical Stem List
count    width    glyphs
    7        8    [H O h o t]
    3        9    [O T o]

[miguelsousa]

psstemhist --version
2.3.0

[miguelsousa]

I just took a look at the O glyph in stem_2.otf. The height of the outer contour is 699 and the width is 517. So this explains a bit the values that the tool is producing, and makes me think that it's not "seeing" the inside contour for some reason.

[miguelsousa]

From https://github.com/adobe-type-tools/psautohint/blob/master/doc/AC.md

There are many thresholds used when evaluating stems, pruning, and finding the best values. The thresholds used throughout the program are just “best guesses” according to Bill Paxton.

Supposedly, the very minimum hinting a glyph will get is its bounding box values.

If no good hints are found use bounding box hints.

[iterumllc]

I'm going to be looking at this in the (relatively) near future but depending on how many heuristics need to be changed for very thin stems it might wind up being easier to provide a "pre-scale" option when generating stem info, which would scale the path elements up by N times and then scale the resulting stem data down by the same amount.

[iterumllc]

(OTOH it may be as simple as providing an option to adjust the equivalent of gMinDist, which is currently hard-coded to 7. We'll need a bit of experimentation to see whether very low values results in a lot of noise.)

[skef]

I'm not sure we'll wind up looking at this anytime soon, but the general solution for cases like this is to provide a means of overriding the many constants in afdko/otfautohint/hinter.py:dimensionHinter.