Variable MATH table

[khaledhosny]

Is there any interest in supporting font variations in MATH table?

At high level, I think there are two aspects for font variations regarding MATH table:

1. MATH in variable fonts: say, a font with weight axis that has a MATH table and MATH data (constants, measurements, etc) would variate. Since most values in MATH table use Device Tables, they would be upgraded to use Item Variation Stores, other values that use plain numbers can probably handled by some other mechanism like in other tables.
2. The other aspect is using font variations in MATH table, namely for horizontal and vertical glyph variants. This would probably be done by registering two axes, for horizontal and vertical extension, lets say mhex and mvex. This can’t support arbitrary glyph sizes, though, so we would still need glyph assembly as last resort mechanism, or may be if we can support extrapolation it would be possible to get arbitrary glyph sizes without resorting to building them from glyph parts.

What do you think? My understanding of the inner workings of font variations is rather limited, so I don’t know how viable is what I proposing. We probably need input from people doing math layout and whether such a thing would be useful/implementable.

[khaledhosny]

cc @fred-wang @laurmaedje @mpsmath @simoncozens

[behdad]

There's definitely interest but needs people to help define what it looks like.

[simoncozens]

(1) is easy and probably should be done. We can upgrade the device tables as you say, and use the MVAR mechanism for the scalars.
(2) I don't think needs any spec changes yet, just an agreement between math layout engines about how to interpret the axes. Try it and formalise it if it works.

[behdad]

(1) is easy and probably should be done. We can upgrade the device tables as you say, and use the MVAR mechanism for the scalars.

We need to at least add a ItemVariationStore then.

[mpsmath]

I am more hesitant, but maybe that is because I have not really played with variable fonts at all and hence not discovered their benefits. I guess it is in principle technically possible. Maybe the extensibles would be the most difficult thing to handle. Do you have plans to create a math font paired with a variable text font? If so, which one?

[fred-wang]

Regarding 2, some benefits could be:

• reduce the size of the math font by avoiding to add many glyphs (important for web fonts)
• allow more accurate stretching without distortion (e.g. one that would be caused by a scale transform).
• allow stretching in both directions (e.g. diagonal arrows).
• allow curved stretching like the arabic style from https://www.w3.org/TR/arabic-math/arabic.xhtml#N10AEE

IIUC, how it works is that we provide a variable value (or more) and we get a glyph from that. While for math layout we are given a target width or height and ask to shape a glyph (or an assembly) to match this target. So either the layout system would need to do a reverse calculation to calculate the desired variable value ; that can be straightforward for easy cases but maybe the MATH table should provide some hints on how to do that.

[simoncozens]

It should be easier than that - if the axis is measured in font units, then the engine can simply dial in how big they want the glyph to become.

[khaledhosny]

cc @jenskutilek

[khaledhosny]

(2) I don't think needs any spec changes yet, just an agreement between math layout engines about how to interpret the axes. Try it and formalise it if it works.

But for it to work reliably it needs (1) in MATH table, at least for top accent attachment and italics corrections of the extensible glyphs.

[khaledhosny]

Do you have plans to create a math font paired with a variable text font? If so, which one?

No concrete plan, my interest is mostly in aspect (2), creating extensible glyphs using font variations, for the many benefits excellently summarized by @fred-wang.

[khaledhosny]

Regarding 2, some benefits could be:

• reduce the size of the math font by avoiding to add many glyphs (important for web fonts)
• allow more accurate stretching without distortion (e.g. one that would be caused by a scale transform).
• allow stretching in both directions (e.g. diagonal arrows).
• allow curved stretching like the arabic style from https://www.w3.org/TR/arabic-math/arabic.xhtml#N10AEE

I’d add to that radicals that are built from one glyphs, instead of a surd and a drawn rule which often results in misalignment and rendering differences due to hinting or different rendering between glyphs and solid rectangles. Instead the radical glyph would stretch in both directions; vertically to get the desired size and horizontally to cover the equation.

[khaledhosny]

cc @tiroj

[tiroj]

I’ll need to think through the vertical/horizontal variants idea. I can imagine this gets complicated in the case of slanted glyphs.

More generally, I think having a brainstorming meeting to come up with all the ways in which variations technology could be applied to math layout would be a good idea. And if we’re doing this, then there are some other improvements that could be usefully made to the MATH table, e.g. defining italic correction for other quadrants than just the top-right.

[mpsmath]

@tiroj Regarding italic correction in other corners, what is the use case? There are already corner kerns/staircase kerns. In fact, the Lucida Bright Math font does not really use italic correction at all, but uses those kerns, and it is therefore one of the easier fonts to handle. (In ConTeXt italic correction is even converted into corner kerns.)

[khaledhosny]

@tiroj Regarding italic correction in other corners, what is the use case? There are already corner kerns/staircase kerns. In fact, the Lucida Bright Math font does not really use italic correction at all, but uses those kerns, and it is therefore one of the easier fonts to handle. (In ConTeXt italic correction is even converted into corner kerns.)

I think it would help with situations like the tail of italic j, where you either give it -ve left side bearing to improve spacing (how type designers usually design it) and get clashes with delimiters, or give it +ve left side bearing to fix the clash at the expense of worse spacing:

I guess a left italic correction here (not sure if 4 corners are really needed) would fix the clash without sacrificing the spacing.

[mpsmath]

@khaledhosny I see the issue, but I'm not sure italic correction is the cure (it is not really correcting an italic <-> upright). How would you differ the spacing i<->j and (<->j? We can already have kerning pairs in the fonts. So an application can decide what to do with it.

Example: In bonum we indeed have the clash (top line). It is resolved with a negative kerning pair between i and j (bottom).