TTF compilation: off-by-one points and composite bounds when compiling with --round-instances vs. compiling without #593
Comments
madig
changed the title
|
If I insert the following into ufo2ft's if not isinstance(glyph, StubGlyph):
for contour in glyph:
for point in contour:
point.x = otRound(point.x)
point.y = otRound(point.y)
for component in glyph.components:
t = component.transformation
component.transformation = t.__class__(
*[*t[:4], otRound(t[4]), otRound(t[5])]
)... the bounds issue seems to be fixed. The points issue remains. Maybe I need to doctor the points before they reach cu2qu. |
|
Todo:
|
|
The component's x and y offsets need to be rounded to integer when the glyf component is being created in the ttGlyphPen, so that the bounds of composite glyphs that contain shifted components are computed the same with/without rounded coordinates. That's easy to fix in fonttools, and I think you're already on it. As for the 1-point differences in the off-curve points, that's something we can't do much about. Cu2qu works internally with floats. There's lot of operations on floating points that make so that, if cu2qu is passed two UFO instances where one was rounded beforehand (thus contains ints) and another where coordinates are left as floats, then the result will inevitably be slightly different, imperceptibly so when looking at the converted, still unrounded float coordinates; but sometimes off-by-one when these are rounded for compiling a TrueType glyf table. The current default behaviour of fontmake is to not apply rounding to UFO instances' geometry, unless I suggest we close this as wont-fix. |
|
actually, maybe the change to unconditionally round the component's offsets in ttGlyphPen is not a good idea, and keeping them as floats like the rest of glyphs coordinates (until they are finally rounded by glyf compile method) is better. We just need to document that --round-instances may slightly change the generated output TTFs. |
|
We are not discussing here whether rounding is necessary or not for TrueType, since of course glyf must only contain integer coordinates and components' offsets. What the --round-instances option controls is when the rounding occurs: i.e. before the conversion to quadratic or at the very end upon compiling the glyf table. The latter is the current default and I am not willing to change that. If you opt in to using --round-instances option, then you are accepting that the TTFs generated from such rounded UFO instances may be slightly different (imperceptibly but enough to notice in a TTX diff) than those generated from UFOs without the option. |
|
Ok... will add |
…sets googlefonts/fontmake#593 This test currently fails. The compositeGlyph.xMax is set to 281, but it should be 282.
|
I'll keep this open while I investigate this issue further. I suspect we also need to change to the way glyph bounding boxes are calculated in ufo2ft.outlineCompiler when UFO contain float coordinates. |
Fixes googlefonts/fontmake#593 The input UFO glyphs may contain float coordinates. Instead of computing the bounding boxes from the UFO glyphs, calculcate them based on the compiled TTGlyph or CFF CharString objects which have already been rounded off to integer. This way, the hmtx.lsb will correctly match the glyph xMin, even in presence of an input UFO with float coordinates.
…sets googlefonts/fontmake#593 This test currently fails. The compositeGlyph.xMax is set to 281, but it should be 282.
The
glyftable only supports integer coordinates and bounds. Therefore, adding--round-instanceswhen interpolating TTFs should make no difference because both instantiator, ufo2ft and fonttools should use the same rounding method. Using the switch however leads to several point coordinates and composite (not outline glyphs?) bounds being off by one.RoundInstancesTest.zip
TTX diff (
aandbare outline glyphs,cis a composite):The text was updated successfully, but these errors were encountered: