STIX-feedback.md

-* In STIXMath-Regular.otf, some glyphs used as components for stretchy operators should be moved to the Miscellaneous Technical unicode block. This includes those from uni2320.s1 to uni23B3.s1 and from uni23B7.s1 to uni23B9.s1
+* 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
 
-* There are a couple of delimiters that could be made infinitely stretchy (but they have only fixed size data):
-    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.)
+* 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.)
 
-* Other stretchy operators could be added, see the DELIMITERS list in https://github.com/fred-wang/MathJax-dev/blob/open-type-fonts/fonts/OpenTypeMath/STIX-Web/config.py
+* 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:
 
-* STIX-Word is missing glyphs from STIX-General?
+    0xAAAA:
+    {
+      "dir": "H",
+      "HW": [0xAAAA,0xBBBB,0xCCCC],
+      "stretch": [(0xDDDD,"left"),(0xEEEE,"rep"), (0xFFFF,"right")]
+    }
 
-* Are most of the glyphs from STIX-Regular.otf and STIXMath-Regular.otf duplicate? If so, is it ok not to repeat them in the Web fonts splitting? Can the STIX committee merge the two files?
+    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:
 
-* Do we have duplicate glyphs for style vs mathvariant (for example alphabets from STIX-Bold.otf and the corresponding characters from the Mathematical Alpha Num block of STIX-Regular.otf)? If so, is it ok not to repeat them in the Web fonts splitting?
+    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
 
-* 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 (these 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.
\ No newline at end of file
+    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.
+
+	> Fred: @Davide, did you find missing glyphs that are important for MathJax?
+
+* 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.
+
+* Note of 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.
\ No newline at end of file