Nested glyphs: break the link between axes with the same name

[mrk-z]

I have 2 glyphs A, B, and A is using B as a component. Currently, if A and B both have an axis with the same name, adjusting this axis in A also affects the same axis in B: B interpolates as if this axis is adjusted, even though the axis in B has no actual values. Entering an actual value for this axis in B seems to break the link.

Not sure if this is intended or a bug. If it's intended, it's creating unexpected issues : for example, the axis in A is actually intended to control another component other than B; but if we leave the axis in B unmodified, when using this axis in A, it does its intended behavior + also modifies this axis in B.

I think it's better to just have them not linked to each other automatically? Currently when creating a component, even if we do want these axes in A and B to do the same thing, we still always make sure this axis in B has actual values.

[justvanrossum]

I don't fully understand.

Could it be your example is really about three glyphs?

A -> B -> C, where B and C each have an axis of a certain name. The B component in A has the axis set. You want it to affect C, but not B?

There isn't really such a thing as "linking", but there is a possibiliy for axis values to pass through an "intermediate" glyph (B in my example), by not specifying a value for the axis for the C component in B. There is no UI for this, so this can for sure cause confusion.

Perhaps each axis (in the right sidebar) should have a checkbox that, when "off", will not set that axis for the component, allowing parent axis values to pass through (from A to C in my example, with the axis turned "off" in the C component in B).

Let me know how this matches with what you are describing.

[mrk-z]

More like this:

Today I was making a character which uses A, and A is composed of B + C. Both B and C are glyphs composed of only contours.

B has an axis called "T_H_weight", which controls the weight of its top horizontal stroke.

A has an axis also called "T_H_weight", and it should only control the weight of C (C has a weight axis).

Today when I was using "T_H_weight" of A, I found that it controls the weight of both C and the top horizontal stroke of B.

I thought we made a mistake when making A, but when I opened up A, I found that the layers related to this axis are correct : only the weight of C is modified, and B remains unchanged. But the top stroke of B also interpolates as I move the "T_H_weight" axis in A, even though the "T_H_weight" axis of B has no value changes.

I had to move around the "T_H_weight" axis of B to set it to 0, in order to stop the top stroke of B from interpolating.

[mrk-z]

Hi, I was wondering if there are any updates with this issue.

This was just a minor local annoyance, and we could easily spot and fix it. But recently we had a font-wide bug, and it took us some time to figure it out it was actually due to this issue. So we think it'd be worth investigating and fixing soon.

Essentially we had 2 glyph A and B, and B uses A as a component.

• Originally, A has a "width" axis, and B has a "H_left_length" axis that controls the left length of the horizontal bar, by modifying A's "width" value and its position.
• Later A is added a "H_left_length" axis. But without editing B, B's "H_left_length" axis automatically adds the effect of A's "H_left_length" axis, which means B's "H_left_length" now modifies the left length by twice the amount.

As a result, may glyphs that use B and its "H_left_length" axis now turn into something like this:

It seems the "extra value" only exists in the display of B. If we decompose B, then A immediately jumps to the correct length, and all of its axes' values are also correct.

In the end, we fixed this bug by changing B's "H_left_length" axis value and setting it back to 0.

[justvanrossum]

Thanks for the extra details! That is very useful. I'll get on it.

[justvanrossum]

I think the fundamental issue here is that axis values can get passed to "grandchildren", if the child does not set the axis itself.

This is intended as a feature: and we actually need this for global axes like weight: deeply nested glyphs should be able to respond to the global weight axis, without any of the intermediates having to do anything.

But I do see how this works counterintuitively (or even just wrong) for glyph axes.

I'm contemplating two solutions:

1. Only pass down axis values for global axes (in other words, never "inherit" axis values for glyph axes)
2. Somehow get Fontra to fill in the values (the effect of you manually editing)

The latter is hard in the context of axes being added: the "client" glyphs don't know about such change.

Therefore I think the first solution is the only reasonable one.