Add support for the OpenType math Table Fields

[fred-wang]

Version 3 of the Open Font Format was published as an ISO standard in the beginning of October and includes a new MATH table. This table has been used by Microsoft Word, TeX engines (e.g. XeLaTeX, LuateX, ConTeXt), Web rendering engines (Gecko and WebKit) for mathematical rendering. It is also supported by some tools such as fontforge or FontTools.

Currently, the UFO format does not seem to contain any field for the MATH table. It would be great if the math table was supported. For example, the UFO font "Fira" used in Firefox OS could have a math companion for MathML rendering (see https://github.com/mozilla/Fira/issues/79).

References:

http://www.microsoft.com/typography/otspec/math.htm http://mpeg.chiariglione.org/standards/mpeg-4/open-font-format/text-isoiec-dis-14496-22-3rd-edition http://www.iso.org/iso/home/store/catalogue_ics/catalogue_detail_ics.htm?csnumber=66391e http://fontforge.github.io/math.html

[adrientetar]

cc me

[fred-wang]

Also cc'ing @khaledhosny and @behdad as they have worked on the implementation in fontforge/fonttools.

[tiroj]

cc. @PeterCon who is doing some work on MATH related stuff at the moment

---

In preparation for the upcoming UFO spec meeting, I'm giving this some thought. Preliminary notes:

The MATH table is unusual in that it contains a mix of font and glyph level data, which elsewhere in the OpenType format would probably be split between separate tables. MATH is a bucket table for everything related to math layout except a small number of math-specific GSUB features.

This suggests that the MATH data in UFO needs to be split between the fontinfo.plist and the individual .glif files, and for clarity each MATH data point should probably be prefixed in some obvious way.

It's pretty obvious where some of the data should live:

• Math Constants all belong in the fontinfo.plist
• Glyph Italics Correction, Top Accent Attachment, and Glyph Kerning (cut-ins) belong in the .glif

But there are also some MATH data that isn't so obviously assigned, and will need model design decisions, i.e. figuring out the best way to handle this data within the UFO structure. So, for example, should the Extended Forms List be a plist, or should inclusion in the Extended Forms List be recorded at the .glif level?

I need to review the MATH table data structure for Vertical/Horizontal Glyph Variants in more detail, but this contains data similar to a combination of GDEF, GSUB and GPOS, in that it includes categorisation, mapping of relationships between glyphs (one-to-one-of-many and one-to-many), and also min and max overlap positioning for combinations of glyphs.

Some of the MATH table data types are constrained to a single value, but almost all of it can also have device (ppem) delta arrays, and some — notably the cut-in Glyph Kerning data — is as extensive as the font maker wants it to be, so an indvidual glyph may contain multiple steps in any of the four quadrants.

---

One further note: the MATH table seems likely to get extended in the not very distant future. In addition to some interesting ideas about leveraging variations technology in math layout, there are some notable holes in the existing data, e.g. Italics Correction is only applied to the top right of glyphs, whereas it should have corresponding correction on the bottom left.

[behdad]

I feel like at least initially one should experiment with adding this to UFOs using the private lib facility, and make fontmake use that to build MATH table. Only then and if everyone is happy about it, should be added to UFO proper.

[tiroj]

That sounds sensible. I’m not really up on the UFO side of things, but have some experience with MATH tables and tools, so can flag the kind of things that need to be handled.

[benkiel]

What @behdad notes is right; that is how we’d like a lot of things developed: tested in implementations; then taken into the formal spec after proving use and practicality; rough edges sanded before we make it official and then tools have to support things

[adrientetar]

Amen to that; putting things in spec before they're implemented you're gonna have regrets down the line.

[tiroj]

That's fine. I'm totally happy with a draft + implementation approach, where draft is some level of understanding about how the data should be handled. So maybe table this discussion in the spec meeting and create a working group to develop the draft and work on implementation?

[benkiel]

@tiroj yes, that would be great. These higher level things are fantastic to have as a resource, thank you

[tiroj]

I'm compiling a list of people interested in exploring a minispecification for MATH table sources in UFO. From the 31 July meeting, I've noted interest from

• Caleb Maclennan
• Jeff Kellem
• Sergey Malkin

Anyone else interested in participating, please indicate here. Likely next step would be some form of online working group video meeting.

[PeterCon]

+1