Allow propagating changes from hb_font to its parent

[behdad]

trafficstars

When you create subfont it copies all from parent. This was designed as one configuring parent then creating sub. I realize that users sometimes create subfont to override a callback or two, and expect that if they reuse subfont and change things on it and everything work. It currently doesn't because the changes won't be propagated to parent.

Asking them to manually do is not nice. We can easily do it. The question is do we add new API to enable such propagation (safe but error-prone) or just change the behavior underneath everyone. If parent is made immutable it won't change, so there's reason to defend changing default behavior.

I was thinking [sg]et_pegged but that sounds more like would be if the subfont followed parent. (https://en.wikipedia.org/wiki/Fixed_exchange_rate_system )

Humm. Maybe explicit is better. I can't make up my mind. The fact that changing parent won't affect subfont will also surprise somebody someday, but that's not something we are ever gonna do.

This is tangentially related to https://github.com/harfbuzz/harfbuzz/issues/2270

[behdad]

cc @drott

[drott]

Indeed, I got a bit stuck on this when trying to use the hb ot callbacks instead of Skia fallbacks for advance metrics when investigating https://crbug.com/1005969 because of the way we use a sub-font in HarfBuzzFace in Blink/Chromium. After creating the sub font, we don't use the parent much anymore and used to set the variations only on the subfont, which then surprisingly makes the ot font parent font advance callbacks not work for HVAR or phantom points + GVAR situations - they only return static hmtx values.

[behdad]

used to set the variations only on the subfont, which then surprisingly makes the ot font parent font advance callbacks not work for HVAR or phantom points + GVAR situations - they only return static hmtx values.

I hit this as well... I'm thinking of alternatives right now.