Potential issue with Type 1/CFF StdHW and StdVW fields

[rimas-kudelis]

While reading and learning a bit about PostScript hinting, I think I discovered a little potential issue in UFOv3. The issue is that there's no official way to explicitly PostScript StdHW and StdVW fields should I want to

The UFO spec currently says:

3. The Type 1/CFF StdHW and StdVW fields can be derived by taking the first value from the postscriptStemSnapH and postscriptStemSnapV lists.

I don't think this algorithm may always be sufficient. The reason is that the Type 1 spec chapter 5.9 (page 42 (or 48, depending on your PDF reader)) specifies the following two things:

The entry StdHW is an array with only one real number entry expressing the dominant width of horizontal stems (measured vertically in character space units).

and:

The entry StemSnapH is an array of up to 12 real numbers of the most common widths (including the dominant width given in the StdHW array) for horizontal stems (measured vertically). These widths must be sorted in increasing order.

So, according to the Type 1 spec, I have to list stem widths in increasing order in stemSnapH, but I'm also supposed to specify the dominant width of the stems in stdHW. If my dominant stem width is not the lowest, there seems to be no way to specify it in UFO.

Same applies for StemSnapV and stdVW.

I'm not sure how much of a problem this is. Maybe the CFF rasterizer doesn't care at all? However, if it is indeed problematic, I think there are two ways this could be alleviated:

1. Adding postscriptStdHW and postscriptstdVW fields to fontinfo.plist spec or.
2. Going into a bit more detail in the note quoted above and explicitly mentioning that postscriptStemSnapH and postscriptStemSnapV may not be sorted in increasing order and font compilers may have to rearrange these numbers when compiling the UFO font to satisfy the constraints set by the respective specs, but meanwhile authoring tools should preserve the original order as specified by the designer and not overwrite it. Or something like that.

[benkiel]

Hey @rimas-kudelis: yes, this has been something that has always been a bit of a mismatch, but the only PS hinting tool (afaik), Adobe's otfautohint (and psautohint before that) doesn't use StdHW or StdVW if I understand the code, so this doesn't really actually have a pratical implication. @skef, if they have time, can provide some clarity here (or tell me that we need to add to fontinfo

[skef]

A few notes:

• I believe it is true that the autohinters don't use StdH/VW values (it's been a while since I was deep in that code). However, this is because they're intended more for the rendering side than the hinting side of things.
• In general, when testing with different StdH/VW or StemSnapH/V values with the same glyphs, our general impression is that you see at most a slight change. It doesn't seem like current rasterizers rely on values much when making decisions that wind up clearly visible.

So, in summary the standard stem width values are something we try to get right but then don't worry about too much. I can't remember running into a case where we had bad output, changed just one of those values, and wound up with good output, for example.

[rimas-kudelis]

I see, fair enough, I guess. Thanks for elaborating!

[benkiel]

Tagging this for UFO4, open to a public lib key also

[rimas-kudelis]

If, like you both said, changes to Std[HV]W have no effect on rasterizers, maybe this should just be closed?