Re: Mozilla mathml project to be interred

FW,

I appreciate comment about formula inside graphic, as with asciimathml
I am still surprised by some of the responses (one artifact is in fact
explored in the edtech pages I cited ;=}  There are few "perfect"
solutions, but if I can get a student to use asciimathml syntax to
express equations so that they are rendered in mathml without needing
a server or expensive client side software like Scientific Notebook,
isn't that worthwhile ;=}

The Moodle Guy (I am going to assume you are talking about Mauno as
opposed to me, though we are both active on Moodle.org)  and I may
well agree with you on quite a few points that you make, but if we
want mathematics notation to be transparent and universal, we can't
always expect that the user has a server side tex installation to rely
on..... and what guarantee that every web 2.0 app will employ the same
server side technology?  So,  while I don't want to see Firefox become
a huge juggernaut, I would love to see firefox be able to
transparently parse tags from any of a half a dozen different text
syntax into MathML for display.....  which argues client, not server
side,  parsing and display....

In other words, there are if you will, two stages involved in display
of Math as few will ever write math in MathML; text expression to
MathML, then MathML to display. We need to address both stages.  I
think we also need to be inclusive of those using non-Tex syntax.  We
woud perhaps need new firefox extensions for libs needed and a tag for
stage one math to differentiate it from current mathml tag,  or
perhaps extensions to Mathml to address this??  Now,  someone could
for example do <mathtext>$\root{n}{x}$<\mathtext> and feel confident
that a) the token used "$" will be recognized as a Tex token and b)
based upon the use of a Tex token in that span the span will be
displayed as MathML using a tex2Mathml routine.

Vis-a-vis asciimathml on wikipedia,  as I demonstrated on edtech,
asciimathml can be implemented on mediawiki via theme (i.e. without
extension) and this can be replicated on other wikis (even dokuwiki
with some mods that have been documented) which offers some intriguing
options, and as Mauno has been demonstrating over the past week, the
Google Chart API can be used for fallback.

I think we need to not only have our eye on the pie in the sky,  but
we need to agree on some baby steps in that direction....  and we need
to make all this accessible for the teacher facing 150 tweens every
day.

Marc

p.s. And thanks for the work you have been doing    ;=}

On Oct 5, 12:58 pm, Frédéric Wang <[email protected]> wrote:
>         I'm not really a fan of the use of scripts to convert row text into
> MathML. This assumes that any program reading the formula has
> javascript/DOM capability and can build the MathML DOM tree. But for
> example, this may not be the case for other non-browser rendering
> engines or for search engines [1]. In general techniques that do not
> give access to MathML source (such that the construction of SVG formulae
> proposed by the moodle guy) should be avoided, in my opinion: they
> prevent all of what MathML is intended for (apart from giving a good
> rendering). I think the right thing to do is to make the conversion
> *before* serving the page, such as in [2] or as Blahtex does. Of course,
> I would really be happy if Wikipedia uses ASCIIMathML to replace png
> images. However it seems the main difficulty here is to make core
> developers of MediaWiki integrate a new extension.
>
>         About mixing formulas & graphics, the W3C has not specified entirely
> how this should be done, even if MathML & SVG specs and note [3] give
> some hints. The inclusion of a formula inside a graphics should be
> reflected by the DOM structure: the MathML tree should be a subtree of
> the SVG one. Hence the use of a <foreignObject/> to put MathML inside
> SVG (again, see [2]) is better than using overlapped CSS <div/>'s. For
> instance, it is expected than a copy&paste of the <svg/> also acts on
> the formula and this is straightforward when <foreignObject/> is used.
> Another example, for people who have Amaya or a SMIL-enabled build of
> Mozilla: a formula *really* included inside SVG can be transformed
> and/or animated [4].
>
>         Back to the chicken or the egg dilemma, I think that implementers
> should take the first step and propose as much features of the Spec as
> possible. People do want to use formulas on the Web and if the current
> implementations are not sufficient, they are unfortunately going to use
> workarounds such that png/svg images or javascript-generated MathML DOM
> + CSS. Thanks to the switch to Cairo and Karl's work, MathML-in-SVG is
> now possible in Mozilla. Allowing MathML/SVG in HTML is another step
> forward, since it seems that the current requirement that a document
> must be served as XML is one of the main limitation for users. Finally,
> another improvement in Mozilla that has not been previously given:
> Thunderbird is now built with MathML support [5].
>
> [1]http://search.mathweb.org/index.xhtml
> [2]http://golem.ph.utexas.edu/instiki/show/Sandbox
> [3]http://www.w3.org/Math/Documents/Notes/graphics.xml
> [4]http://www.maths-informatique-jeux.com/international/mathml_with_othe...
> [5]https://bugzilla.mozilla.org/show_bug.cgi?id=456014