Recover design coords from a hb_font_t

[matthiasclasen]

I want to create a ui for font variations.

I have a hb_font_t. From that I can get the hb_face_t, and all the axis infos to set up sliders.

But there is currently no way for me to find the coords of the hb_font_t to set the sliders current value. hb_font_get_var_coords_normalized gives me something, but it does not obviously relate to the min/max/default values in the axis info.

[behdad]

Need to add hb_font_get_var_coords_design.

This is slightly problematic since in a future with avar2 table, converting back from normalized to design coords might not be unique...

[behdad]

I think I forced FreeType to add similar API and exposed them to the same dilemma... We don't currently keep the design coords. Got to save them so we can return. And yeah, no idea what to do if user called set_var_coords_normalized and later called get_var_coords_design.

[matthiasclasen]

Note that the main problem is with initial values. Once I have my ui set up,the changes only flow from the sliders to the font, which is fine. The issue is what to set the sliders to the first time I see the hb_font_t.

In pango, I've reverted to opening the font with freetype and using FT_Get_MM_Var for now. But wanted to get away from that, and just go fontconfig -> fontname -> hb_blob_create_from_file.

Maybe the right answer is to make fontconfig add the design coords to the pattern.

[matthiasclasen]

And yeah, no idea what to do if user called set_var_coords_normalized and later called get_var_coords_design.

I would suggest to clear saved design coords when normalized coords are set from the outside, and only return design coords when you have them.

[behdad]

I would suggest to clear saved design coords when normalized coords are set from the outside, and only return design coords when you have them.

Right. But we don't have a (existing, clean, ..) way to return "not-representable".

[matthiasclasen]

Something like this?
/**

• hb_font_get_var_coords_design:
• Returns design coords that have been set with
• hb_font_set_var_coords_design(). Will return %NULL
• if normalized coords have been set directly with
• hb_font_set_var_coords_normalized().
• Return value is valid as long as variation coordinates of the font
• are not modified.
• Returns: (nullable): the design coords of the font
• Since: 1.4.2
  */
  HB_EXTERN const float *
  hb_font_get_var_coords_design (hb_font_t *font,
  unsigned int coords_length);

[ebraminio]

Do we need a separate API or what is done here #1890 is useful for this also as it is now able to convert back from normalized coordination to design in a hb_font_t?

[ebraminio]

I mean I think we can store original design coordination but do simulation also with the API if we don't have original ones, if what the API promises isn't convenient enough.

[behdad]

If the transform is reversible, sure would be nice to return it.

[behdad]

Reopening to finalize this and mark non-experimental.

[behdad]

I thought about this in reference to #1914.

If we are to inject hb_font_set_ptem into ptsz axis automatically, should that be returned in the return value of this API or not? I feel like it should not, but that would be a user surprise. @matthiasclasen @drott ?

[drott]

If we are to inject hb_font_set_ptem into ptsz axis automatically

ptsz or opsz?

[behdad]

ptsz or opsz?

Right.

[behdad]

If we are to inject hb_font_set_ptem into opsz axis automatically, should that be returned in the return value of this API or not? I feel like it should not, but that would be a user surprise. @matthiasclasen @drott ?

Nevermind. See #1914 (comment)