Open rimas-kudelis opened 1 week ago
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
A few notes:
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.
I see, fair enough, I guess. Thanks for elaborating!
Tagging this for UFO4, open to a public lib key also
If, like you both said, changes to Std[HV]W
have no effect on rasterizers, maybe this should just be closed?
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
andStdVW
fields should I want toThe UFO spec currently says:
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:
and:
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 instdHW
. If my dominant stem width is not the lowest, there seems to be no way to specify it in UFO.Same applies for
StemSnapV
andstdVW
.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:
postscriptStdHW
andpostscriptstdVW
fields to fontinfo.plist spec or.postscriptStemSnapH
andpostscriptStemSnapV
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.