Closed Bug 19398 Opened 21 years ago Closed 20 years ago
Ensure that Math
ML compiles successfully in the M12 tarball
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 tarball. 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.
Thanks for the info... About the demo: The DOM Viewer has a demo. Please ask firstname.lastname@example.org 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).
Hi, 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: http://www.cygnus.com/misc/wp/nov97/lex.html#lex.operators
What about hacking around those problems with #define's - not nice but should work. Or grab the Sun WS 6EA compiler from http://access1.sun.com/workshop6ea/ 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 email@example.com, when I tried the link you gave, I am getting the error message: Forbidden 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.
ALERT ALERT. 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...
Status: ASSIGNED → RESOLVED
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: ftp://ftp.mozilla.org/pub/mozilla/nightly/latest/mozilla-source.tar.gz 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.
Status: RESOLVED → REOPENED
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 http://puck.informatik.med.uni-giessen.de/download/mozilla-sparc-sun-solaris2.7-M12.tar.gz inclduing mathML, OJI, IRC etc. Thanks ! ---- Changing "summary" and reopen the bug... the same game for M13... =:-)
Clearing FIXED resolution due to reopen.
Status: REOPENED → RESOLVED
Closed: 20 years ago → 20 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.
Status: RESOLVED → VERIFIED
You need to log in before you can comment on or make changes to this bug.