Variable Components for COLRv1

[justvanrossum]

In short A: Variable Components are components which can specify the variation space location for the glyph they reference.
In short B: it's similar to Smart Components in Glyphs.

As some of you know, I've been working with @JeremieHornus / @BlackFoundryCom on a proposal to add "Variable Components" to OpenType:

• https://github.com/BlackFoundryCom/variable-components-spec

We've since found out that this idea has a lot in common with COLRv1 (as discussed in #88), and are now exploring the idea of proposing to add Variable Components to COLRv1.

Our idea currently is to add PaintLocation, which specifies an array of (axisIndex, axisValue) pairs, and a corresponding PaintVarLocation, where axisValue is variable.

Here's a very quick sketch of what these new Paints could look like:

struct Coordinate
{
  uint16     axisIndex;
  F2DOT14    axisValue;
};

struct VarCoordinate
{
  uint16     axisIndex;
  VarF2DOT14 axisValue;  // (edited)
};

struct PaintLocation
{
  uint8                  format; // = 21 ???
  Offset24<Paint>        src;
  ArrayOf<Coordinate>    coordinates;
};

struct PaintVarLocation
{
  uint8                  format; // = 22 ???
  Offset24<Paint>        src;
  ArrayOf<VarCoordinate> coordinates;
};

The values in the coordinates array override the global variation space location coordinates. Axis values for axes not referenced in the coordinates array are left alone.

I hope this is a good start for further discussion.

[rsheeter]

Ty for the sketch. Do we have any sense of how this model compares in size to VarC?

override the global variation space location coordinates

I immediately wonder if you want the option to offset from global as well as to just replace.

[justvanrossum]

Do we have any sense of how this model compares in size to VarC?

Not yet: we can't build trial fonts without 32-bit VarStore in fonttools (fonttools/fonttools#2279).

override the global variation space location coordinates

I immediately wonder if you want the option to offset from global as well as to just replace.

As a distinct feature, this hasn't occurred to me. But the effect can be achieved with the "override" behavior: the variable component can itself be variable on that axis, and override the value for the same axis for the referenced glyph, effectively remapping the axis.

[behdad]

Not yet: we can't build trial fonts without 32-bit VarStore in fonttools (fonttools/fonttools#2279).

I hope to have enough by end of today to unblock you.

I immediately wonder if you want the option to offset from global as well as to just replace.

Not really. The variation of this value provides that.

[behdad]

Not yet: we can't build trial fonts without 32-bit VarStore in fonttools (fonttools/fonttools#2279).

I hope to have enough by end of today to unblock you.

This should get you going: fonttools/fonttools#2279

[justvanrossum]

Fantastic, @behdad, thank you!

[rsheeter]

The values in the coordinates array override the global variation space location coordinates

Nit: we should spell out behavior if multiple coordinates specify the same axisIndex.

[justvanrossum]

Nit: we should spell out behavior if multiple coordinates specify the same axisIndex.

Perhaps it's better to disallow it. I don't see how it is useful.

[behdad]

Perhaps it's better to disallow it. I don't see how it is useful.

Disallowing is typically too harsh. Call it undefined if same axis is set multiple times to different values. And spec the array as sorted on axisIndex.

[rsheeter]

(So I don't forget) In playing with the test font changing the array of coordinates to an array of offset24 to coordinate resulted in 15+% reduction in filesize because while the full set of coordinates was often unique each individual one often wasn't.

[behdad]

I tried prototyping this. The FontTools side was simple:

fonttools/fonttools#3262

The HarfBuzz side however is proving to be impossible to implement given our abstractions. I'll try to elaborate more on the issue:

harfbuzz/harfbuzz#4384