1007090 - Remove the *.properties tables used for the MathML stretchy operators

Status: NEW

(Core :: MathML, defect)

Description

[Frédéric Wang (:fredw)]

This is for the long term when all the supported platforms have migrated to OpenType MATH fonts.

The glyph tables loaded in InitGlobal can be dropped, the nsPropertiesTable class could be removed and the nsMathMLChar code could probably be simplified. The only table that could remain is the generic Unicode table (mathfontUnicode.properties), but maybe we can handled it differently and will only be needed when MATH fonts are not used.

Comment 1

[Frédéric Wang (:fredw)]

As a side note, I was doing some experiments for WebKit and it seems that the STIX Math font is not installed by default on Mac. I've reported this to Apple bug tracker.

Comment 2

[Frédéric Wang (:fredw)]

Currently, we have the following *.properties files:

1) MathJax_Main: this file has always only given partial support, MathJax fonts are not installed by default on any platform and MathJax never served these WOFF fonts for the native MathML rendering, anyway. One of the reason to support it was to replace the old "Computer Modern" style, but this role is now played by Latin Modern Math. So I think we can safely remove it now.

2) StandardSymbolsL: according to Karl, this is installed on some Linux platforms. However, it might not be very important given that DejaVu is installed by default and has the same coverage. So I think we can safely remove it now.

3) Symbol: this one is only installed by default for Windows but necessary when Cambria Math is absent.

4) STIXGeneral: this one is only installed by default on Mac >= Lion. I expect and hope that Apple will eventually upgrade to the latest STIX version, but I didn't see any progress so far.

5) Unicode: this is used to provide basic support with Unicode constructions. It won't be necessary if a font with a MATH table is available. In particular, it is necessary for DejaVu on Linux until distributions upgrade to the version 2.35.

Comment 3

[Frédéric Wang (:fredw)]

Attachment: MOZTIXMath-Regular.woff

In order to avoid potential pain caused by dropping 2), 3, 4), 5) and to provide a minimal support for stretchy operators, I've started to prepare a subset of the STIX 1.1.1 fonts that we could try and bundle into Firefox. See the attachment and the GitHub repository:

https://github.com/fred-wang/MOZTIX

The font essentially contains all the stretchy operators from STIX 1.1.1 as well as the italic, script, fraktur and double-struck characters. We can still try to have a smaller subset in order to reduce the font size. STIX 1.1.1 covers all stretchy operators provided by 2), 3), 4), 5) with some exceptions indicated in the script: https://github.com/fred-wang/MOZTIX/blob/master/MakeFont.py#L196

At the moment, the WOFF version of MOZTIX takes 67kb and the WOFF2 version 58.9kb. The *.properties files compressed into a zip archive, take ~7.6kb. I'm curious to see how much we can win by dropping the whole support for *.properties file and cleaning up the code.

Comment 4

[Frédéric Wang (:fredw)]

Attachment: Part 1 - Remove the nsPropertyTable's

Comment 5

[Frédéric Wang (:fredw)]

Attachment: Part 2 - Add MOZTIX fonts

This is an attempt to bundle the MOZTIX fonts as WOFF fonts. But it does not seem to work.

Comment 6

[Frédéric Wang (:fredw)]

(In reply to Frédéric Wang (:fredw) from comment #5)
> This is an attempt to bundle the MOZTIX fonts as WOFF fonts. But it does not
> seem to work.

OK I stand corrected, I tried again it does work. (I previously tried to clear font.name.x-math and it seems that it prevents to use the MOZTIX fallback in font.name-list.x-math. If I set font.name.x-math to an explicit font e.g. "Arial", then the MOZTIX fallback is taken).

Comment 7

[Frédéric Wang (:fredw)]

Attachment: Part 1 - Remove the nsPropertyTable's

Comment 8

[Frédéric Wang (:fredw)]

Latest stats:

MOZTIX 12/06/2015

    STIXMath-Regular.otf: 476.9kb (476872 bytes)
    MOZTIXMath-Regular.otf: 101kb (101024 bytes)
    MOZTIXMath-Regular.woff: 70.6kb (70556 bytes)
    MOZTIXMath-Regular.woff2: 58.6kb (58616 bytes)

Comparison of sizes with/without the patches applied:

https://treeherder.mozilla.org/#/jobs?repo=try&revision=f7e779210c3d
https://treeherder.mozilla.org/#/jobs?repo=try&revision=5afa28cdbe84

firefox-41.0a1.en-US.linux-x86_64.tar-.bz2 | 54518058 bytes
firefox-41.0a1.en-US.linux-x86_64.tar.bz2 | 54564245 bytes
firefox-41.0a1.en-US.mac-.dmg | 103072068 bytes
firefox-41.0a1.en-US.mac.dmg | 103117196 bytes
firefox-41.0a1.en-US.win32.installer-.exe | 41791520 bytes
firefox-41.0a1.en-US.win32.installer.exe | 41848992 bytes
firefox-41.0a1.en-US.win32-.zip | 50955316 bytes
firefox-41.0a1.en-US.win32.zip | 51013607 bytes

Currently, this increases the size of release bundles by 45-60kb. We can probably simplify the font / code further.

Comment 9

[Frédéric Wang (:fredw)]

(In reply to Frédéric Wang (:fredw) from comment #6)
> (In reply to Frédéric Wang (:fredw) from comment #5)
> > This is an attempt to bundle the MOZTIX fonts as WOFF fonts. But it does not
> > seem to work.
> 
> OK I stand corrected, I tried again it does work. (I previously tried to
> clear font.name.x-math and it seems that it prevents to use the MOZTIX
> fallback in font.name-list.x-math. If I set font.name.x-math to an explicit
> font e.g. "Arial", then the MOZTIX fallback is taken).

This is not quite true, I'm still not sure why the MOZTIX fallback is sometimes not used. It seems that sometimes the Web font is not downloaded and we need to force it to be used, maybe a problem within nsMathMLChar...

Comment 10

[James Kitchener (:jkitch)]

Attachment: Part 1 - Remove the nsPropertyTable's

Rebased

Comment 11

[Frédéric Wang (:fredw)]

@James: have you made any progress on this?

Comment 12

[James Kitchener (:jkitch)]

The problem is that gecko does not really support omni.ja fallback fonts - only system fonts (or fonts installed in the standard font location) are checked.

The current code for stretchy operators begins to load the font, but the page finishes rendering before it has loaded as there are no callbacks.  When the page is refreshed, the font is in the cache so the page loads correctly.  Adding the font to mathml.css begins the font load earlier and allows correct rendering without reloading the page, but I have yet to prove correct behaviour in all situations.  This also works for Mathvariant, providing nobody specifies their own font-family.

I have not yet found a proper solution that works in all cases.

Comment 13

[Frédéric Wang (:fredw)]

Thanks. I suspect the code in nsMathChar will somewhat have to force a reflow after the web font is loaded.

Note sure that helps, but:
- Bug 736010 was the place when made downloaded fonts usable in nsMathChar
- In the experimental attachment 636771 [details] [diff] [review], I was testing whether the web font are loading before displaying a missing font warning.

Comment 14

[Frédéric Wang (:fredw)]

Attachment: Default installed fonts on popular Linux distributions

I'm attaching a list of default installed fonts on popular Linux distributions.

Reading it, our best bet seems to be to wait for a "DejaVu Math" font since the DejaVu families looks to be installed by default on all distros.

Kudos to Fedora for making STIX fonts available by default. It's still version 1.1.0, though. So we'll have to wait the 2.0 release to get decent OpenType math support.

Comment 15

[Frédéric Wang (:fredw)]

I updated https://github.com/fred-wang/MOZTIX with STIX2. Some of the size variants have been removed when a glyph assembly exists in STIX2. The new stats are:

STIX2Math.otf: 738K (755584 bytes)
MOZTIXMath-Regular.otf: 152K (155524 bytes)
MOZTIXMath-Regular.woff: 97K (98968 bytes)
MOZTIXMath-Regular.woff2: 88K (89676 bytes)

Comment 16

[Frédéric Wang (:fredw)]

Attachment: Hardcode the Unicode Table

This is an alternative option after bug 1335124 and bug 1336058. The remaining *.properties table is the Unicode one and this patch make it hardcoded into the C++ source. Things are also simpler because we no longer use external fonts.

Comment 17

[Frédéric Wang (:fredw)]

(In reply to Frédéric Wang (:fredw) from comment #16)
> Created attachment 8833060 [details] [diff] [review]
> Hardcode the Unicode Table
> 
> This is an alternative option after bug 1335124 and bug 1336058. The
> remaining *.properties table is the Unicode one and this patch make it
> hardcoded into the C++ source. Things are also simpler because we no longer
> use external fonts.

To get even more cleanup and speedup, I was also thinking we could have a single nsGlyphTable class that for a given font, reads data from the MATH table (if any) or fallback to hardcoded unicode constructions. The first MATH font would be selected or otherwise the first font in the font group. We should also consider again getting rid of Unicode code points and move to glyph-only manipulation.

Comment 18

[Karl Tomlinson (:karlt)]

Comment on attachment 8833060 [details] [diff] [review]
Hardcode the Unicode Table

I haven't studied all the details here, but an internal array should be fine,
if or when bug 1336058 can land.

>-  if (aGlyphCode.font) {
>-    glyphCodeFont.Append(aGlyphTable->FontNameFor(aGlyphCode));
>+  if (aGlyphTable && !aGlyphTable->IsUnicode()) {
>+    aGlyphTable->AppendFontFamilyName(glyphCodeFont);
>   }

I prefer the previous code because it is clear that it is glyphCodeFont, not
aGlyphTable that is being modified.  There is now no aGlyphCode, but could the
glyph table have a FontName() method?

Comment 19

[Karl Tomlinson (:karlt)]

(In reply to Frédéric Wang (:fredw) from comment #17)
> To get even more cleanup and speedup, I was also thinking we could have a
> single nsGlyphTable class that for a given font, reads data from the MATH
> table (if any) or fallback to hardcoded unicode constructions.

A glyph table for a font sounds reasonable, if fallback is not an issue
(see below).

> The first MATH font would be selected or otherwise the first font in the
> font group.

I think we'd need a good reason to deviate from the CSS-specified font search.
i.e. All specified and default fonts and should be considered.
Fallback can be searching for a MATH font and using a single glyph when that
doesn't help, if that is not a significant regression.

> We should also consider again getting rid of Unicode code
> points and move to glyph-only manipulation.

If it is likely that we can expect at some point that a MATH font will be
installed, then it may make sense to delay refactoring until that
point in time.  It's a question of what the value is in refactoring now.

Comment 20

[Karl Tomlinson (:karlt)]

(In reply to Karl Tomlinson (:karlt) from comment #19)
> I think we'd need a good reason to deviate from the CSS-specified font
> search.

I have expanded on this at https://bugzilla.mozilla.org/show_bug.cgi?id=1009582#c33 after reading through the comments there.

Comment 21

[BugBot [:suhaib / :marco/ :calixte]]

The bug assignee is inactive on Bugzilla, so the assignee is being reset.

Comment 22

[Suhaib Mujahid [:suhaib]]

Sorry, there was a problem with the detection of inactive users. I'm reverting the change.