Splitting of font metrics data

[Frédéric WANG]

So I've looked more carefully at how the splitting is done in [1]. Fonts
are already split as indicated in [2]. I give in attachment the file
config.pl files that was generated by the new script and that gives a
separation by font and unicode blocks. However, as I previously said I
don't use that classification for the moment and put everything in the
"Main" section (so in fontdata.js).

A way to split the font metrics data would be to use the attached file
and to add only a few characters in the "Main" section. So my idea is to
add a "Main" section for all the "STIX_Main-*" and "STIX_Math_Size*".
This "Main" section will contain all the characters that are in the
"Main R"/"Main B"/"Main I"/"Main BI" in the old font data [1]. Also, for
the "STIX_Math_Size*", perhaps I should put all the remaining characters
in the "All" section rather than using separate sections for each
unicode block.

Does that sound a reasonable approach?

Another question: the TeX's config.pl data contains a %test that I guess
is necessary for Web fonts. How am I supposed to choose these strings?

[1]
https://github.com/mathjax/MathJax-dev/blob/master/fonts/AFM/STIX-1.1/config.pl
[2] https://github.com/mathjax/MathJax/wiki/STIX-and-Asana#stix

--
Fr�d�ric Wang
maths-informatique-jeux.com/blog/frederic

[Davide P. Cervone]

> So I've looked more carefully at how the splitting is done in [1]. Fonts are already split as indicated in [2]. I give in attachment the file config.pl files that was generated by the new script and that gives a separation by font and unicode blocks. However, as I previously said I don't use that classification for the moment and put everything in the "Main" section (so in fontdata.js).

OK, I've look through this, and am starting to understand the layout better. I was misunderstanding the Normal and Main breakup originally. It looks like STIX_Main is what was in the Main.js file of the breakup of the original STIX fonts, while NORMAL is really just the math alphabets. That makes your comments about the mathvariants more clear. I will have to look back at the fontdata.js file now and see if I can make better sense out of that.

I still want to look very carefully at what glyphs are in some of the fonts. For example, I see some arrows are in STIX_Main, like the diagonal ones, but not the horizontal or vertical ones. Those are in STIX_Arrows, but not the diagonals. So I'm a little confused by that.

Here are some other things I noticed:

* Since each font must contain the space character U+0020, you should include that in the data (since the space could be used in something like <mn mathvariant="double-stuck">ONE HUNDRED</mn>.

* The PUA symbols at U+EFFD through U+EFFF are for internal use, and you don't need to include them in the font data, and it will save space if you don't.

* The block names are used in filenames, and so it would be better to not include spaces in them (e.g., "PrivateUseArea" rather than "Private Use Area"). I suspect that simply removing the spaces should be sufficient.

* Some browsers can't access the SMP (plane 1), and so can't access the math alphabet characters in the locations that they normally occupy. The MathJax web fonts don't use plane 1 for that reason, and so the fonts of Fraktur, script, etc, have those characters in the normal ASCII alphabetic positions. Since you have separate fonts for these as well, I'm wondering if it wouldn't be better to move the characters from plane 1 to those locations as well. This makes it easier to use those fonts for things like CSS styling of the corresponding attributes (as you do now with the MathJax fonts in Firefox).

> A way to split the font metrics data would be to use the attached file and to add only a few characters in the "Main" section. So my idea is to add a "Main" section for all the "STIX_Main-*" and "STIX_Math_Size*". This "Main" section will contain all the characters that are in the "Main R"/"Main B"/"Main I"/"Main BI" in the old font data [1]. Also, for the "STIX_Math_Size*", perhaps I should put all the remaining characters in the "All" section rather than using separate sections for each unicode block.
>
> Does that sound a reasonable approach?

It looks like STIX_Main is basically the Main.js from the original, so loading all its data (as you do now) would be OK. I think it is also OK to do as you say with the Math_Size* files. So yes, this sounds reasonable.

> Another question: the TeX's config.pl data contains a %test that I guess is necessary for Web fonts. How am I supposed to choose these strings?

They are chosen by hand to include characters within the font, ideally ones whose widths would help distinguish them from normal fonts, like Times, during the font detection process.

Davide

[Frédéric WANG]

On 15/04/2013 15:55, Davide P. Cervone wrote:
> OK, I've look through this, and am starting to understand the layout
> better. I was misunderstanding the Normal and Main breakup originally.
> It looks like STIX_Main is what was in the Main.js file of the breakup
> of the original STIX fonts, while NORMAL is really just the math
> alphabets. That makes your comments about the mathvariants more clear.
> I will have to look back at the fontdata.js file now and see if I can
> make better sense out of that.

> * Some browsers can't access the SMP (plane 1), and so can't access the math alphabet characters in the locations that they normally occupy. The MathJax web fonts don't use plane 1 for that reason, and so the fonts of Fraktur, script, etc, have those characters in the normal ASCII alphabetic positions. Since you have separate fonts for these as well, I'm wondering if it wouldn't be better to move the characters from plane 1 to those locations as well. This makes it easier to use those fonts for things like CSS styling of the corresponding attributes (as you do now with the MathJax fonts in Firefox).

Yes, that's what I mentioned in the original proposal "We can probably
do a remapping to ASCII positions (as we do for the MathJax fonts) to
avoid bugs with some browsers not able to access non-BMP characters.".
However, it was still not clear how the Bold/Italic/BoldItalic style and
Bold/Italic/BoldItalic mathvariant would be handled when I wrote that.
Finally, I decided to put the Bold/Italic/BoldItalic Mathematical
Alphanumeric Symbols in a separate "Normal" font (for lack of a better
name). This can still be changed of course. I was also a bit concerned
about whether we should try to keep all the glyphs from the original
STIX fonts (for example because of legal issues) or if we could get rid
of duplicate glyphs. At the moment, everything is preserved.

> I still want to look very carefully at what glyphs are in some of the
> fonts. For example, I see some arrows are in STIX_Main, like the
> diagonal ones, but not the horizontal or vertical ones. Those are in
> STIX_Arrows, but not the diagonals. So I'm a little confused by that.

The exact operations are the following:

https://github.com/fred-wang/MathJax-dev/blob/open-type-fonts/fonts/OpenTypeMath/splitMain.py#L40

So Main-* fonts contain the "Basic Latin", "Greek and Coptic" and
"Specials" blocks as well as the characters from the MathJax_Main font.
This was in the original proposal:

"These fonts will contain the glyphs from Basic Latin Unicode block
(U+0000 to U+007F) as well as the characters from the MathJax-Main
fonts. This may also contain the "Replacement character" (U+FFFD)."

The original proposal mentioned the "STIX_AMS-*" and "STIX_Greek-*"
fonts, but they have finally been merged in the Main-* font. The idea is
to have the most used characters in these Main-* fonts.

> * Since each font must contain the space character U+0020, you should include that in the data (since the space could be used in something like <mn mathvariant="double-stuck">ONE HUNDRED</mn>.

> * The PUA symbols at U+EFFD through U+EFFF are for internal use, and you don't need to include them in the font data, and it will save space if you don't.
> * The block names are used in filenames, and so it would be better to not include spaces in them (e.g., "PrivateUseArea" rather than "Private Use Area"). I suspect that simply removing the spaces should be sufficient.

OK, I'll take care of the other comments.