| ... | ... | @@ -48,32 +48,10 @@ |
|
|
|
|
|
|
|
______
|
|
|
|
|
|
|
|
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.
|
|
|
|
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.
|
|
|
|
|
|
|
|
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
|
|
|
|
The webfonts will not be a full substitute for the STIX fonts in browsers with native MathML support. 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.
|
|
|
|
|
|
|
|
@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).
|
|
|
|
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).
|
|
|
|
|
|
|
|
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 |
|
|
|
Besides these technical issues, using the mathjax-webfonts would be slightly cumbersome as authors would have to specify 114 instead of 4 webfonts. |
|
|
\ No newline at end of file |
Peter Krautzberger