Open
Bug 1007090
Opened 10 years ago
Updated 1 year ago
Remove the *.properties tables used for the MathML stretchy operators
Categories
(Core :: MathML, defect)
Core
MathML
Tracking
()
NEW
People
(Reporter: fredw, Assigned: fredw)
References
(Depends on 1 open bug, Blocks 2 open bugs)
Details
Attachments
(4 files, 3 obsolete files)
96.60 KB,
patch
|
Details | Diff | Splinter Review | |
54.05 KB,
patch
|
Details | Diff | Splinter Review | |
9.98 KB,
text/plain
|
Details | |
51.46 KB,
patch
|
karlt
:
feedback+
|
Details | Diff | Splinter Review |
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.
Assignee | ||
Comment 1•10 years ago
|
||
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.
Assignee | ||
Comment 2•9 years ago
|
||
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.
Assignee | ||
Comment 3•9 years ago
|
||
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.
Assignee: nobody → fred.wang
Assignee | ||
Comment 4•8 years ago
|
||
Assignee | ||
Comment 5•8 years ago
|
||
This is an attempt to bundle the MOZTIX fonts as WOFF fonts. But it does not seem to work.
Assignee | ||
Comment 6•8 years ago
|
||
(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).
Assignee | ||
Comment 7•8 years ago
|
||
Attachment #8612532 -
Attachment is obsolete: true
Attachment #8621838 -
Attachment is obsolete: true
Assignee | ||
Comment 8•8 years ago
|
||
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.
Assignee | ||
Comment 9•8 years ago
|
||
(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...
Assignee | ||
Comment 11•8 years ago
|
||
@James: have you made any progress on this?
Flags: needinfo?(jkitch.bug)
Comment 12•8 years ago
|
||
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.
Flags: needinfo?(jkitch.bug)
Assignee | ||
Comment 13•8 years ago
|
||
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.
Assignee | ||
Comment 14•8 years ago
|
||
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.
Assignee | ||
Comment 15•7 years ago
|
||
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)
Assignee | ||
Comment 16•7 years ago
|
||
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.
Attachment #8833060 -
Flags: feedback?(karlt)
Assignee | ||
Comment 17•7 years ago
|
||
(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•6 years ago
|
||
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?
Attachment #8833060 -
Flags: feedback?(karlt) → feedback+
Comment 19•6 years ago
|
||
(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•5 years ago
|
||
(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 hidden (off-topic) |
Comment 22•1 year ago
|
||
Sorry, there was a problem with the detection of inactive users. I'm reverting the change.
Assignee: nobody → fwang
Updated•1 year ago
|
Severity: normal → S3
You need to log in
before you can comment on or make changes to this bug.
Description
•