Issue with StdHW and StdVW

[rrob...@adobe.com]

I noticed a minor issue  in fontinfo.plist PostScript values: there is no way to specify a value for the PostScript FontDict fields 'StdHW' and 'StdVW".

 The notes under this section do partly address this with note 3:

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

However, this is a fall-back rule, not the correct solution. The StdHW and StdVW are supposed to hold the most important H and V stem widths. These values would usually not be the smallest stem value in the StemSnapH and StemSnapV lists. The UFO spec does need a way to specify this number.

One way would be to add recognized keys  'postscriptStdHW' and 'postscriptStdVW'.

Another way would be to relax the rule that the stem widths in the StemSnap[HV] lists have to be ordered as in the CFF spec. A user could then put the most important stem width first in the list. A tool that does something with this list, such as building a CFF or Type1 font, would then need to sort it before using it.

Thoughts?

- Read Roberts

[Dave Crossland]

On Wednesday, 11 September 2013 00:30:19 UTC+2, rrob...@adobe.com wrote:
>
> I noticed a minor issue in fontinfo.plist PostScript values: there is no way to
> specify a value for the PostScript FontDict fields 'StdHW' and 'StdVW".
>

> One way would be to add recognized keys 'postscriptStdHW' and 'postscriptStdVW'.
> Another way would be to relax the rule that the stem widths in the StemSnap[HV]
> lists have to be ordered as in the CFF spec.

Of those 2 options I would prefer the 1st because it is simple and concise.

Since the private dict is a dictionary, why is it represented as a list?

[Tal Leming]

On Sep 10, 2013, at 6:30 PM, rrob...@adobe.com wrote:

> Another way would be to relax the rule that the stem widths in the StemSnap[HV] lists have to be ordered as in the CFF spec. A user could then put the most important stem width first in the list. A tool that does something with this list, such as building a CFF or Type1 font, would then need to sort it before using it.

For some reason this is how I interpreted the Type 1 spec. Unless there are objections, I'll clarify this in the UFO 2 and UFO 3 specs to say something like:

The most common stem width should be the first number in the list. The remaining items may be in any order.

Does that sound clear enough?

Thanks,
Tal

[Ben Kiel]

>> The most common stem width should be the first number in the list. The remaining items may be in any order.

My only question with this strategy comes from my reading of the Type 1 spec, which states that italics should not have a entry for StemSnapV, but should have a measurement for StdVW. If that's still the recommendation, it seems that having an entry for StdVW and StdHW is better than trying to have the end application guess how best to fill StemSnapV if there is only one value.

Best,
Ben

[rrob...@adobe.com]

I discussed this issue with one of the few people left at Adobe who still works on rasterizers, David Arnold. I now suggest that there should be a separate entry for StdVW. Summary of the discussion:

- You should not put StemSnapV array in Italic fonts. The most modern branches of the rasterizer will ignore the StemSnapV array if the font is italic, but some current rasterizers do not do so, and the the presence of this data causes more hinting problems than it solved.

- neither StemSnapH nor StemSNapV arrays are used  in rasterizers that support sub-pixel positioning, as is the case for LCD screens. However, they are still used for monochrome output, and by a lot of third party rasterizers.( aka in  printers).

- StdVW should be included in all fonts, as it is used to determine the default stem width, and thus controls how much stem-darking is applied if the vertical stem width is less than one pixel. If no StdVW is supplied, then the Adobe rasterizers use a value of 75.

No one remembers why the Type1 Spec says that StdVW should always be present. It can't have been for supporting stem darkening, as the T1 spec was written before the stem darkening logic was added to the Adobe rasterizers.

- Read Roberts

[Tal Leming]

Hi Read,

As for how these would be specified, is this what you are thinking?

postscriptStdHW -- integer or float -- A number defining the dominant horizontal stem width in the font. Corresponds to the Type 1/CFF StdHW field.
postscriptStemSnapH -- list -- List of horizontal stems sorted in the order specified in the Type 1/CFF specification. Up to 12 integers or floats are possible. This corresponds to the Type 1/CFF StemSnapHfield.
postscriptStdVW -- integer or float -- A number defining the dominant vertical stem width in the font. Corresponds to the Type 1/CFF StdVW field.
postscriptStemSnapV -- list -- List of vertical stems sorted in the order specified in the Type 1/CFF specification. Up to 12 integers or floats are possible. This corresponds to the Type 1/CFF StemSnapVfield.

I'm wondering if there should be a statement about the inclusion of the dominant stem widths in the lists. The Type 1 spec says that it is included in the list of all stems. We don't usually place requirements like that on data in the UFO. It could add an informative note below the section that informs compilers that they are responsible for making sure that the value is in there. But, if the dominant width does't have to be in the list and the user maxes out the number of values in the list, that would be a problem. Hm.

I'm thinking of removing the sorting statement for the lists. It could be interpreted as a requirement and anything that is easily automated like this shouldn't be a requirement of human editable files. Sorting could be the responsibility of the compiler.

Ben, does this line up with what you were thinking before?


These new fields would be added in UFO 4. I have been thinking about a way to make new fields possible in older versions of the UFO via the lib for situations like this. I'll write a separate email about that when my thoughts are more fully formed.

Thanks,
Tal

> --
> You received this message because you are subscribed to the Google Groups "Unified Font Object Specification" group.
> To unsubscribe from this group and stop receiving emails from it, send an email to ufo-spec+u...@googlegroups.com.
> For more options, visit https://groups.google.com/groups/opt_out.

[Ben Kiel]

Hey Tal,

That does line up with what I was thinking before.

I don't have a good solution for adding the dominant stem to the list, but an informative note saying that compilers will need to do some data checking and throw an error seems to be in the spirit of the spec.

Ben

[rrob...@adobe.com]

Hi Tal;

This looks like a good plan to me.

I agree that compilers should be in charge of checking data consistency. I favor in general allowing users to shoot themselves, as long as the system includes consistency checks at some point. Specifically, I would not enforce that the a dominant stem width be in the matching stem list when editing UFO data, or would I require that the list be sorted in any order.  I would expect a compiler to complain, bit not abort, if it finds the first situation, and to always sort the stem list in the second.

- Read