Conflict with COLRv1 transforms… merge the proposals?

[Lorp]

Nice to see this proposal.

I wanted to check you are aware of another OpenType format proposal relating to components, namely my own colr-gradients-spec/Rotated components suggestion to add component transforms to the COLRv1 format. The idea behind it is that COLRv0 layers are already rather like components, and that, by allowing transforms in each included glyph layer, we can make COLRv1 a superset of the capabilities of old-style "glyf" composites. While making the colour Muybridge horse, I realized that there was a common case where the fallback b/w glyph references exactly the same glyph components as the COLR glyph layers, and so it seemed sensible to give COLR the same capabilities for transformation as glyf has, rather than force this case to perform all transforms in glyf to new transformed components, then layer those transformed composite glyphs in COLR. For good measure, I proposed flags to handle explicit rotation in degrees and @jfkthame added shear in degrees too. I imagined in the future controlling this rotation angle with an axis. Also, one day, I imagined this improved transform structure being incorporated into an updated glyf spec, to avoid people using the COLR apparatus unnecessarily — @behdad believes clients should be free to ignore COLR/CPAL tables entirely if they have no use for colour.

So that’s the background to COLRv1 transforms. The proposal seems to have met with approval from @PeterConstable and @rsheeter, among others, and is well on the way to being proposed as an update to OpenType.

You can probably already see the issue I am worrying about, namely that, with your variable component idea and good old glyf, it makes THREE different ways to represent composite glyphs. I don’t think this is a good outcome. So I wonder what your thoughts are. I guess we can think of:

• merging your component variations with the COLRv1 transform to use the same structure in both
• removing transforms from COLRv1 for now, while we come up with a unified transform structure

In any case I would be pleased if you would take a look through the COLRv1 transform discussion, and add some comments. It would be a shame to do things differently without a clear reason.

[JeremieHornus]

Thanks for pointing to this @Lorp Indeed these should be unified, we don't need two ways of representing the same thing.

Note: we came up here with a 'center of transformations' instead of a 'center of rotation' only.

I don't have strong feeling about how we should proceed but since they are very similar things, they should be described only once.

[justvanrossum]

Ugh, the fact that COLRv1 adds it's own way of doing component transformations completely escaped me.

I currently have a hard time to understand why this is even part of the COLRv1 proposal, as "better component transformations" should be completely orthogonal to "better color capabilities".

[justvanrossum]

Starting to understand a bit more: a color glyph can (should?) be seen as a composite, where each component has paint properties, as well as a transformation. But conceptually COLR (at least v0) is an alternative to glyf: "enable color, use the COLR table instead of glyf or CFF or CFF2.

I now better understand "sanctioning COLR table as glyf2 for component use" comment, but that implies COLR should become the default, even if no color is requested.

Our proposal works differently, as it adds information to the existing glyf component structure.

If COLRv1 would add local designspaces for components, it would be a functional superset of our proposed VarC table. (Ignoring possible differences in how transformations work for now.) With the added benefit that it would then also be compatible with CFF and CFF2, which VarC currently isn't.

[rsheeter]

I currently have a hard time to understand why this is even part of the COLRv1 proposal

Because emoji repeat composite colored parts basically :)

If COLRv1 would add local designspaces for components, it would be a functional superset of our proposed VarC table. (Ignoring possible differences in how transformations work for now.)

After a first skim through it looks to me like the transform capabilities of COLR would be sufficient. I don't yet adequately understand what "add local designspaces for components" concretely means.

[justvanrossum]

I don't yet adequately understand what "add local designspaces for components" concretely means.

Very roughly, it means that a component can set the variation space location for the glyph it is referencing. So if the referenced glyph implements variations for some (possibly hidden) axes, the component can specify the axis values for those axes (or any axis really).

[JeremieHornus]

it means that a component can set the variation space location for the glyph it is referencing

@rsheeter This is actually the main point of our proposal: variablity is not accessible at font level only, but composite glyphs can become "users" of other variable glyphs; these other ('base') glyphs (glyphs the component is referencing to) have their own local designspace independant of font variation axes.