should Affine2x3.dx/dy be integers instead of Fixed 16.16?

[anthrotype]

@Lorp noted on MPEGGroup/OpenFontFormat#20 (comment)

The table at line 170 defines an Affine2x3 matrix with two translation elements, dx and dy. It it intentional that these are VarFixed (16.16) rather than VarFWord (16-bit integer)? It seems to imply that a renderer needs to keep track of fractional point locations.

In glyf table the component x and y offsets are integers, just like the simple glyph point coordinates are. Also in this draft spec, the gradients' end points are encoded as integers (VarFWORD).
Allowing fractional point locations as result of PaintTransform would be inconsistent with that.

[PeterConstable]

The final results at some point in derivation needs to be integral design units. The spec should probably be clear as to when: is it as each paint is composed with its parent, or only after the entire graph has been composed?

As for composing only a transformed src with the parent, note that the 2x2 elements must be fractional. Suppose the transform result is immediately rounded to integers. Having dx, dy be fractional means that they can affect the outcome of rounding. If they are integers, they cannot.

[rsheeter]

It seems to imply that a renderer needs to keep track of fractional point locations.

Agreed. This is already true when rasterizing and when computing variations. It is desirable when computing a chain of transforms.

The final results at some point in derivation needs to be integral design units

This is downstream of design space; we've moved on to the rasterizers coordinate system and we aren't coming back to design space.

[PeterConstable]

Except that the rasterizers are working with a particular PPEM, whereas the font data is defined in design units.

[Lorp]

@rsheeter Are you saying that composite glyphs (glyf table) are composed in the rasterizer coordinate system? Thus you could in effect get a 2x ppem by using a 0.5 scale transform.

[Lorp]

we've moved on to the rasterizers coordinate system

Technically there may not be a rasterizer. It seems to me to be an innovation that composite decomposition introduces fractions.

[Lorp]

@rsheeter the chaining argument is persuasive. If 100% compatibility between a COLR-style glyph stack and a glyf-based composite glyph is desired (including the potentially common case of representing the b/w fallback glyph using identical base glyphs), the 16-bit glyf matrix values can be used, padded with zeroes from F2.14 or DWord to 32-bit Fixed.

[behdad]

Non-integer coordinates are already in the format, via transformed composite glyphs in glyf table, non-integer numbers in CFF/CFF2, as well as arbitrary decimal numbers in SVG, as well as glyph variations.