You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
This issue is a correction to what I said in #1141. Specifically, this comment (from me) was wrong:
With StemSnap[H|V] these questions seem academic. You could have blends that change the order but there's no reason to. Probably better to just impose the narrower restriction that they must be sorted everywhere in the design space. And because alignment zones can't overlap, same with them.
If a designer simply puts the various salient stem sizes in the list in order for each master, then the rasterizer will work correctly for each master. The problem is that when the values interpolate for some other instance they won't (or may not) correspond to the stem size in that instance. For the interpolation to work correctly the size of stem A in one master needs to correspond to the size of stem A in each other master, and so on. I just didn't think this through enough in our earlier discussion.
I think the right way to fix this is how it was fixed for hinting stems (hstem/vstem): Require that the list be in sort order by size at the default location and allow the order to differ in other locations.
I've re-read through #1141 and I don't see any additional things we discussed that would warrant changes beyond this one.
Description
This issue is a correction to what I said in #1141. Specifically, this comment (from me) was wrong:
If a designer simply puts the various salient stem sizes in the list in order for each master, then the rasterizer will work correctly for each master. The problem is that when the values interpolate for some other instance they won't (or may not) correspond to the stem size in that instance. For the interpolation to work correctly the size of stem A in one master needs to correspond to the size of stem A in each other master, and so on. I just didn't think this through enough in our earlier discussion.
I think the right way to fix this is how it was fixed for hinting stems (hstem/vstem): Require that the list be in sort order by size at the default location and allow the order to differ in other locations.
I've re-read through #1141 and I don't see any additional things we discussed that would warrant changes beyond this one.
Page URL
https://learn.microsoft.com/en-us/typography/opentype/spec/cff2
Content source URL
https://github.com/MicrosoftDocs/typography/blob/live/typographydocs/opentype/spec/cff2.md
The text was updated successfully, but these errors were encountered: