For m0.9.9, Dawn was hunting for a MathML sample page that won't require the user to resolve the hurdle of fonts first (c.f. bug 125404). Let's see what the MML JS editor guy think here... Over to you, Steve. Here is an example: http://www.w3.org/Math/testsuite/Presentation/TablesAndMatrices/mtable/mtable2.x html Looks like something could be cooked with some flashy colors and perhaps equations that can stretch well when only the Symbol font that everybody has is there.

I've posted a preliminary sample at http://www.newmexico.mackichan.com/MathML/Mozilla/basics.xml I still get the warning about missing fonts, but it renders correctly. Is this what we want? There is an example with <maction>, but otherwise I object to flashy colors on the grounds that mathematics is rarely colored or styled.

It is coming along nicely. Here is a link to another type of example that can work well with the Symbol font (see mathfontSymbol.properties for the full list of characters such as '{', '|', etc that can stretch well with the Symbol font) http://www.w3.org/Math/testsuite/Presentation/GeneralLayout/mfenced/mfencedAdeli ms6.html As for the colors, since this is a technology demonstration, I am okay with having bold/italic/color/href'ed/javascript'ed equations to illustrate that the rendering code has such _possibilities_. And this is a page to mostly give a nice first impression to one-off visitors from the mainstream. They won't know that such things (and more) are possible if we don't use that opportunity to mention them. Some other suggestions: . master button: expand all/unexpand all, in the maction sample . link to the screenshots http://www.mozilla.org/projects/mathml/screenshots/ (I recently added links to other screen captures).

My example in comment #1 has been updated.

I have iterated and put it here (as usual, will become active when mozilla.org's website is refreshed): http://www.mozilla.org/projects/mathml/demo/basics.xhtml

Marking FIXED.

reopening. on redhat 7.2 i'm getting extra vertical lines extending down from the integral signs. Mostly from the first integral sign but if i play around with the page i can get it to happen with all of them. The line appears when the page first draws, then if i scroll up and down the line goes away from the part of the screen that was obscured. Covering the page with another window and re-exposing causes the line to reappear. here's another way to get a line: - right click on the mozilla integral. a short line appears - cover this mozilla window with another window. re-expose it. a line appears extending all the way down to the bottom of the window, which is obscured by the mozilla.org banner images from a mail with rbs: > also, is the top row of the x matrix supposed to be even > vertically with the middle row of the a matrix? No. But since you ask, it means others might get confused too. (I might need to find another example). What is happening is that the baseline of the matrix row is aligned with the baseline of the first element in the column vector. So if you abstract the brackets, it is as if a_i1, ..., a_in, x_1 are on the same line.

-> mozilla.0.9.9 for the buggy integral extender. I have a clue where the problem might come from (this font is known to be buggy -- see also how the right parenthesis doesn't align properly). I will need your testing once I come up with a patch in the next day local time... (I am going off at the moment).

The problem was due to platform differences in FillRect(). When the partial glyphs for the top and bottom of the integral are sufficient to cover the desired area, the remaining rect for the middle part is empty. And when trying to draw a rule with FillRect(), it results in a no-op on Windows but does something else on Linux. The patch has consisted in testing for a non-empty rect before calling FillRect().

Cc:ing roc+moz & attinasi for r/sr

-> re-assigning to myself

Please ignore the /WithConversion/ etc, they will be going away in bug 128139 when these strings are localized.

Comment on attachment 71747 [details] [diff] [review] patch to fix the weird integral r=roc+moz

Awesome demo page, BTW!

Verified that Roger's patch fixes the problem even after scrolling the page around and hiding and re-exposing it. Minor nits: I might change "Without these fonts, Mozilla cannot render the page properly." to this "Without these fonts, Mozilla may not render this page properly." cannot -> may not the -> this Rendering mathml without the mathml fonts is suboptimal, but not completely hopeless.

Did a little lookup in IE following your comments. In an attempt to benefit from this opportunity to make the whole lot less mouthful, want to iterate on this? "This page contains MathML. Mozilla has detected that some of the fonts needed for quality rendering of MathML are missing from your system. To render MathML in Mozilla properly, you need to install the following fonts: [missing fonts]. For further information see: http://www.mozilla.org/projects/mathml/fonts"

How about: To properly display the MathML on this page you need to install the following fonts: [missing fonts]. For further information see: http://www.mozilla.org/projects/mathml/fonts/ and change the behaviour of the dialog so the mathml page loads right away (as in msie) and the dialog appears on top of the broken page instead of blocking it. Doing that would make it obvious what 'this' is. Or just change the wording now and change the behaviour later.

...I am now quickly looking into the APIs to see if it is easy to change the behavior. Actually, IE itself is not displaying the dialog on top of the page. The page that is triggering the dialog is the one that I manually typed in (c.f. URL bar & status/progress bars) that is about to be loaded. Also, the dialog is only once per session. So if the user revisits a page later on, nothing will show up. Do you have another wording which reflects that too (i.e., more general than just 'this page')? I guess bad looking MathML will jot the memory of the user, so I will be fine with your current iteration anyway since it is already very concise.

Ok then. feel free to forget the behaviour change. I think i like this wording the best either way. Anything that's more precise is less concise. I think being less concise is more confusing than the slight ambiguity of using the word 'this' before the subject is displayed.

Changed the behavior from modal (wait for input from user) to non-modal (don't wait for input from user). In fact, I left both behaviors with an #ifdef but the default is now non-modal and so the message shows up on the faulty page itself.

I tried '\n' just to see and noted that it does line breaking... So I made this final screenshot with: To properly display the MathML on this page you need to install the following fonts:\n [missing fonts].\n\n\n For further information see:\n http://www.mozilla.org/projects/mathml/fonts

Comment on attachment 71825 [details] [diff] [review] updated patch (improved wording & non-modal behavior) carrying r=roc+moz forward

Comment on attachment 71825 [details] [diff] [review] updated patch (improved wording & non-modal behavior) sr=attinasi

Comment on attachment 71825 [details] [diff] [review] updated patch (improved wording & non-modal behavior) Can we lose the huge #if 0 block?

the patch works great for me. The integral sign works now and the font warning dialog is very readable and more pleasant to deal with now that it doesn't block page loading.

Comment on attachment 71825 [details] [diff] [review] updated patch (improved wording & non-modal behavior) Forget that #ifdef question -- I missed your comment before. a=shaver for 0.9.9.

Fix checked in. Got rid of the huge #if 0 block following the further thought that it can be grabbed from this bug if needed (which is now improbable since the non-modal version is much pleasant in this situation).

Backed out, got confused about the status of the tree and saw dp's checkin comment later on. Will re-checkin later.

Just a question, couldn't it be possible to make the URL described in the dialog clickable? This is a generic request and not specific to this dialog.

When I was doing the patch, I tried <a href="...">...</a> and it didn't work, and I didn't bother to look further. But having done a bit of digging now, the function that is doing the formatting is the following one. See how it creates <description> elements with their content set as text node (line 95): http://lxr.mozilla.org/seamonkey/source/xpfe/global/resources/content/commonDialog.js#88 (and BTW... that file is full of those magic numbers used in SetInt()/SetString() in my patch) Noted that the back-end code for the <description> element boils down to the "area frame" which is used for other elements such as <div>. So in principle it is possible to have active links by creating a nested dom tree rather than just a flat text node (although where the links would lead to in modal mode is unclear)... Feel free to open a but against the XUL folks about the links.

-> Follow-up for the clickable link: bug 130023