Stems for hinting: two conflicting issues

Context

I am setting up a Glyphs document that is 7 masters, brought in from 7 UFOs that were previously set up to export static fonts. The goal is to set up this Glyphs document so that it exports OTFs with as few differences as possible to the already-retailing OTFs that were previously exported from the UFOs, with AFDKO.

These masters have overlaps removed and are not fully compatible, but I’ve put them into a single Glyphs document to make it easy to control shared information. To make this work, the Custom Parameter “Enforce Compatibility Check” is set to 0.

The underlying reason for the conversion to Glyphs is to help with some language extension work in these fonts. I am doing this for a client, for already-published fonts, so I have less flexibility than I would if I were simply building something new.

Problems

The UFOs represent a range of weights in a low-contrast type design. The thin styles are set up with only a couple of stems declared. The bolder styles have more variation between stem widths, so they have 4 horizontal and 4 vertical values declared.

“Stems can’t be zero”

By default, Glyphs filled in empty values in the thinner styles with 0 values. However, this blocks the export, with the message “Stems can’t be zero.”

To get around this, I simply duplicated the last values, where they were otherwise 0. The Thin style only has vertical stems of 39, so I just put that value four times.

This allows the build to happen, but…

Repeated stem values are entirely excluded from exports

When I inspect the resulting CFF tables of exported OTFs, the StemSnapH or StemSnapV values get omitted, if that style has any repeated stem values in the associated master.

What I would hope for

If a stem value is 0, and stems don’t need to be interpolated into instances, the stem value of 0 could be ignored.

If a stem value is repeated in an export, it could be simply skipped, rather than causing all stem values to be excluded.

What should I do?

I know that your hinting documentation recommends “as few values as possible.” This seems reasonable, but I will have to ask my client if it is acceptable to them to reduce things down to two values, but they may have their own opinions.

Otherwise, it seems like if I want to match the existing values, I will need to split up the masters into 7 separate Glyphs documents, but… that would be a bummer.

Is there some solution I’m missing? I’ll send the documents if I get approval to do so.

Thanks for any pointers or insights!

I have a look. setting it to zero might work in that specific case, but that is to fragile if you start to interpolate.

I just checked the code. And Glyphs was writing out all stems. And the library that is compiling the CFF that is used in Glyphs 3 is skipping the StemSnapV when there is a duplicate. I fixed that. Thanks for the report.

1 Like

Wow, amazingly fast fix – thank you!

I guess that adjusted library will probably appear in a Glyphs Beta update, in a few days, yeah?

Also, just to make sure I understand correctly: in my case, you do recommend just repeating values, instead of setting 0 values… correct? And then, the repeated values will probably just get de-duplicated in the CFF table build?

Yes.

Yes.

1 Like

Awesome, thank you, Georg!