Coordinate ptem with variable opsz

[ebraminio]

Great that we now have #1484 as it will ease this, one thing I think worth to do eventually is to coordinate _set_ptem with opsz variation axis (and maybe deprecate _set_ptem eventually), I am not sure how that should be done, maybe simulating an axis variation when trak table exists? Setting the axis when _set_ptem is called? etc. Let me know what do you think

[behdad]

I agree we want some of those things. Not sure about specifics. Let this sit here for a while. :) I thought I opened an issue for it before.

[drott]

I am concerned about the case that in Blink it would be possible to override opsz using font-variation-settings and disconnect it from ptem-size - in that case I prefer it not to be automatic behind the scenes.

[behdad]

So I think trak and opsz should be controlled the same way. Same way that we control TT kern table using kern OT feature.

How to control it, what takes priority over what, to be determined, and is entangled in other things, like named-instances and desire that their variations stick. Ie. #1883

So, we're moving to a place that a font's variations don't start to default coordinates, but they come from the named-instance, then overriden by set_pptm and only then overriden by explicitly-specified varitations.

[behdad]

So Blink can always override.

[matthiasclasen]

This would be great to have. I'm looking at what to do for opsz in pango, and having harfbuzz just do the right thing would be by far the easiest.

[behdad]

This would be great to have. I'm looking at what to do for opsz in pango, and having harfbuzz just do the right thing would be by far the easiest.

I agree. As a first step let's make pango call hb_font_set_ptem if it doesn't.

[behdad]

Ref https://gitlab.gnome.org/GNOME/pango/-/issues/621

[behdad]

Thinking more about this I think I want to deprecate this API and make it simply return the currently-set value of the opsz axis. Adding two new API:

  void hb_font_set_variation(font, hb_tag_t, float value);
  float hb_font_get_variation(font, hb_tag_t);

these set/get one variation without disturbing others.

The reasoning is that if we were to keep the ptem API, then we'd also need to add API for weight and width, and other standard axes when they are added. But by precedent we prefer enum-based APIs like our hb-style, hb-ot-metrics, etc. That API style also obviates the interaction questions raised.

[behdad]

Thinking more about this I think I want to deprecate this API and make it simply return the currently-set value of the opsz axis. Adding two new API:

  void hb_font_set_variation(font, hb_tag_t, float value);
  float hb_font_get_variation(font, hb_tag_t);

these set/get one variation without disturbing others.

The reasoning is that if we were to keep the ptem API, then we'd also need to add API for weight and width, and other standard axes when they are added. But by precedent we prefer enum-based APIs like our hb-style, hb-ot-metrics, etc. That API style also obviates the interaction questions raised.

@jfkthame does this make sense to you?

[behdad]

Thinking more about this I think I want to deprecate this API and make it simply return the currently-set value of the opsz axis. Adding two new API:

  void hb_font_set_variation(font, hb_tag_t, float value);
  float hb_font_get_variation(font, hb_tag_t);

these set/get one variation without disturbing others.

One issue with this is that, in the future (FontVars2.0) avar calculations would need to be run for the full font after each variation is changed, so this style of API is more likely to encourage an O(n^2) style of setting variations.

@jfkthame still would value your input.

[behdad]

Seems like this is the root of a few bugs:

#1914
https://gitlab.gnome.org/GNOME/pango/-/issues/695