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.

[behdad]

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.

Sounds good.

[behdad]

@ebraminio want to implement the proposed API, with MVAR?

[ebraminio]

Sounds interesting!

[ebraminio]

My conclusion till this point from the discussion and reading some parts of the specs is the proposed API will be like this and placed on hb-ot-metrics.h:

HB_EXTERN hb_bool_t
hb_ot_font_get_metrics (hb_font_t *font,
                        hb_ot_metrics_t metrics_tag,
                        hb_position_t *position);

And valid tags for hb_ot_metrics_t enum are:

• The ones here that will be fetched from MVAR table and polyfilled with OS/2. (tags mentioned on Sacha comment)
• Also the ones here which will be fetched from STAT, ital tag of it will be polyfilled with fsSelection bit0/Italic, wght with OS/2.usWeightClass, wdth with OS/2.usWidthClass, slnt with OS/2.fsSelection (bit 9/oblique?) and opsz with OS/2.usLowerOpticalPointSize/OS/2.usHigherOpticalPointSize (average?)? So at this point no need for separate API for OS/2 I guess? And shouldn't we try fvar before STAT? What to do with name ids STAT has? I mean we should be aware of the API we are designing is not STAT oriented but just uses it. Is my understanding correct, isn't STAT for font families and fvar for variable fonts?
• And now that we are here, why not expose BASE with its tags also? Or isn't better we have three separate APIs now that they have three different tag registry?

[brawer]

Personally I’d find a separate API for stylistic attributes more natural because the returned range is different. Metrics are positions; stylistic attributes are values along variation axes. Personally, I’d also keep BASE separate because baseline positions are language-dependent.

[ebraminio]

OK so we clearly need three different APIs, back to API design I guess,

• One dealing with values only available at STAT polyfilled with OS/2 using fvar tags.
• One for MVAR defined tags on hb-ot-metrics.h? (fetched from different places...)
• BASE API, also in hb-ot-metrics.h (and expose bsln on hb-aat.h?)

[behdad]

Forget about STAT and BASE tables. Let's define one simple API for MVAR tags for now.

[ebraminio]

Sooner or later ot-metrics will be finished, any idea about the other part using tags on https://docs.microsoft.com/en-us/typography/opentype/spec/dvaraxisreg on a different API, what should be named? And can I have a digest of what is STAT use, still confused I can say.

[behdad]

Take a break, leave me alone for a while. It's holiday season! ;)

[ebraminio]

Hehehe

[ebraminio]

From head,

  HBINT16	xMin;			/* For all glyph bounding boxes. */
  HBINT16	yMin;			/* For all glyph bounding boxes. */
  HBINT16	xMax;			/* For all glyph bounding boxes. */
  HBINT16	yMax;			/* For all glyph bounding boxes. */
  HBUINT16	macStyle;		/* Bit 0: Bold (if set to 1);
					 * Bit 1: Italic (if set to 1)
					 * Bit 2: Underline (if set to 1)
					 * Bit 3: Outline (if set to 1)
					 * Bit 4: Shadow (if set to 1)
					 * Bit 5: Condensed (if set to 1)
					 * Bit 6: Extended (if set to 1)
					 * Bits 7-15: Reserved (set to 0). */

So yMin and yMax can be used instead ascender and descender I guess and macStyle to polyfill OS/2? (or which one should be prioritized?)

[behdad]

So yMin and yMax can be used instead ascender and descender I guess

No.

[ebraminio]

Guess we can consider original request of this page fixed with metrics API introduced some releases ago, and #1880 and #1920 are considered its remaining parts. Thanks

[behdad]

I thought more and like to expose italicAngle in ot-metrics and font-extents. I suggest we expose it not as an angle but as, eg for horizontal direction, scale_x * tan(angle).

[behdad]

I thought more and like to expose italicAngle in ot-metrics and font-extents. I suggest we expose it not as an angle but as, eg for horizontal direction, scale_x * tan(angle).

If/when we do that we should also update our fallback mark-positioning to use that to adjust mark x position depending on the y.

[ebraminio]

Was thinking about you proposal more in caret sense, apparently italicAngle is considered to have some use other than caret #1880 (comment) so like to know what is Khaled's use as I don't think it would be nice to force our only user to reverse our work exactly to access some value it should've accessed easily at the first place. The advantage (update the difference maybe) of hb-style to this was to query the value first from fvar/STAT/fdsc tables before post->italicAngle.

[behdad]

Italic angle is used by TeX for mark positioning as well as "italic correction". While using this for mark positioning is considered fallback behavior in OpenType fonts, Italic correction is a legit thing.