hb_font_set_variations forgets the current coords

[matthiasclasen]

It uses 0 for every axis that is not specified in the variations.

This was unexpected to me when I did this:

hb_font_set_var_named_instance (font, instance);
hb_font_set_variations (font, just_one_axis, 1);

[matthiasclasen]

I ended up changing things around and instead of calllng hb_font_set_var_named_instance, do the following:

hb_ot_var_named_instance_get_design_coords (...)
/*  override some coords */
hb_font_set_var_coords_design (...)

[behdad]

Yes this is bothersome to me... I'm leaning towards making font remember which named instance it's pegged to, and apply variations on top of that when set using set_variations. Not sure what about when set with set_var_coords_design with a short vector. The latter resetting unspecified axes to their default (of the pegged instance) makes most sense to me.

[behdad]

Am reviewing API changes for release, and came here to express again how much this bothers me!

I'm making the release but let's figure this out soon.

[ebraminio]

I think I should disagree here, we should have one other API like hb_font_set_variation that just touches one axix without having anything to do with named instances, keeping set_variations semantic clear (resetting variations and use only ones in the input). _set_var_named_instance semantic also shouldn't be made complicated, if someone touches one axis of a named_instance, the font won't refer to that named instance anymore so it doesn't make sense to store its index in the font, if we wanted that we should've named _set_var_named_instance as _set_var_base_named_instance

[behdad]

I'm getting nervous about this mess we have right now. Let's aim for an understanding and agreement here. @jfkthame can you please chip in?

[behdad]

Basically question is, I think, do we want to have a set of "sticky" variations on the font, and then adjustments automatically applied on top of that? Or maybe that's the wrong way to think about it.

[jfkthame]

What I think makes sense to me from an API point of view is that hb_font_set_variations should set only the variation axes that are specifically passed to it, leaving any others untouched.

If I have a font that has multiple axes, I should be able to set them one by one in separate calls to hb_font_set_variations, or (more efficiently, perhaps) all at once in a single call, but the end result would be the same.

hb_font_set_var_named_instance sets all axes, of course; hb_font_set_variations could then be used to adjust one (or more) of the axes from the values that the instance specified, so that the font no longer represents that instance, but any axes that aren't mentioned in hb_font_set_variations would keep the values that the instance gave them.

The font doesn't need to "remember" which instance was used to set its variations, AFAICS; it just needs to adopt that instance's axis values. Calling hb_font_set_var_named_instance is (should be) identical to calling hb_font_set_variations with the corresponding set of axes/values. A named instance is simply a shorthand that gets "expanded" by the set operation.

So IMO what @matthiasclasen originally tried ought to have worked in the way he expected.

[behdad]

hb_font_set_var_named_instance (font, instance);
hb_font_set_variations (font, just_one_axis, 1);

Okay I like to make this work by making the font remember its named instance and anchor to it.

[behdad]

hb_font_set_var_named_instance sets all axes, of course; hb_font_set_variations could then be used to adjust one (or more) of the axes from the values that the instance specified, so that the font no longer represents that instance, but any axes that aren't mentioned in hb_font_set_variations would keep the values that the instance gave them.

Since we can't change hb_font_set_variations behavior now, I have to either add hb_font_set_variation to set an individual value (more expensive) or add a new API with new semantics hb_font_change_variations?