STIX feedback

• 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.

---

Note on the design of the Web fonts: splitting the fonts will require some changes like dropping the Open Type Math table, adding space characters for monospace, moving non-Unicode glyphs to the Plane0 PUA etc In general the splitting is designed for MathJax's purpose and may not work well in browsers. Anyway, browsers could just use WOFF packaging of the STIX-Word, without further modifications.

Peter: @Fred Could you specify "may not work well in browsers"? What functionality will be lost, which loss can be worked around (without MathJax) etc.

Fred: @Peter If browsers use Open Type Math table in the future, the Web fonts without Open Type MATH table will not be usable. In general, for browsers and users it is easier and more convenient to have only one font-family to handle. For example, if one wants to use STIX fonts (and if STIX-Math and STIX-Regular are merged as proposed here) users will just use the CSS rule "math { font-family: STIX; }" and they additionally want to specify Web fonts

  @font-face {
   font-family: STIX;
   src: local(STIX-Regular), url(STIX-Regular.woff);
  }
  @font-face {
    font-family: STIX;
    src: local(STIX-Bold), url(STIX-Bold.woff);
    font-weight: bold;
  }
  @font-face {
    font-family: STIX;
    src: local(STIX-Italic), url(STIX-Italic.woff);
    font-style: italic;
  }
  @font-face {
    font-family: STIX;
    src: local(STIX-BoldItalic), url(STIX-BoldItalic.woff);
    font-weight: bold;
    font-style: italic;
  }

Obviously, it's a pain if we have to do instead "math { font-family: STIX-Main, STIX-Arrows, STIX-Alphabets, STIX-Greek ... }" and similarly have many @font-face rules for each subfont. The same is true for browsers' internal code where having many fonts to deal with complicate things. Also just using woff versions of STIX-Word will ensure that the browsers handle the Web fonts exactly the same as the local versions (with only a possible reflow after a few seconds) while this is far less clear with our Web fonts (in particular Davide mentioned that it may disturb the computation of the font height).

I'm now wondering if we should give the fonts back to the STIX committee as "STIX-mathjax" rather than "STIX-web" to better explains for what they have been designed for (similar to STIX-word and STIX-latex). In particular, in the future MathJax could use these versions as local fonts if they are installed on the system. That seems important, given that the STIX-General set is probably going to remain unmaintained and removed from the default distribution of operating systems.