Mozilla mathml project to be interred

Thought this bit of news as posted on moodle.org where some folk aretrying to promote use of mathml via asciimathml and other options wasworth sharing:

"I spoke personally with Chris Hoffman of Mozilla Foundation aboutMathML and he told me that the project leader bailed out for someother project a while ago. This means the project is basicallystalled. The project page was last modified September, 2006, and mostlinks on that page are broken."

There's been a good bit of work on MathML since then to keep itworking after the switch to cairo and the reflow branch landing(mostly by Karl Tomlinson, I think). I think this means yourmessage's subject is an overstatement.

However, I don't think there's been much, if any, new feature workon MathML, although I might be missing something.

On Thu, Aug 20, 2009 at 7:33 AM, L. David Baron<dba...@dbaron.org> wrote:> On Wednesday 2009-08-19 19:39 -0700, net-buoy wrote:>> Thought this bit of news as posted on moodle.org where some folk are>> trying to promote use of mathml via asciimathml and other options was>> worth sharing:>>>> "I spoke personally with Chris Hoffman of Mozilla Foundation about>> MathML and he told me that the project leader bailed out for some>> other project a while ago. This means the project is basically>> stalled. The project page was last modified September, 2006, and most>> links on that page are broken.">> There's been a good bit of work on MathML since then to keep it> working after the switch to cairo and the reflow branch landing> (mostly by Karl Tomlinson, I think). I think this means your> message's subject is an overstatement.>> However, I don't think there's been much, if any, new feature work> on MathML, although I might be missing something.

That's unfortunate. There is plenty work that could and should be donewith the MathML support in Firefox--including accessibility work.

I thought Mozilla was looking to revive the project and apply a bitof resources to MathML enhancements.

-- --Alex Milowski"The excellence of grammar as a guide is proportional to the paucity of theinflexions, i.e. to the degree of analysis effected by the languageconsidered."

> On Thu, Aug 20, 2009 at 7:33 AM, L. David Baron<dba...@dbaron.org> wrote:>> On Wednesday 2009-08-19 19:39 -0700, net-buoy wrote:>>> Thought this bit of news as posted on moodle.org where some folk are>>> trying to promote use of mathml via asciimathml and other options was>>> worth sharing:>>>>>> "I spoke personally with Chris Hoffman of Mozilla Foundation about>>> MathML and he told me that the project leader bailed out for some>>> other project a while ago. This means the project is basically>>> stalled. The project page was last modified September, 2006, and most>>> links on that page are broken."

Walter's comment kind of needs to be read with the knowledge thathe is advocating an alternative technology.

But, as Walter indicates in another comment, even though thevolunteers that have done a lot of work on MathML in Mozilla inthe past have not been active recently, that does not mean thatMozilla is not interested.

>> There's been a good bit of work on MathML since then to keep it>> working after the switch to cairo and the reflow branch landing>> (mostly by Karl Tomlinson, I think). I think this means your>> message's subject is an overstatement.>>>> However, I don't think there's been much, if any, new feature work>> on MathML, although I might be missing something.>> That's unfortunate. There is plenty work that could and should be done> with the MathML support in Firefox--including accessibility work.

> I thought Mozilla was looking to revive the project and apply a bit> of resources to MathML enhancements.

It takes resources just to keep MathML in Gecko while changes aremade to Gecko's infrastructure and to ensure that supportingMathML doesn't compromise the safety of using a browser.Mozilla has been applying resources here.

I am not arguing the position prsentred (I have been watching the workon menclose because of long div issues and know how much work justthat piece took) but felt it was important for people to know what isbeing said, as sometimes perception is more important than reality....If nothing else, the project needs updating...

Yeah, we should update the pages to reflect reality. Maybe Karl can do that.

Mozilla staff are currently maintaining our MathML support (i.e., keeping it working as other things change around it) and willing to review and land contributions to improve it, but we aren't going to invest in any major improvements until MathML becomes a lot more popular on the Web. We already support a very large subset of MathML and there's just no point in extending that until people start using what we've already implemented.

Actually there is one major improvement for MathML coming as a side effect when we transition to the new HTML5-spec-based parser; you will be able to write MathML in non-XML HTML documents. That will make MathML far more usable on the Web.

On Sun, Aug 23, 2009 at 4:02 PM, Robert O'Callahan<rob...@ocallahan.org> wrote:>> Mozilla staff are currently maintaining our MathML support (i.e., keeping it> working as other things change around it) and willing to review and land> contributions to improve it, but we aren't going to invest in any major> improvements until MathML becomes a lot more popular on the Web. We already> support a very large subset of MathML and there's just no point in extending> that until people start using what we've already implemented.

That seems somewhat circular in that until there is a high qualityimplementationpeople won't use it. Using MathML is currently quite the "magic incantation"that also requires a user to install fonts. Most users won't do that.

> Actually there is one major improvement for MathML coming as a side effect> when we transition to the new HTML5-spec-based parser; you will be able to> write MathML in non-XML HTML documents. That will make MathML far more> usable on the Web.

Yes, that will certainly be a big help with the deployment of MathML byauthors.

-- --Alex Milowski"The excellence of grammar as a guide is proportional to the paucity of theinflexions, i.e. to the degree of analysis effected by the languageconsidered."

On 23/08/09 7:41 PM, Alex Milowski wrote:> On Sun, Aug 23, 2009 at 4:02 PM, Robert O'Callahan<rob...@ocallahan.org> wrote:>> Mozilla staff are currently maintaining our MathML support (i.e., keeping it>> working as other things change around it) and willing to review and land>> contributions to improve it, but we aren't going to invest in any major>> improvements until MathML becomes a lot more popular on the Web. We already>> support a very large subset of MathML and there's just no point in extending>> that until people start using what we've already implemented.>> That seems somewhat circular in that until there is a high quality> implementation> people won't use it. Using MathML is currently quite the "magic incantation"> that also requires a user to install fonts. Most users won't do that.

I thought that that problem is going away since Windows Vista and the latest version of Microsoft Office include Cambria Math, Linux distros will package STIX when that's released, and Mac already had adequate fonts. Is that not true?

I also believe that in Firefox 3.5 you could put a free math font on your server and use CSS @font-face to instruct the browser to download and use the font.

Alex Milowski <al...@milowski.com> writes:> On Sun, Aug 23, 2009 at 4:02 PM, Robert O'Callahan<rob...@ocallahan.org> wrote:>>>> Mozilla staff are currently maintaining our MathML support (i.e., keeping it>> working as other things change around it) and willing to review and land>> contributions to improve it, but we aren't going to invest in any major>> improvements until MathML becomes a lot more popular on the Web. We already>> support a very large subset of MathML and there's just no point in extending>> that until people start using what we've already implemented.>> That seems somewhat circular in that until there is a high quality> implementation> people won't use it.

It's not the quality of the Mozilla implementation, that stops publishers from using MathML. But you have to offer an other representation of math, for example images,for those people, who use other browser. Then, if the other representation works well im Mozilla too, why would you maintain two representations?

On Mon, Aug 24, 2009 at 1:41 AM, Martin Holz<usene...@martin-holz.net> wrote:> Alex Milowski <al...@milowski.com> writes:>> It's not the quality of the Mozilla implementation, that stops publishers from> using MathML. But you have to offer an other representation of math, for example> images,for those people, who use other browser. Then, if the other> representation works well im Mozilla too, why would you maintain two> representations?

It is great to have some kind of implementation of MathML and I am certainquite happy that Firefox contains some support for MathML. Unfortunately, thatsupport is incomplete and still requires addition fonts on most deployedplatforms. The coming STIX fonts will help alleviate the font problem butit is unclear how Mozilla will achieve uniformity given OS vendors releasecycle and commitment to including the STIX fonts. Most certainly, peoplewith older OS version (of which there are many) will not have them.

Having to use CSS and have the browser download a font isn't very friendlyto a publisher and most will attribute that to quality ofimplementation--howeverfair or unfair that is.

That's where I come back to active support by Mozilla of the "big three" ofMathML, SVG, and HTML. Just maintaining the code isn't sufficient.

-- --Alex Milowski"The excellence of grammar as a guide is proportional to the paucity of theinflexions, i.e. to the degree of analysis effected by the languageconsidered."

On Aug 24, 1:02 am, Robert O'Callahan <rob...@ocallahan.org> wrote:>> Mozilla staff are currently maintaining our MathML support (i.e.,> keeping it working as other things change around it) and willing to> review and land contributions to improve it, but we aren't going to> invest in any major improvements until MathML becomes a lot more popular> on the Web. We already support a very large subset of MathML and there's> just no point in extending that until people start using what we've> already implemented.

It would be nice if Mozilla would not only follow the mainstream (addvideo support etc.) but feel responsible of supporting science(minorities) as well. In the end many of the technologies used withinFirefox came out of science. So it would be only fair to give somedividend back.

> > It would be nice if Mozilla would not only follow the mainstream (add> video support etc.) but feel responsible of supporting science> (minorities) as well. In the end many of the technologies used within> Firefox came out of science. So it would be only fair to give some> dividend back.

I've just gave a try to your extension. It's certainly useful to quickly insert mathematical symbols and write simple presentation MathML. However It's not easy to generate a complex recursive structure (it often says "Operation not permitted on empty objects!"). I also feel difficult to move across the tree structure and select fragments of the formula. It lacks a parsing for simple expression such that "a+b=2" and copy&paste feature of MathML fragments. I hope one day I can hack mozilla/source/editor/ to add the editing features of Amaya (including the recent SVG editor BTW) so that XUL applications like yours (maybe Thunderbird?) can rely on a user-friendly interface...

On 11/09/09 1:05 AM, Firemath wrote:> It would be nice if Mozilla would not only follow the mainstream (add> video support etc.) but feel responsible of supporting science> (minorities) as well. In the end many of the technologies used within> Firefox came out of science. So it would be only fair to give some> dividend back.

Well, we have been supporting MathML for years longer than everyone else --- and that hasn't been free, belive me.

I know that, personally, I really appreciate that Mozilla has been supportingMathML as it exists in the code base. I think what you are seeing is thatmany of us want more out of the implementation and that just maintainingthe current state without some forward movement is something weall have opinions about.

With the current development of HTML5 going on, it would be reallygreat to see HTML5 progress in conjunction with SVG and MathML asa fully supported triad of markup we can rely upon in Firefox and otherMozilla derived products.

Maybe we should turn this discussion in a positive direction:

1. What feature(s) of MathML 2 do you need that is not implemented?

2. What's "broken" that you need fixed?

-- --Alex Milowski"The excellence of grammar as a guide is proportional to the paucity of theinflexions, i.e. to the degree of analysis effected by the languageconsidered."

Yes, Wikipedia has a potential for boosting the use of MathML with its tons of equations. It is supposed to have experimental functionality to use MathML for formulas: you have to login with a personal account, and in your settings for Math select the option "MathML where possible (experimental)". However, I don't see any effect: A few simple formulas get converted to plain HTML, and most of them to PNG.

I think, there are libraries for converting LaTeX (the internal math representation in Wikipedia) to MathML. They should implement it and get rid of the rasterised PNGs, at least for users of Firefox :-)

[OT] I remember I also suggested Wikipedia to embed SVG drawings as such (they currently convert them to PNG for display), for SVG-enabled browsers, but they were reluctant as they considered SVG to be insufficiently or differently implemented in the various browsers.

On 16/09/09 10:27 AM, Alvaro wrote:> Yes, Wikipedia has a potential for boosting the use of MathML with its> tons of equations. It is supposed to have experimental functionality to> use MathML for formulas: you have to login with a personal account, and> in your settings for Math select the option "MathML where possible> (experimental)". However, I don't see any effect: A few simple formulas> get converted to plain HTML, and most of them to PNG.>> I think, there are libraries for converting LaTeX (the internal math> representation in Wikipedia) to MathML. They should implement it and get> rid of the rasterised PNGs, at least for users of Firefox :-)>> [OT] I remember I also suggested Wikipedia to embed SVG drawings as such> (they currently convert them to PNG for display), for SVG-enabled> browsers, but they were reluctant as they considered SVG to be> insufficiently or differently implemented in the various browsers.

It would be great if someone found out what their specific issues are, and why their MathML option isn't working!

The original developer is David Harvey. Apparently, he stopped leading the project because the core developers of MediaWiki have never taken a moment to integrate it. It is now maintained by Gilles van Assche. See this discussion:

for demonstration purposes re moodle.org which uses mediwiki foronline docs I set up a mediawiki at EdTech.alaskapolicy.net to useasciimathml (took a minute) while others set up Tex for comparison.

While google chart API prsents some new options, it is high time thatgoogle allow mathml. I do not have google script access and wonder ifscript access can be used to invoke asciimathml.js

btw, my original posting was done rather tongue in cheek..... But itwould be nice if mathml in general took a giant step forward ;)

On Sep 19, 9:30 am, Frédéric Wang <fred.w...@free.fr> wrote:> > It would be great if someone found out what their specific issues are,> > and why their MathML option isn't working!>> > Rob>> There exists an extension for MediaWiki called BlahTex, and it seems> ready for a while.>> http://www.mediawiki.org/wiki/Extension:Blahtex> http://gva.noekeon.org/blahtexml>> The original developer is David Harvey. Apparently, he stopped leading> the project because the core developers of MediaWiki have never taken a> moment to integrate it. It is now maintained by Gilles van Assche. See> this discussion:>

>> From this discussion, a new bug was created to request integration of> Blahtex in future versions of MediaWiki:>> https://bugzilla.wikimedia.org/show_bug.cgi?id=6383>> This bug is three years old but the developers of MediaWiki still have> not answered. I have just voted for this bug, maybe gathering enough> votes will catch their attention.

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

I appreciate comment about formula inside graphic, as with asciimathmlI am still surprised by some of the responses (one artifact is in factexplored in the edtech pages I cited ;=} There are few "perfect"solutions, but if I can get a student to use asciimathml syntax toexpress equations so that they are rendered in mathml without needinga 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 asopposed to me, though we are both active on Moodle.org) and I maywell agree with you on quite a few points that you make, but if wewant mathematics notation to be transparent and universal, we can'talways expect that the user has a server side tex installation to relyon..... and what guarantee that every web 2.0 app will employ the sameserver side technology? So, while I don't want to see Firefox becomea huge juggernaut, I would love to see firefox be able totransparently parse tags from any of a half a dozen different textsyntax into MathML for display..... which argues client, not serverside, parsing and display....

In other words, there are if you will, two stages involved in displayof Math as few will ever write math in MathML; text expression toMathML, then MathML to display. We need to address both stages. Ithink we also need to be inclusive of those using non-Tex syntax. Wewoud perhaps need new firefox extensions for libs needed and a tag forstage one math to differentiate it from current mathml tag, orperhaps extensions to Mathml to address this?? Now, someone couldfor example do <mathtext>$\root{n}{x}$<\mathtext> and feel confidentthat 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 bedisplayed 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. withoutextension) and this can be replicated on other wikis (even dokuwikiwith some mods that have been documented) which offers some intriguingoptions, and as Mauno has been demonstrating over the past week, theGoogle Chart API can be used for fallback.

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

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

I humbly but strongly disagree. This is an example of how the 'net hasbeen going the wrong way: Instead of a few, clean specs we have aproliferation of competing technologies, many proprietary, that aresupported to various degrees by different platforms. Instead of theone-markup-fits-all dream behind the separation of content fromrendering, most Web pages are highly platform specific. ExpectingMozilla to support different math content formats would go down the sameroad, making things worse.

MathML is *the* format for marking up math. If it falls short, let'simprove it. May all browsers do their best to implement it.

How MathML is generated is none of Mozilla's business. There's a dozenways to do it. The choice is on the content creator's side, and this isa good thing.

Let's keep these two separate: The server does its best to produce cleanmarkup, and the client does its best to produce a clean rendering fromthis markup. The cleaner the set of markups to support by either side,the better for everyone.

Apologies, Justus, but I think you missed my point.I am not arguing for any dilution of mathml, just the opposite. I amarguing for additional tag standards, either as a superset to mathmlor to XHTML that would allow the tagging of text expression forparsers.Likewise I am not arguing that FF do it all, merely that the extensionarchitecture combined withsuch a tag provides the transparency anduniversality that is needed; ie parsers for text syntax can be addedand turned on and off.

Devils advocate wise, mathml is a w3c standard and we can see theimpact that has had on Microsoft and webkit.... Wolfram is not goingto abandon mathematicas syntax and the same applies tothosecomfortable with maxima or any other syntax..... The problem isthat the paradigm of web content provider vs consumer breaks down with"web 2.0" and will arguably disappear as web service takes overwebinteraction (web 3.0). If I amcomfortable using asciimathingooglegroups and you arecomfortable with maxima, why shouldn't webothbe able to use the syntax we arecomfortable with, having ourbrowsers adjust?

I think our real choice is between browser based or reliance on 3rdparty servers (such as WA, googlechartapi, or even mathtran ormimetex) and sitting offline reading a file via my browser whyshouldn't I expect what is imminently possible?

> Apologies, Justus, but I think you missed my point.> I am not arguing for any dilution of mathml, just the opposite. I am> arguing for additional tag standards, either as a superset to mathml> or to XHTML that would allow the tagging of text expression for> parsers.> Likewise I am not arguing that FF do it all, merely that the extension> architecture combined withsuch a tag provides the transparency and> universality that is needed; ie parsers for text syntax can be added> and turned on and off.

I agree with Justus here. Alternative input syntax for mathematics arebest thought of like wiki syntax for natural language text. Wikis becamepopular because they didn't require people to install special browsers,the conversion from the linear syntax to html/xml markup happens on theclient. Adding multiple math language parsers to a browser would be likeinstalling parsers for every flavour of wiki syntax.

> Devils advocate wise, mathml is a w3c standard and we can see the> impact that has had on Microsoft

Quite a lot on microsoft, although not currently in IE, Word has MathMLinput/output as standard and the new pen based math input in Windows 7is using mathml internally as well as on file export.

why should they? Mathematica has had MathML import/export since thefirst drafts of MathML.

> I think our real choice is between browser based or reliance on 3rd> party servers (such as WA, googlechartapi, or even mathtran or> mimetex) and sitting offline reading a file via my browser why> shouldn't I expect what is imminently possible?

A plugin to the browser (or javascript or whatever) that expands markup,whether it be asciimath to mathml, or wiki markup to html, is usefulagreed, but the strength of the web is in sharing common markuplanguages, not that everyone has to have a parser for every languagevariant.

David

________________________________________________________________________The Numerical Algorithms Group Ltd is a company registered in Englandand Wales with company number 1249803. The registered office is:Wilkinson House, Jordan Hill Road, Oxford OX2 8DR, United Kingdom.

This e-mail has been scanned for all viruses by Star. The service ispowered by MessageLabs. ________________________________________________________________________