Closed
Bug 177474
Opened 23 years ago
Closed 23 years ago
Mozilla fails to render MathML with certain header
Categories
(Core :: MathML, defect)
Tracking
()
RESOLVED
INVALID
People
(Reporter: khamilton, Assigned: rbs)
Details
User-Agent: Mozilla/5.0 (Windows; U; WinNT4.0; en-US; rv:1.2b) Gecko/20021016
Build Identifier: Mozilla/5.0 (Windows; U; WinNT4.0; en-US; rv:1.2b) Gecko/20021016
Experimenting with MathML, I used the Wolfram Research site
(http://www.mathmlcentral.com/Tools/MSP/FromMathML) to generate an XHTML output.
Upon insertion into Mozilla, I get a parsing error. If I change the header to
correspond to MOzilla MathMl examples, it parses and renders okay. Amaya will
render either version.
Reproducible: Always
Steps to Reproduce:
1. Try to open "wolf.xml" in Mozilla.
2.
3.
Actual Results:
XML Parsing Error: undefined entity
Location: file:///E:/kgh/mathweb/wolf3.xml
Line Number 11, Column 10:
<mo>∫</mo>
---------^
Expected Results:
Rendered the math.
Here is the source of "wolf.xml"
--------------------------------------------------------------------------------
<?xml-stylesheet type="text/xsl" href="http://www.w3.org/Math/XSL/mathml.xsl"?>
<html xmlns='http://www.w3.org/1999/xhtml'>
<head>
<title>XHTML Content - Created by webMathematica</title>
</head>
<body>
<math xmlns='http://www.w3.org/1998/Math/MathML'>
<mrow>
<msubsup>
<mo>∫</mo>
<mi>a</mi>
<mi>b</mi>
</msubsup>
<mfrac>
<mtext>dx</mtext>
<mi>x</mi>
</mfrac>
<mo>=</mo>
<mo>ln</mo>
<mfrac>
<mi>b</mi>
<mi>a</mi>
</mfrac>
</mrow>
</math>
</body>
</html>
-------------------------------------------------------------------------
Here is the source with revised header, which does render in Mozilla:
--------------------------------------------------------------------------
<?xml version="1.0"?>
<!DOCTYPE html PUBLIC "-//W3C//DTD XHTML 1.1 plus MathML 2.0//EN"
"http://www.w3.org/TR/MathML2/dtd/xhtml-math11-f.dtd" [
<!ENTITY mathml "http://www.w3.org/1998/Math/MathML">
]>
<html xmlns="http://www.w3.org/1999/xhtml">
<head>
<title>XHTML Content - Created by webMathematica</title>
</head>
<body>
<math xmlns="http://www.w3.org/1998/Math/MathML">
<mrow>
<msubsup>
<mo>∫</mo>
<mi>a</mi>
<mi>b</mi>
</msubsup>
<mfrac>
<mtext>dx</mtext>
<mi>x</mi>
</mfrac>
<mo>=</mo>
<mo>ln</mo>
<mfrac>
<mi>b</mi>
<mi>a</mi>
</mfrac>
</mrow>
</math>
</body>
</html>
|
||
Comment 1•23 years ago
|
||
> xmlns='http://www.w3.org/1998/Math/MathML'
That doesn't look like a valid MathML namespace (particularly, that would not
lead to the MathML entities being loaded from the DTD, since the DTD is for the
published 1999 version of MathML).
re: bz, the namspace is OK -- that's the one of MathML. It is the XHTML
namespace that was dated in 1999.
re: reporter, please report the problem to the folks of Wolfram Research who
maintain the site. As you saw, the problem is due to the entity <mo>∫</mo>.
To use such entities, the document _must_ have a DOCTYPE declaration in its
header to allow any conforming XML parser to reslove these entities to their
corresponding Unicode values.
Alternatively, if the document doesn't specify a DOCTYPE, it ought to refer to
these characters using their equivalent built-in numeric character references
(either in decimal form ∫ or hexadecimal form &x#222B;).
So the problem is that the Wolfram Research site is producing an invalid
document. I am marking the bug as such.
Status: UNCONFIRMED → RESOLVED
Closed: 23 years ago
Resolution: --- → INVALID
|
|
Reporter | |
Comment 3•23 years ago
|
||
Thank you for the quick response.
I passed the information along to Wolfram Research, as you requested.
I am still a little curious as to how Amaya handled it without a
problem. Perhaps because it is also a MathML editor it had these
characters as a native resource?
Amaya seems to be doing something special indeed.
According to the XML spec, a document is free to use any &MyEntityOfChoice;
However, in order for that to make sense in the user agent, the document must
also define what "MyEntityOfChoice" maps to, and that's where the DOCTYPE (or
more precisely the DTD) comes into play.
You need to log in
before you can comment on or make changes to this bug.
Description
•