125541 - Need sample MathML page for what's new in m0.9.9

Status: RESOLVED FIXED

(Core :: MathML, defect)

Description

[rbs]

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.

Comment 1

[steve.swanson]

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.

Comment 2

[rbs]

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).

Comment 3

[steve.swanson]

My example in comment #1 has been updated.

Comment 4

[rbs]

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

Comment 5

[rbs]

Marking FIXED.

Comment 6

[Dawn Endico]

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.

Comment 7

[Dawn Endico]

Attachment: screen shot of integral

Comment 8

[rbs]

-> 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).

Comment 9

[rbs]

Attachment: patch to fix the weird integral

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().

Comment 10

[rbs]

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

Comment 11

[rbs]

-> re-assigning to myself

Comment 12

[rbs]

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

Comment 13

[Robert O'Callahan (:roc) (email my personal email if necessary)]

Comment on attachment 71747 [details] [diff] [review]
patch to fix the weird integral

r=roc+moz

Comment 14

[Robert O'Callahan (:roc) (email my personal email if necessary)]

Awesome demo page, BTW!

Comment 15

[Dawn Endico]

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.

Comment 16

[rbs]

Attachment: example of prompt in ie

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"

Comment 17

[Dawn Endico]

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.

Comment 18

[rbs]

...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.

Comment 19

[Dawn Endico]

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.

Comment 20

[rbs]

Attachment: updated patch (improved wording & non-modal behavior)

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.

Comment 21

[rbs]

Attachment: screenshot - resulting mozilla prompt

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 22

[rbs]

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

carrying r=roc+moz forward

Comment 23

[Marc Attinasi]

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

sr=attinasi

Comment 24

[Mike Shaver (:shaver emeritus)]

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

Can we lose the huge #if 0 block?

Comment 25

[Dawn Endico]

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 26

[Mike Shaver (:shaver emeritus)]

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.

Comment 27

[rbs]

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).

Comment 28

[rbs]

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

Comment 29

[Jerome Lacoste]

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.

Comment 30

[rbs]

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.

Comment 31

[rbs]

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