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
711 bytes, 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: