Should the global designspace location be implicitly passed down to components?

[justvanrossum]

See also the last section of https://github.com/BlackFoundryCom/variable-components-spec/blob/main/variable-components-spec.md#how-to-process-varc-data

The current design and implementation (at https://github.com/BlackFoundryCom/rcjk-tools/) do not do this.

If a component base glyph implements variations for a global axis (say wght), the current design requires to set the value wght explicitly from the component reference.

If the wght value does not need to be changed by the component reference, this will require some redundant data.

It appears that the model GlyphsApp uses for Smart Components would benefit from implicitly passing down global axis values. I don't think Smart Component references can influence/overwrite global axis values.

[behdad]

I think locations should implicitly be passed down to components. That would allow eg. modifying the wght of a component from a composite.

Regarding your point with private axes conflicting with each other, I don't think that's a problem in practice. This only becomes a problem with composites using other composites. So their axes should be distinct. I think a smart font builder / compiler can take care of assigning axes to avoid conflicts.

[behdad]

I'll go as far as saying that the delta should be added to the current value of each axis.

[behdad]

I'll go as far as saying that the delta should be added to the current value of each axis.

That would make this very similar to my avar2 proposal:

https://github.com/harfbuzz/boring-expansion-spec/blob/avar2/avar2.md

[justvanrossum]

I think locations should implicitly be passed down to components. That would allow eg. modifying the wght of a component from a composite.

Yes, absolutely.

Regarding your point with private axes conflicting with each other, I don't think that's a problem in practice. This only becomes a problem with composites using other composites.

VarC indeed assumes that you always set all axis values of the component to avoid such conflicts. But it doesn't require you to.

Can be solved either way. Compiling is already a complex task is it is, so I would not want a new design to require a "smart font builder / compiler".