Closed Bug 15391 Opened 25 years ago Closed 23 years ago

MathML not enabled in nightly builds

Categories

(Core :: MathML, defect, P2)

Product:
Core
Component:
MathML
Type:
defect

Tracking

()

Status:
RESOLVED FIXED

People

(Reporter: ian, Assigned: rbs)

References

(
URL
)

Details

Attachments

(1 file, 1 obsolete file)

Patch for configure.in which enables MathML unless --disable-mathml is given
(deleted), patch
Details | Diff | Splinter Review
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?
QA Contact: py8ieh=bugzilla
[Installing myself as QA contact.]
Status: NEW → ASSIGNED
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.
Test case fixed. Broke out bug 15402 for the whitespace issue.
Priority: P3 → P2
Testcase is not using the official MathML namespace which is: <math xmlns"http://www.w3.org/1998/Math/MathML>
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?
OS: Windows 98 → All
Hardware: PC → All
It'd be nice to get this done for Mozilla0.9. See discussions in n.p.m.mathml. Gerv
Keywords: mozilla0.9
hixie: do you think this is a blocker? I too agree this is not exactly one...
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?
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-#ifdef-ed? 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...
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...
I guess at some point I will have to let that code go out there. There are no #ifdef'ed code-sections 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 MathML-enabled and non-MathML-enabled 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 "drop-in" 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 non-standard way that prevents cross-browser usage. One has to tweak the DOCTYPE: Tweak the official XHTML DOCTYPE: <!DOCTYPE html PUBLIC "-//W3C//DTD XHTML 1.0 Strict//EN" "DTD/xhtml1-strict.dtd"> To the following non-standard 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/xhtml-math11-f.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>...
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?
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/xhtml-math11-f.dtd"> Added dependency on bug 67646: ".xhtml to XML if pref is set." This is needed for cross-platform 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 auto-installing 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).
Depends on: 44458, 67646
Depends on: 74821
Depends on: 39411
Depends on: 86247
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...
Keywords: mozilla1.0
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...
Is there any "blocker" which prevents us from hacking configure.in and turn --enable-mathml into a --disable-mathml ?
(sorry for the mistake in the previous patch)
Attachment #61027 - Attachment is obsolete: true
I have opened bug 109826 to address any fix-ups that super-reviewers may require. See my post dated Dec 04 entitled "--enable-mathml" 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 "to-the-point" 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.
Depends on: 119080
Fix landed in bug 109826. Resolving as FIXED.
Status: ASSIGNED → RESOLVED
Closed: 23 years ago
Resolution: --- → FIXED
You need to log in before you can comment on or make changes to this bug.

Attachment

General

Creator:
Created:
Updated:
Size: