VarComposites

[behdad]

I've started implementing these. decompile() seems to work so far.

[justvanrossum]

You should probably run black.

[behdad]

Thanks. Will do every few commits.

[behdad]

@justvanrossum I have a question for you:

Currently I'm setting all transformation components on VarComponent, and flags controls which ones are compiled. This is a bit uneasy to work with since if client modifies the transformation components they also need to modify the flags. We cannot just compile transformation components smartly since they should all match across masters when compiling a variable font...

An alternative would be to NOT set attribute for those components that should not be compiled into the font. That would be inconvenient to use when working with the component though.

Can you advise which one you prefer?

[justvanrossum]

Currently I'm setting all transformation components on VarComponent,

Sounds good.

and flags controls which ones are compiled

Ideally, the flags would be computed autimatically based on the transformation data.

We cannot just compile transformation components smartly since they should all match across masters when compiling a variable font...

Couldn't a VF compiler take that into account and adjust accordingly?

[behdad]

We cannot just compile transformation components smartly since they should all match across masters when compiling a variable font...

Couldn't a VF compiler take that into account and adjust accordingly?

It can. A bit more work but doable indeed. Which then means, the glyf compiler should calculate flags based on presence of attributes only, and cannot drop components that have default value.

[behdad]

@justvanrossum This branch now has compile/decompile/toXML/fromXML.

It's a bit crude as axisIndices are retained as integers not tags. To convert to tags I need to pass fvar down to glyf compile/decompile, which is a bit inconvenient.

[justvanrossum]

the glyf compiler should calculate flags based on presence of attributes only, and cannot drop components that have default value

I don't follow. Ideally (I think), all fields would be present as attributes, but only those that don't have the default value get compiled into the binary.

[behdad]

Ideally (I think), all fields would be present as attributes, but only those that don't have the default value get compiled into the binary.

The problem is that the same flag controls whether variations for the transform components is encoded. So there are cases that eg. a translateX of 0 should be encoded, because it has variations. So the glyf-table compiler cannot just discard translateX of 0 automatically.

[justvanrossum]

Ah yes, now I get it. The variations in gvar have to match up.

[behdad]

Currently Glyph.decompile only takes the glyf table. Not sure how to pass fvar to it without changing API drastically.

[behdad]

Ah yes, now I get it. The variations in gvar have to match up.

Oh. If .flags is missing we can calculate it!

[justvanrossum]

Currently Glyph.decompile only takes the glyf table. Not sure how to pass fvar to it without changing API drastically.

Maybe table__g_l_y_f.compile() and table__g_l_y_f.decompile() can assign a reference to the ttFont for later use. It's a bit ugly, but then again: circular refs stopped being a big deal a long time ago, and I'm sure the API would have looked different if it were designed today... Or use a weakref.

[behdad]

circular refs

I'll try that. The cff table does it just fine.

[behdad]

Currently Glyph.decompile only takes the glyf table. Not sure how to pass fvar to it without changing API drastically.

Maybe table__g_l_y_f.compile() and table__g_l_y_f.decompile() can assign a reference to the ttFont for later use. It's a bit ugly, but then again: circular refs stopped being a big deal a long time ago, and I'm sure the API would have looked different if it were designed today... Or use a weakref.

Or I can just save the axisTags. That's all I need.

[justvanrossum]

Or I can just save the axisTags. That's all I need.

Ah yes. As long as they're refreshed on each compile/decompile call, that should be fine.

[behdad]

All done.

[behdad]

I still have to handle the following flag:

If ScaleY is missing: take value from ScaleX (to be discussed here: BlackFoundryCom/variable-components-spec#2)

It gets messy.

[justvanrossum]

It gets messy.

I bet :( Feel free to simplify this in the spec — we can be pragmatic about this.

[behdad]

I still have to handle the following flag:

If ScaleY is missing: take value from ScaleX (to be discussed here: BlackFoundryCom/variable-components-spec#2)

It gets messy.

I made the compiler handle this flag automatically.

[behdad]

This is now works in:

• ttx
• WOFF
• WOFF2
• ttGlyphSet
• scaleUpem
• subset
• merge
• varLib.instancer when not instancing VarComposite axes with variations.
• varLib.interpolatable

[behdad]

Added tests and fixed.

Err. Actually fixing.

[anthrotype]

I see you added some generic xml-roundtripping tests for varComponents in the unit tests for scaleUpem module.. that's not ideal, althoughj some tests is always better than no tests. The glyf table module has unit test module of its own, in Tests/ttLib/tables/glyf_test.py, that's where I'd expect to find things like those.

[behdad]

I see you added some generic xml-roundtripping tests for varComponents in the unit tests for scaleUpem module.. that's not ideal, althoughj some tests is always better than no tests. The glyf table module has unit test module of its own, in Tests/ttLib/tables/glyf_test.py, that's where I'd expect to find things like those.

Ah thanks. I was wrongly looking for ttx tests and not finding them. Will move there.

[behdad]

This seems to be in good shape again.

[justvanrossum]

This seems to be in good shape again.

Looks good to me i general, and the pen.addVarComponent() api is now usable for glyph extraction uses cases.

I do worry that we don't have a solution for glyph.recalcBounds() for variable components. The factoring between _g_l_y_f.py and ttGlyphSet.py makes it seemingly difficult to implement. At the same time, ttGlyphSet._setCoordinates() does too much work in some cases, where we don't need the lsb - xMin offset (because is is supposed to be zero anyway). I have a vague idea of adding a new class "DrawingContext" to _g_l_y_f.py, that would contain the common code for recalcBounds and ttGlyphSet. Needs sketching out.

[behdad]

I do worry that we don't have a solution for glyph.recalcBounds() for variable components. The factoring between _g_l_y_f.py and ttGlyphSet.py makes it seemingly difficult to implement. At the same time, ttGlyphSet._setCoordinates() does too much work in some cases, where we don't need the lsb - xMin offset (because is is supposed to be zero anyway). I have a vague idea of adding a new class "DrawingContext" to _g_l_y_f.py, that would contain the common code for recalcBounds and ttGlyphSet. Needs sketching out.

We can do that in a followup PR. Sad thing is we don't have the font around; I suppose we can add a glyf.font link.

[behdad]

@anthrotype @justvanrossum Can we move towards merging this?

[anthrotype]

LGTM

a follow up PR can deal with recalcBounds for varComposites

[anthrotype]

We can do that in a followup PR.

let's also file an issue tracking implementation of recalcBouds for varComposites

[behdad]

We can do that in a followup PR.

let's also file an issue tracking implementation of recalcBouds for varComposites

#2986