Closed Bug 19398 Opened 21 years ago Closed 20 years ago

Ensure that MathML compiles successfully in the M12 tarball


(Core :: MathML, defect, P3)






(Reporter: rbs, Assigned: rbs)


This is a follow-up to bug 19238 where Roland Mainz who is maintaining
semi-official Milestone build on Solaris SPARC asked to ensure that the MathML
should compile successfully if a user decides to enable it on a Milestone

Roland, to answer your question, printing is handled in a similar way
as the screen (via the so-called "presentation context"). Printing
MathML will result from the other work in Gecko, i.e., MathML is
not going to be a special case.

"Saving as text" and clipboard selection are a bit tricky. But we can
choose to do nothing at leave it "as is". This will yield results that
are similar to the results of selecting elements of form(s).
I haven't tried to see what happens when you do copy/paste of MathML :-)

Your suggestion to put a MathML demo is great! If you can look at how
others are done and come up with a patch that gives a menu item for
MathML when #ifdef MOZ_MATHML is set, it will be great.
Target Milestone: M12
Thanks for the info...

About the demo: The DOM Viewer has a demo. Please ask how he
managed to get the "demo" menu entry. Last-but-not-least the demo menu item
should only appear if MathML has been turned-on at compile-time :-)

Support for clipboard/save as text: Solaris 2.7 has a en_US.UTF-8 locale and
matching converters. is it possible to (mis-)use this for our needs ?
Sorry, I am chasing other pressing issues right now and cannot start
investigating how to hook a demo at this stage. Hope you don't mind
helping with it. You can approach alecf for hints, saying you want
to hook a submenu for MathML, and see what he says. I think hooking
a MathML submenu with items that demonstrate some particular facets
of MathML is a great idea.

The question with "save as text" is how should equations be formatted.
Should we use some "ascii art" or not. If we only want to output
the text content, then the clipboard component of Gecko will do that
for us (in a XP manner).
I was just trying to compile mozilla with SUNs Workshop 5.0
There is some code #ifdef MOZ_MATHML in nsRenderingContextPS.cpp and .h that
breaks. It returns the following error:

"mozilla/gfx/src/ps/nsRenderingContextPS.cpp", line 1257: Error: A previously
specified default argument value cannot be changed.

The default arg is both in .h and .cpp, and Suns CC seems unhappy about this.

Axel alias Pike
In addition to the problem mentioned by Axel, there is another problem with
nsMathMLAtomList.h and anything that references some of the atoms listed there.
The new ANSI C++ standard defines a bunch of new operators, including "and",
"not", "or", and "xor".  The SUNWspro 5.0 compilers know about these keywords,
and the compile fails because they conflict with the mathml atom names.

The relevant section of the C++ standard:
What about hacking around those problems with #define's - not nice but should
work. Or grab the Sun WS 6EA compiler from
and fix these problems.
"mozilla/gfx/src/ps/nsRenderingContextPS.cpp", line 1257: Error: A previously
specified default argument value cannot be changed.

The declaration under consideration in the function header is
"PRInt32* aFontID=nsnull"

I have landed a change to replace this simply with "PRInt32* aFontID".
To, when I tried the link you gave, I am getting the
error message:

You don't have permission to access /misc/wp/nov97/lex.html on this server.

The conflicting names have been reported also on the Mac sometimes ago.
Mail me a full list of the names where the compiler is chocking, and
I will land the associated changes in the tree.
Odd, that URL still works for me.  The entire list of conflicts was in my

comment: "and", "or", "not", "xor".  Personally I would recommend using a

common postfix on all the atom names (i.e. "notML"), as some of the other

names conflict with standard math.h or posix functions.
Would that be ok to postfix all names with an underscore?
It seems all names prefixed with underscore are reserved to C++ and
their implementators. Does this extend also to postfix?
(The reason I am asking for the underscore is because using an
underscore will make the reading easier).

I saw that you have started to integrate GetBoundingMetrics in
the Xlib port. There is a flaw in the GTK code. The metrics are not
returned in the appropriate character coordinate system. It is just
a matter of flipping some signs as documented in the definition
of the nsBoundingMetrics struct at the bottom of nsIRenderingContext.h.
When the metrics are not returned in a XP manner (a uniform character
coordinate system as expected), glyphs are unexpectedly chopped
(see bug 19024).
That's my understanding of the external symbols rule too; an
underscore postfix should be fine.

I sent you a proposed patch for the font metrics separately
Saw the patch. Looks alright... until testing proves otherwise!
I also saw your note that MathML doesn't work yet, due to the
font stuff. I had hoped that you will come up with the news
that MathML is working with Xlib!

Will be postfixing an underscore on MathML atoms some time soon.
On bug 19024, Shyjan has provided a patch similar to yours to correct
the sign of the metrics on Linux. He also attached a screenshot that
shows that indeed the rendering is as expected when the character
coordinate system is the one expected by the MathML engine.
PS: The MathML code is presently out-of-sync with some recent changes
in layout.
MathML doesn't build (using the nightly 19991205 tarball) and someone wrote that
M12 release date is 19991215. Any build details needed ?
I was entangled in other commitments. It is only now that I have resumed the
work on the MathML engine. A couple of weeks ago, I made some major changes in
my tree to support embellished operators. I will try to approach Chris Hofmann
if I run too late, and tinderbox is closed for M12 stabilization. He is usually
open and understanding.
> He is usually open and understanding.



Has anyone tries to compile the Mozilla with Sun Workshop 6EA ? I tried it and
the build failed very early in the nspr part ;-(
Any hints how to solve the problem ?
Hey,  i resemble that remark. ;-)

how is this one coming?
nicely. one more day of work and testing and it should be ready.
Can someone write here a small note if MathML is ready for M12 ?
I will ask permission to land my changes later today (down under time)
Awaiting clearance to check-in...
Closed: 20 years ago
Resolution: --- → FIXED
all checked in. moving off the m12 radar
1. Does the Linux build work with MathML ?
2. How may I get the pre-M12 sources as tarball (I don't have CVS access yet
;-(  ) ?
About question 2 - Download this file:
This is the source code equivalent of the 'nightly build' binaries.

If you forget that URI you can get to it by going to the Mozilla home, taking
the "more..." link under "Nightly Builds" in the "Download Mozilla" section,
going down to "Nightly Builds", picking "download latest build", and choosing
the right file from the list. (If you do this more than once, make sure you are
displaying the most up-to-date version of the page -- I have often had cache
problems here when using a web browser and not a dedicated FTP program.)

The MathML code is included in that archive.
OK - I thougth that the Milestone-stabilisation-work is done in a seperate
"thread" of the CVS tree...
I'll try the build this weekend... need some sleep now... :-)
Build from mozilla-source-19991215.tar.gz compiles with --enable-mathml
Q: Is there any test case within the MathML code tree ?
Q: What about MathML 2.0 ?
Q1: Yes, in the directory mozilla/layout/mathml/tests/
Q2: We will track the REC. There hasn't been drastic changes
on presentation markup (the part that we are currently coding).
Are you now subscribed to the mathml mailinglist/newsgroup?
Doing so will allow you to stay informed on current developments.
Summary: Ensure that MathML compiles successfully in the M12 tarball → Ensure that MathML compiles successfully in the M13 tarball
M12 build for Solaris 2.7 SPARC ready for download from
inclduing mathML, OJI, IRC etc.
Thanks !


Changing "summary" and reopen the bug... the same game for M13... =:-)
Resolution: FIXED → ---
Clearing FIXED resolution due to reopen.
Target Milestone: M12 → M13
Closed: 20 years ago20 years ago
Resolution: --- → FIXED
Target Milestone: M13 → M12
Re-closing the bug. Please Roland, open a new bug. Many sub-issues have emerged
during the lifetime of this bug. And possibly, other issues may arise while we
try to stay up-to-date with M13. It is better to keep a clear focus.
Let's continue to join our forces and be watchful to ensure that MathML will
also build in M13. Thanks.
Summary: Ensure that MathML compiles successfully in the M13 tarball → Ensure that MathML compiles successfully in the M12 tarball
Okay, posting new bug 22308... :-)
Rubberstamping verified; "the proof is in the pudding" and all that.
You need to log in before you can comment on or make changes to this bug.