STIX feedback

This page collects information about the STIX fonts and how to create STIX webfonts for use with MathJax; see MathJax v2.3 roadmap.

Design Issues

The webfonts will not be a full substitute for the STIX fonts in browsers with native MathML support for several reasons.

This is due to the way browsers handle math fonts right now. While glyphs at unicode codepoints generally work, stretchy characters require the combination of severaly glyphs; some of these glyphs are stored in non-unicode positions and accessed through OpenType Math Tables -- which no browser currently supports.

To resolve this problem, Firefox has the relevant table information hardcoded in its source -- but only for STIX and Asana fonts; see https://developer.mozilla.org/en-US/docs/Mozilla/MathML_Project/Fonts for more information. (Safari does not handle non-unicode glyphs and only a few unicode constructions).

Even if browsers supported Open Type Math Tables, splitting the fonts would require dropping the Open Type Math table. It also requires adding space characters for monospace, moving non-Unicode glyphs to the Plane0 PUA etc.

Besides these technical issues, using the mathjax-webfonts would be slightly cumbersome as authors would have to specify 114 instead of 4 webfonts.

Technical issues.

• In STIXMath-Regular.otf, some glyphs used as components of stretchy operators (e.g. pieces of parenthesis) could be encoded as characters from the Miscellaneous Technical unicode block. This includes those from uni2320.s1 to uni23B3.s1 and from uni23B7.s1 to uni23B9.s1

• The following operators have size variants specified in the Open Type MATH table. Some components are already available and thus the stretchy constructions could just be added to the Open Type MATH table:

  • U+203E could be able to stretch infinitely (using itself as the extender)
  • U+222B could be made infinitely stretchy (top: U+2320, rep: U+23AE, bot: U+2321)
  • U+27E6 and U+27E7 could be infinitely stretchy using box drawing characters (U+2553, U+2551, U+2559, etc.)

• MathJax <= v2.2 uses the STIX-General set and its table for stretchy operators was created "by hand". In order to create STIX Web fonts for v2.3, we generated that table again using the Open Type MATH table instead. However, some operators we were able to stretch in v2.2 are not specified in the Open Type MATH table and thus we have to keep a list of extra delimiters (see DELIMITERS in https://github.com/fred-wang/MathJax-dev/blob/open-type-fonts/fonts/OpenTypeMath/STIX-Web/config.py#73). Note that our list is partly based on the W3C's MathML operator dictionary. Most of these operators could be easily added to the Open Type MATH table since the glyphs are already available from STIXMath-Regular.otf. Typical examples:

  0xAAAA: { "dir": "H", "HW": [0xAAAA,0xBBBB,0xCCCC], "stretch": [(0xDDDD,"left"),(0xEEEE,"rep"), (0xFFFF,"right")] }

  means that the stretchy operator 0xAAAA has direction horizontal, 2 size variants 0xBBBB and 0xCCCC and one construction (with 0xDDDD as the left piece, 0xEEEE as the "repeated" glyph and 0xFFFF as the right glyph). Vertical versions would look like this:

  0xAAAA: { "dir": "V", "HW": [0xAAAA,0xBBBB,0xCCCC], "stretch": [(0xDDDD,"top"),(0xEEEE,"ext"), (0xFFFF,"bot")] }

  However for some of the constructions, the components do not combine perfectly and we have to use scaling and translation parameters to work around that (these are the decimal numbers you can see in the list) ; some constructions also use glyphs from other fonts like STIX-Bold.otf and STIX-Regular.otf (these are the "Bold" and "Regular" you can see in the list). In these cases, adding these constructions to the Open Type MATH table will be less straightforward (that may not be essential, though). Finally, note also the alias entries like

  0x2500: {"alias": 0x2212, "dir": "H"}, # horizontal line

  which just mean that the operator 0x2500 will use the same strechy data as the operator 0x2212. These entries probably don't need to be added to the Open Type MATH table, since rendering engines could just maintain a table of remappings like the one used in MathJax.

• Is STIX-Word missing glyphs from STIX-General? The pdf included in the STIX fonts release from February 2012 indicates some changes. Most of the glyphs that were used for the extra DELIMITERS list were found ; some of them seemed to be lost but could be replaced by equivalent glyphs.

  The main difference is the loss of bold versions of some of some characters in the STIXMath-Regular.otf font. These include all the Size1 through Size5 forms (e.g., large parentheses, large integrals, large summation signs, wide tildes and other accents, etc.). Although not strictly needed by MathJax, currently these are accessible via \boldsymbol, and help when math is used in a bold context.

  In addition, bold versions of a number of variant forms (the contents of STIXVariants-Bold.otf) are missing. Again, not strictly needed by MathJax, these where in the old fonts, and aren't in the new ones. Also missing are bold versions of the integral variations (small, display, up, small up, display up). These are not currently available in MathJax. Finally, the bold versions of the characters at U+E150 to U+E153 from STIXNonUnicode-Bold.otf are missing.

• Most of the glyphs from STIX-Regular.otf and STIXMath-Regular.otf seem to be duplicate. Currently, our Python script that generates the Web fonts do not preserse this duplication but has to pick some from STIX-Regular.otf and other from STIXMath-Regular.otf. It would simplify a bit the script if the two are merged in a single file.

• Some glyphs used for style (*-Bold, *-Italic, *-BoldItalic) and mathvariant (Mathematical Alphanumeric Symbols unicode block for Bold, Italic, Bold Italic, Bold Script, Bold Fraktur, Sans Serif Bold, Sans Serif Italic, Sans Serif Bold Italic) are probably duplicate. Currently our Python script preserves all the glyphs while MathJax only needs a subset of them to implement the MathML mathvariant and style attributes.

• The symbol at U+1D98 (LATIN SMALL LETTER ESH WITH RETROFLEX HOOK) seems to be incorrect. It appears to be the glyph for U+1D9B (MODIFIER LETTER SMALL TURNED ALPHA)? The glyph is correct in the STIXGeneral fonts.

• The combining characters in the larger sizes (found in STIXMath-Regular.otf) do not combine (they are not zero width), as they do in the normal sized versions. E.g., uni20D7.s1 should have right and left bearing both set at 0, with the glyph extending to the left of 0 (see U+20D7 in STIX-Regular.otf for reference). This is true of all the combining characters in size 1 thorough 5 in both Combining Diacritical Marks (U+0300 through U+036F except for U+0338) and Combining Diacritical Marks for Symbols (U+20D0 to U+20FF).

• The combining symbols U+20EC (COMBINING RIGHTWARDS HARPOON WITH BARB DOWNWARDS) and U+20ED (COMBINING RIGHTWARDS HARPOON WITH BARB DOWNWARDS) in STIX-Italic.otf both combine to the right rather than to the left. That is, they are properly zero width, but the glyph is to the right of 0 rather than to the left. The bold and regular forms are properly handled.