Would it be possible for glyphs to round coordinates in interpolated fonts so that stems have consistent widths. Very often stems that should be exactly the same width, are 1 unit thinner or one unit wider in interpolated fonts. That of course is due to coordinates being rounded mathematically correctly but wrongly in terms of stem consistency. My suggestion would be for glyphs to somehow know what a stem is in a letter, in the master fonts, and then output consistent stems in the interpolations. The stems that are meant to be different due to optical adjustments, could just be ignored, that is, if they don’t have the standard stem width. This would save a lot of time in production, since we wouldn’t have to manually fix stems in the interpolated fonts, which is a big chunk of time in big families.
That is an inherent problem of interpolation. Should be rare though. Can you send me the file at res (at) (this website without www)?
But why do you round at all? Add an instance custom parameter for Grid Spacing, and set it to something low like 0.1 for an extra decimal in your coordinates. You may want to increase the sizes of your alignment zones by 1 then.
Rainer, Rui and me are working on this together. I’ll send you the Glyph-document. Please see if you can do something. Not sure how the Grid-spacing could work.
I agree that a great future function in Glyphs could be that each interpolated weight gets corrected if rounded to something else than the stem width value.
Sorry some how I missed your reply 190 days ago!
Do you mean we can actually have nodes with non-integer coordinates? That is totally new to me, I always thought in font world only whole number existed. Is there any drawback of setting the Grid Spacing to a value under 1? Can you explain how that is possible, or how that is translated in the font files with 1000UPM?
I don’t know of any.
PostScript has a div statement. The values are stored as large integers but divided by whatever the div statement stipulates. This is still possible in CFF/OpenType fonts.
Does UFO support that?
Does hinting deal well with it?
I wonder why the possibility of working non-integers hasn’t been available before Glyphs than. Or was it?
Has always been possible, e.g., in FontForge. Just FLS could not do it. Fontographer allowed you to work with decimals, but would only export rounded integers.
Not so rare as you might think. It happens quite often that the interpolated alignment zones are too small. It might be wise to make them always 1 unit larger then needed!?
Making them one unit bigger is usually a good idea.
Update on this topic:
There are two possible incompatibilities:
- PDF generation in Quark XPress
- Some old printer drivers (e.g., the BRScript drivers)
The problem is: the outlines suddenly show a visible kink at the starting point. I suspect that these renderers round the relative coordinates for each segments, adding to the total rounding error with each segment until they hit the closepath statement, where there is already a significant distance between first and last point.
And for hinting, the zones cannot be snug to the paths. You will usually need to add 1 unit to the size of the zones. That was the main reason I wrote my BlueFuzzer script.