Exposing OS/2 table?

[khaledhosny]

I’m working on a small project using HarfBuzz and I need to access a couple of fields from OS/2 table. It is a simple table and I can just read it in my code, but HarfBuzz already reads it for the font extents so I thought to ask if exposing the rest of the table is something HarfBuzz might want to do?

[behdad]

If we can model them in a nice way, sure. Which fields?

[khaledhosny]

I currently only want sxHeight and sCapHeight, but I guess the API would expose anything. How that API would look is really a tough question, I have been thinking about it and I don’t have an answer. The only similar API I know is FT_Get_Sfnt_Table, I like how it can handle newer table versions with additional fields, but I don’t really know if it is a good API design-wise or if it is a good fit for HarfBuzz.

[brawer]

Perhaps an API could be based on value tags from the MVAR table? For example, xhgt for OS/2.sxHeight, cpht for OS/2.sCapHeight, and undo for post.underlineOffset. For a variable font, the implementation would interpolate according to MVAR; for a non-variable font, it would retrieve the value from the respective tables in the font.

HB_EXTERN hb_bool_t
hb_ot_font_get_metrics (hb_font_t *font,
                        hb_tag_t metrics_tag,  // eg. hasc, hlgp, undo, xhgt, cpht
                        hb_position_t *position);

[behdad]

Thanks Sascha. Yes, that's indeed what I liked before. A couple changes:

1. The tag should be it's own enum. hb_ot_metrics_t,
2. Not sure if hb_ot_font_get_metrics; or hb_ot_metrics_get. Like neither of them. Anyway, this goes into hb-ot-metrics.h.

[khaledhosny]

OS/2 has more than metrics, they might not all be useful but why not just expose them all. I guess the enum would then be hb_ot_os2_field_t and the function would be hb_ot_font_get_os2_fields() or something like that. This can then be a model for other simple tables.

[behdad]

I prefer not to expose table by table.

Which OS/2 fields do you need that are not supported by MVAR tags? https://docs.microsoft.com/en-us/typography/opentype/spec/mvar

[khaledhosny]

Not currently in this project, but in LibreOffice I need also fsSelection. I’m likely to need also need it in this project, in addition usWeightClass andusWidthClass when I start working on font matching.

[behdad]

I prefer to have the metrics API, and expose more things separately.

[behdad]

width/wght we can add private MVAR-like tags and fetch using the same API (and hook to variations as well).

[behdad]

Why do you rely on fsSelection?

[behdad]

Also, hb_font_extents_t has lots of room. X-height and cap-height, although I don't like them because Latin-centric, can probably be added there.

[khaledhosny]

In LibreOffice fsSelection is checked for the USE_TYPO_METRICS bit. In the current project I think I’ll need it for the ITALIC, BOLD, REGULAR, and OBLIQUE bits.

Edit. I just checked XeTeX, and it uses OS/2.usWeightClass, OS/2.usWidthClass, OS/2.fsSelection, head.macStyle, and post.italicAngle to classify the fonts, so that is probably what I will need. May be I better read the tables myself first until I’m sure what I need exactly, if we are going to selectively expose table fields.

[behdad]

In LibreOffice fsSelection is checked for the USE_TYPO_METRICS bit.

Our font-metrics code already takes that into account.

In the current project I think I’ll need it for the ITALIC, BOLD, REGULAR, and OBLIQUE bits.

Right. Those would be useful.

Edit. I just checked XeTeX, and it uses OS/2.usWeightClass, OS/2.usWidthClass, OS/2.fsSelection, head.macStyle, and post.italicAngle to classify the fonts, so that is probably what I will need. May be I better read the tables myself first until I’m sure what I need exactly, if we are going to selectively expose table fields.

Okay, let us know.

[brawer]

Weight, width and italic angle sound like candidates for an API that could be modeled around the STAT table; the implementation would fall back to OS/2 if STAT is not present.