Closed
Bug 15391
Opened 21 years ago
Closed 19 years ago
MathML not enabled in nightly builds
Categories
(Core :: MathML, defect, P2)
Core
MathML
Tracking
()
RESOLVED
FIXED
People
(Reporter: ian, Assigned: rbs)
References
()
Details
Attachments
(1 file, 1 obsolete file)
STEPS TO REPRODUCE 1. Download and install latest nightly build. 2. Run viewer. 3. Go to: http://www.bath.ac.uk/%7Epy8ieh/internet/projects/mozilla/mathml/concept.xml ACTUAL RESULTS The math doesn't look like an equation to me! EXPECTED RESULTS There should be an equation below the paragraph. NOTES The MathML is included inline using namespaces. Here is the markup for the equation bit: <math xmlns="http://www.w3.org/Math/MathML"> <mrow> <mi> F </mi> <mo> = </mo> <mi> m </mi> <mfrac> <mrow> <mi>d</mi> <mi>v</mi> </mrow> <mrow> <mi>d</mi> <mi>t</mi> </mrow> </mfrac> </mrow> </math> Should that work?
Reporter  
Updated•21 years ago

QA Contact: py8ieh=bugzilla
Reporter  
Comment 1•21 years ago


[Installing myself as QA contact.]
Accepting the bug. Still working to get MathML properly hooked with the rest of the build system. Meanwhile, replace <tag> text </tag> with <tag>text</tag> in your test cases, for example <mo>=</mo> instead of <mo> = </mo>. Ignorable whitespace is not yet handled properly on *leaf* tags.
Updated•21 years ago

Priority: P3 → P2
Testcase is not using the official MathML namespace which is: <math xmlns"http://www.w3.org/1998/Math/MathML>
Comment 5•21 years ago


This is labled as blocker. I think is should only be major (but not more than critical). If this is a blocker it would be nice to know a Milestone. Either M17 or something M20+. Can somebody change the OS field to all?
Updated•21 years ago

OS: Windows 98 → All
Hardware: PC → All
Comment 6•20 years ago


It'd be nice to get this done for Mozilla0.9. See discussions in n.p.m.mathml. Gerv
Keywords: mozilla0.9
Comment 7•20 years ago


hixie: do you think this is a blocker? I too agree this is not exactly one...
Reporter  
Comment 8•20 years ago


It's a blocker  it blocks use a MathML in stock Mozilla nightly builds. Also, since our MathML support is more solid that some of our CSS support, and the CSS is turned on, I see no reason not to turn on MathML. CC'ing a couple of driver folks  dbaron, asa: can we get some traction on this? Is there any reason we couldn't do it? rbs: Would you be in favour or against doing this?
Comment 9•20 years ago


A few questions: * What's the status of MathML on Mac? * Are there any sections of core layout code that are currently #ifdef MOZ_MATHML that were intended to be reviewed and un#ifdefed? If so, they probably should be first. * What are the size differences in the libraries (layout, gfx, ??)? * What's the current level of our MathML support? Is it MathML 1.0 within XML? (And is that officially sanctioned by a W3C REC?) I would like to see MathML in the nightlies too (since this would allow people to start using MathML on the web in some limited contexts), but I'm trying to ask some of the questions we should ask first...
Reporter  
Comment 10•20 years ago


I can't answer those, but regarding the parenthetical comment: MathML is an XML application, and embedding MathML within other XML is "officially" sanctioned with the use of namespaces, which is how we do it, so I guess the answer to that is "yes, it's officially sanctioned". As official as these things get, anyway, which isn't _that_ official when it gets to namespaces...
Assignee  
Comment 11•20 years ago


I guess at some point I will have to let that code go out there. There are no #ifdef'ed codesections waiting for review. All of them have been reviewed. The size differences are not really significant (they can be seen at the release pages where MathMLenabled and nonMathMLenabled builds are shown side by side)  and after all, adding something comes with a little overhead. So the question for the drivers is really whether it is worth it or not. Personally, although the size increase is not significant, I think that this question shouldn't bear too much weight in the first place. (The bigger fish is the work needed to get an installable "dropin" component that users could select/deselect.) But apart from the fact that the Mac is still lagging behind, I still feel uncomfortable with some issues that are going to alienate people, and for mathml to be enabled, mozilla.org's drivers really need to mean business and push for these issues to be addressed first. Currently, the mathml fragment is activated in a nonstandard way that prevents crossbrowser usage. One has to tweak the DOCTYPE: Tweak the official XHTML DOCTYPE: <!DOCTYPE html PUBLIC "//W3C//DTD XHTML 1.0 Strict//EN" "DTD/xhtml1strict.dtd"> To the following nonstandard version which causes Amaya to choke, and which has been the cause of reported complaints from a number of people (including from the W3C UI Project Lead): <!DOCTYPE html PUBLIC "//W3C//DTD XHTML 1.0 Strict//EN" "mathml.dtd"> The recommended DOCTYPE in the mathml spec is, <!DOCTYPE html PUBLIC "//W3C//DTD XHTML 1.1 plus MathML 2.0//EN" "http://www.w3.org/TR/MathML2/dtd/xhtmlmath11f.dtd" > where, quoting from the spec, "the URI may be altered to that of a local copy of the DTD, and the namespace prefixes used for XHTML and MathML may be controlled by the use of parameter entities." Fixing the DOCTYPE handling would also require loading the over 2000 MathML entities as part of bug 44458. Much effort has been put in the stretching code but what to do without fonts!?! Rendering with mathfonts and without mathfonts is like day and night. I have received promises from Design Science (makers of MathType) and Wolfram Research (makers of Mathematica) that they may release their fonts under licences that are both agreable to them and to mozilla.org. The fonts are crucial for decent mathml rendering. So the fonts need to be bundled with Mozilla. Some other issues that need appraisal are for example: checking what happens with dynamic updates, printing, the dreaded <mtable>...
Comment 12•20 years ago


rbs, can you please file bugs for each of the issues that are blocking this bug (i.e. preventing MathML to be turned on in the nightlies) and add them to this bug's dependencies? This would make it more obvious if there's any progress, and if not, why not. (I'm involved with a project that, among other things, generates MathML, so I'm very much interested that this happens soon.) If I understand your last comment correctly, there are at least 2 such bugs that should be filed: 1.) doctype issues with MathML 2.) need to bundle MathML fonts with mozilla Maybe 2.) need to be separate bugs for each platform?
Assignee  
Comment 13•20 years ago


Added dependency on bug 44458: "HTML entities are not recognized in XHTML documents." If this is fixed, it could be extended to handle the MathML case as a particular case using the doctype: <!DOCTYPE html PUBLIC "//W3C//DTD XHTML 1.1 plus MathML 2.0//EN" "http://www.w3.org/TR/MathML2/dtd/xhtmlmath11f.dtd"> Added dependency on bug 67646: ".xhtml to XML if pref is set." This is needed for crossplatform compatibility. Also, so far Mozilla is not passing the MathML testsuite (http://www.w3.org/Math/testsuite/) as a result of this limitation. Andreas, go ahead and file a bug about bundling and autoinstalling the fonts if the user checks the XPI button to that effect (some of the fonts have their improved commercial versions and the user needs to okay the install process so that no unintended overwritting happens). Then I will add a dependency (or you can do both  file the bug and add a dependency).
Comment 14•20 years ago


I have filed bug 86247 about the fonts. When can we expect MathML to be enabled by default? It would be nice if someone could at least give a rough estimate for the year...
Updated•19 years ago

Keywords: mozilla1.0
Comment 15•19 years ago


What about this bug? blocker since 1999? 0_o Would be cool to have him in the nightly builds... also for release currently choise is between MathML and TalkBack... and I always finish preferring the TalkBack rversion...
Comment 16•19 years ago


Is there any "blocker" which prevents us from hacking configure.in and turn enablemathml into a disablemathml ?
Comment 17•19 years ago


Comment 18•19 years ago


(sorry for the mistake in the previous patch)
Attachment #61027 
Attachment is obsolete: true
Assignee  
Comment 19•19 years ago


I have opened bug 109826 to address any fixups that superreviewers may require. See my post dated Dec 04 entitled "enablemathml" on n.p.m.mathml for a panoramic pitcure of where things stand at the moment. I also posted an updated progress report (see the MathML project page) to inform users as to what to expect when MathML is enabled. What I need right now are the "sizes" (the size with MathML on, and the size with MathML off). If you have such figures, please provide them on bug 109826 (which is a kinda "tothepoint" portfolio bug of the impact of MathML). Once all these data are in, patches to enable MathML in the build could be attached there as well.
Assignee  
Comment 20•19 years ago


Fix landed in bug 109826. Resolving as FIXED.
Status: ASSIGNED → RESOLVED
Closed: 19 years ago
Resolution:  → FIXED
You need to log in
before you can comment on or make changes to this bug.
Description
•