Weekly edition Kernel Security Distributions Contact Us Search Archives Calendar Subscribe Write for LWN LWN.net FAQ Sponsors

# MathML, Firefox, and Firemath

April 27, 2011

The World Wide Web Consortium (W3C) blessed version 3.0 of the MathML standard as an official "recommendation" in October of 2010. There are no major surprises in the revision, but software support has only started to catch up in recent months. Firefox 4 is the first browser to support MathML 3.0 directly, and new releases of the Firemath equation editor and STIX fonts enable in-browser editing and rendering, respectively. Widespread use of MathML may continue to elude scientists and educators in the near term, however, due to lackadaisical support in the other major browsers.

#### Let there be math

MathML is an XML-based specification for serving and rendering mathematical notation on the web. There are two ways to mark up mathematics in MathML, known as "presentation" MathML and "content" MathML. Presentation MathML focuses on making expressions human-readable, for use in web pages intended only to be read and understood. As a result, its fundamentals offer considerable control over the layout of the math, but do not try to capture its semantic meaning. Content MathML is designed to encode the semantic mathematical meaning of every expression, so it could be parsed and correctly understood by a computer algebra system.

For example, it is sufficient in presentation MathML to write x2 as:

    <msup> <mi>x</mi> <mn>2</mn></msup>


which simply renders the 2 as a superscript. But content MathML must encode the meaning of that relationship, and thus uses a different set of entities entirely:

    <apply> <power/><ci>x</ci> <cn>2</cn> </apply>


Both markup systems delimit individual "tokens" including literal numbers, variables, and operators, plus separator characters such as parentheses, braces, fraction lines, and matrix brackets. In most cases, whether the notation or the functional structure is most important dictates which system the author should use, but they can be mixed together so long as sufficient care is taken.

Given that web-based computer algebra systems are scarce, presentation MathML is where most of the effort is focused. MathML's major historical competitor is TeX formatting, which predates MathML considerably. There are numerous conversion scripts to render TeX and LaTeX expressions into inline images, which was generally regarded as the "safe" option for self-publishing as well as for content management systems. In recent years, however, conversion scripts for transforming TeX notation into MathML are making a strong showing.

MathML 3.0 does not introduce major changes to MathML syntax, although there are new elements in presentation MathML to support elementary-level math notation, such as vertical addition, multiplication, and long division. The mstack element is used to align such stacked rows of digits and operators; the related msline and mscarries elements support horizontal lines between rows and special borrow/carry rows. The mlongdiv element is used to mark up a long division, with quotient, denominator, and properly-aligned intermediate calculation steps. Because long division notation varies considerably between regions, the element supports a longdivstyle attribute with ten variations.

Most of MathML 3.0's changes address outstanding roadblocks to its adoption in the field. For starters, MathML 3.0 is officially part of HTML5, which means it can be delivered inline in HTML documents. MathML 2 required that the document be XHTML, delivered by the web server as application/xhtml+html, and linked to the W3C's MathML DTD. Until more HTML5 browsers support MathML, the old DTD as well as a new Relax NG schema are still available, and MathML MIME types have been registered, which is expected to push forward adoption in office applications and other non-browser environments.

The specification's definitions of content MathML elements have also been reorganized to better explain their alignment with the OpenMath semantic algebra system — an alignment that was part of previous revisions of MathML, but poorly documented. Finally, 3.0 explicitly supports mixing MathML with bi-directional text, closing a longstanding bug with the right-to-left text layout used in Arabic and Hebrew.

#### Browser support

The Gecko 2.0 rendering engine at the heart of Firefox 4 supports the majority of presentation MathML 3.0, including tokens and general layout elements, and most (but not all) modifying attributes. Still unimplemented are the new elementary math layout elements, line-breaking attributes, and the ability to embed hyperlinks within MathML expressions. Mozilla maintains a status page where users can follow the progress of individual elements.

A more practical resource for those needing MathML support today is the demos page, which links to pages showcasing support for individual elements, plus tests of Firefox's CSS support for MathML. By default, Gecko renders different MathML tokens according to different rules. Single letters (which often appear as variables) are rendered in italics, while multi-character strings (which often represent functions, such as sin() or tan()) are rendered in non-italic style. But MathML allows the page author to style the typography of any element, which is useful for highlighting one term or part of an equation, but also provides fine control where necessary, such as to differentiate between n and n.

MathML itself supports writing non-alphanumeric symbols via HTML character codes, but to take advantage of them, the browser needs fonts that supply Unicode's mathematical operators and symbols. Mozilla's demos are written to support the limited character coverage of the Symbol font, but the project's recommended solution is to install the STIX font set, which provides a much larger set of symbols, and in multiple styles. Internally, Firefox uses the font.mathfont-family configuration variable to choose the font used to display MathML, which uses a "fallback" list of math-supporting fonts to select the most appropriate option, so neither the page author nor the user needs to manually set a font preference.

STIX also supports "stretchy" elements, such as integrals, radicals, vertical bars, various braces, and arrows that are expected to expand to whatever size is needed to delimit the accompanying expression. In late 2010, however, a regression crept in to Firefox's STIX support that broke stretchy separators. The fix required both a patch to Firefox (which made it in to the 4.0 release) as well as an update to the STIX fonts. The STIX fonts are available under the SIL Open Font License, but as of 2011 are provided only in OpenType format. Type 1 (for PostScript) and TrueType versions are on the roadmap for future releases.

#### Equation editing

Rendering support is excellent in Firefox, but MathML's syntax is still verbose enough that writing it by hand is infeasible for all but the simplest expressions. In addition to the weight added by marking up individual tokens, operators, and layout elements, MathML uses invisible elements such as mrow, mfenced, msub/msup/msubsup, and mover/munder/moverunder to carefully align the elements in every expression vertically and horizontally.

Fortunately, the Firemath extension provides a WYSIWYG MathML expression editor as a Firefox add-on. The latest edition, version 0.4.0.2, was released in March, with support for Firefox 3 and 4. Once installed, Firemath can be launched from the Tools menu. The editor runs inside a tab or browser window; the basic usage scenario consists of creating an equation or expression in the Firemath tab, copying it to the clipboard, then pasting the result as MathML into a page or external editor.

As one might anticipate, the editor itself reserves a large swatch of space for a table of math operator and element buttons — enough are provided that the main library panel breaks them into six tabs. But the most common expressions and functions are separated out into a separate toolbar at the top-left. The editor component itself consists of three panes: the active WYSIWYG editor itself, a "live" render pane showing the contents of the editor, and a source view, which shows the underlying code.

The WYSIWYG editor displays a rendering of the current expression, too, but it places small pink dots at available entry points in the MathML. Some of the toolbar buttons insert operators or elements into the expression at these entry points, while others (such as sub- or super-scripts) require you to select an existing element first. Thus, writing an expression can be tricky if you are a Firemath newbie. The interface does its best to distinguish between these different classes of button by separating them with empty space, but it still takes some getting used to.

Editing an existing expression is also on the tricky side, as the keyboard arrow keys permit movement but not selection, and selecting the right element with the mouse can be difficult (particularly with stacked and nested elements). There is also a toolbar delete key, but it is not mapped to the keyboard delete, which seems like an oversight. In my own experiments, I found it frustrating that the normal copy-paste-cut and undo/redo functions are not supported in the editor, and that several of the toolbar buttons used bitmaps rather than text labels — bitmaps obviously designed for a light-colored background and unreadable in my dark GTK theme.

Still, one must expect to learn one's way around a new tool, and to that end the Firemath online documentation and examples proved helpful, but sparse. It is clear some of the editing conventions supported grew out of necessity, such as holding down the Control key while inserting "fence" elements such as braces. Using modifier keys to place objects on the screen is a common choice in graphics editors; it is simply uncommon for a text editor. On the other hand, a more complete glossary of the supported functions and operators would be helpful — not everyone will have the entire mathematical symbol Unicode block memorized — and it would be helpful for those less skilled in MathML to show the cursor position in the source code view as well as in the WYSIWYG editor. It is easy to misjudge a few pixels of vertical spacing on the pink dot, but much harder to misjudge the location of the actual HTML tags.

In addition to the basic elements, you can click the toolbar's "attribute" button to bring up a separate editor where you can change MathML attributes, including font script, size, foreground and background color, and even add user-defined CSS classes. This is also the only way to make horizontal spacing adjustments, through changing the attributes of the mspace element.

When your work is perfected in the editor, Firemath can copy it to the clipboard as MathML or as an image (in PNG or JPEG format), or save it with the same output options. The MathML output can be exported as fully marked-up HTML5, XHTML, an inline equation, or a block-level math element.

Firemath only produces presentation MathML, and at present has not added support for MathML 3.0's new elements. Its output, however, is valid in HTML5 documents for the syntax unchanged since MathML 2. You can also manually add newer attributes through the attribute editor, if desired, and Firemath will preserve them.

In just a few minutes of working with Firemath, the distinction between presentation and content MathML becomes crystal clear (if it wasn't already) — you can use the editor to craft any mathematical-looking expression your heart desires, even if it is semantic nonsense (such as this example). Forcing you into writing semantically correct math is not the job of a display technology like MathML; rendering it correctly with respect to size, position, and alignment is. Firemath makes it easy to write expressions the way you want them to look, which is all that an editor is responsible for doing.

#### Infinity and beyond

As Mozilla points out in its MathML documentation, one of the most exciting aspects of Firefox 4's MathML support is that mathematical expressions are now simply another part of the page. That opens the door to off-the-wall uses of MathML beyond generic in-line equations. The MathML demos show how to manipulate MathML with JavaScript, CSS, and the DOM, including tooltips, resizing expressions on mouse clicks, and head-scratchers like using images and form fields inside of equations.

For now, though, all of this fun remains essentially Firefox-only. Despite more than a decade of W3C Recommendation status, Firefox remains the only major browser to support rendering MathML in any meaningful sense. Opera can emulate some MathML with JavaScript and CSS add-ons, and a plug-in was available for earlier versions of IE — but it has not been maintained for IE 9. WebKit, interestingly enough, has MathML support in its renderer, but none of the WebKit-based browsers (including Chrome and Safari) enable it.

In the sciences, expecting visitors to use Firefox in order to see your published content is probably not a difficult hurdle, but online courseware packages like Moodle target a wider range of users, including school computer labs that may have locked-down environments. Moodle currently uses TeX to format equations in its content editor (rendering them to inline images), but as indicated on the wiki and elsewhere, there is growing interest in supporting MathML, either directly or via TeX-to-MathML converters. For other content management systems, the W3C maintains a list of known MathML plugins, including some for general-purpose CMSes like Wordpress, but the timestamps on many of the entries are getting dangerously old.

Despite those challenges, the MathML community is optimistic. David Carlisle from the MathML Working Group wrote in a blog posting in October that the adoption of the standard into HTML5 will constitute a "massive boost to getting Mathematics into web-based systems." It is said that the browser vendors' commitment to HTML5 will surely bring more support to MathML, which may be true, but so far Safari, Chrome, and IE have yet to make a public statement to that effect. Which means that at the moment, you have exactly one alternative for robust MathML rendering.

MathML, Firefox, and Firemath

Posted Apr 28, 2011 1:41 UTC (Thu) by elanthis (guest, #6227) [Link]

You know, honestly, the only thing I really care about with any of this is searchability.

I want to be able to have an _easy to type_ mathematical language that I type into Google and it'll be able to find similar equations.

Largely this happens when I'm combing though some graphics/physics code, there's a big algorithm that was poorly documented, and I have no idea what it's trying to achieve. Usually it's some well-known algorithm in the graphics/physics domain, so I just need a way to search it and see what it's all about.

MathML, Firefox, and Firemath

Posted Apr 28, 2011 20:27 UTC (Thu) by bronson (subscriber, #4806) [Link]

Sounds like you want a math regex to match parts of equations. That would be seriously sweet.

Given how glacially mathml and friends are moving though I can't imagine we'll see something like that any time soon. Maybe microformats could be applied to maths expressions and then search using semantic web tools?

It'll take a visionary.

MathML, Firefox, and Firemath

Posted May 11, 2011 12:29 UTC (Wed) by nix (subscriber, #2304) [Link]

TBH regexes applied to TeX seem more likely to bear fruit. It's not like people who write equations professionally would like to use MathML instead of TeX.

MathML, Firefox, and Firemath

Posted Apr 28, 2011 4:29 UTC (Thu) by mrons (subscriber, #1751) [Link]

Another approach, not mentioned in the article, is MathJax. It's a "javascript display engine" that is supposed to work in all modern browsers.

MathML, Firefox, and Firemath

Posted Apr 28, 2011 11:50 UTC (Thu) by jschrod (subscriber, #1646) [Link]

I wouldn't call TeX and MathML competitors, but neighbours, to be used for different tasks, sporting knowledge exchange and collaboration.

After all, David Carlisle, named in the article, is not only a MathML working group member, but also a LaTeX core group member.

MathML, Firefox, and Firemath

Posted Apr 28, 2011 20:01 UTC (Thu) by n8willis (editor, #43041) [Link]

They "compete" for author attention & web support within CMSes, which is what the statement in the article discusses; that situation does not, however, suggest or imply that they have the same goals or that there is animosity between the two camps. One could easily learn both, and a web publishing system could easily support input in both. They are simply formats, after all.

Nate

MathML: horrible

Posted Apr 28, 2011 14:17 UTC (Thu) by danielpf (subscriber, #4723) [Link]

What an terrible syntax and that for a rather poor result. The comparison table betwenn TeX and MathML shows how far MathML is from TeX (for expert eyes the MathML rendering is awful almost like à la Word). Obviously MathML is not close to improve on the work of Donald Knuth.

The given example

<msup> <mi>x</mi> <mn>2</mn></msup>

is expressed in TeX (switching from text mode) as

$x^2$

which is identical (except for the \$'s) to the convention of most computer algebra languages (Maxima, Maple, etc.) which don't need a special notation to know about the functional meaning (even bulkier in the given example).

I get the impression that once more some people need to reinvent the wheel, and dismiss the past experience, resulting afters years of work in a big failure IMHO.

MathML: horrible

Posted Apr 28, 2011 17:40 UTC (Thu) by cladisch (✭ supporter ✭, #50193) [Link]

One of the primary goals of XML is to make its processing by computers easier; XML is not intended to be written by humans.

MathML rendering quality depends on the implementation. There are MathML-to-TeX convertes, and it would be possible to use TeX's formatting rules in Firefox.

MathML: horrible

Posted Apr 28, 2011 20:09 UTC (Thu) by n8willis (editor, #43041) [Link]

How is the syntax "terrible" precisely? Solely because it is not as compact? In any event, one thing I did not touch on in the main story is that presentation MathML is designed to express *notation*. The x2 example might be the equivalent of x*x, as a computer algebra system would interpret x^2, but it might also mean the second element in a tensor named x in Einstein notation, the charge of a particle, or any number of other things. By being neutral on that, MathML is as a result more flexible.

Nate

MathML: horrible

Posted Apr 28, 2011 21:05 UTC (Thu) by viro (subscriber, #7872) [Link]

The same is true for TeX; as the matter of fact, $$\Gamma^i_{jk} = \frac{1}{2}g^{im}(g_{mk,l} + g_{ml,k} - g_{kl,m})$$ is how you normally spell the formula for Christoffel symbols. I hate to think what that would turn into in your notation... caret-something is just "make something an upper index", no more and no less. No semantics attached; it's up to the reader of the resulting text how to interpret the damn thing.

The thing is, TeX is just a notation as well - one designed by a guy who took care to check how that kind of stuff was expressed in real world, i.e. by typesetters dealing with math texts. As for the flexibility - meh... S-expressions are just as flexible and require as little parsing as that piece of bloat. But then *ML is The Wave Of Future(tm) and S-exp is not, so who cares that if it's vomit-inducing...

MathML: horrible

Posted Apr 28, 2011 23:40 UTC (Thu) by n8willis (editor, #43041) [Link]

I'm confused by what you mean when you refer to "my notation" -- ostensibly that should mean MathML (which, for the record, I did not create in the slightest), but then you go on to take a swipe at the caret, which is not MathML at all.

In the first paragraph, you seem to be saying that TeX, like MathML, is semantics-free, which is true. Presentation MathML and TeX notation are equivalent there. Don't forget, though, that MathML also encompasses Content MathML, which as is explained in the 3.0 docs, is aligned with OpenMath, which *is* a semantic encoding. In *all* non-semantic encodings, it is always left up to the reader to "interpret the damn thing" (and there is nothing you as an author can do to prevent someone, somewhere, from misunderstanding you). The same is true with words, is it not?

But I'm also confused by what you're trying to say in the second paragraph, where you appear to being knocking MathML again, this time on the grounds that it is not connected to the "real world" (meaning, apparently, solely printed books and journal articles?). It is clear, is it not, that MathML is a _web_ publishing technology? The syntax is inherited from HTML, and you're certainly free to love or hate HTML, but its regularity is what makes things like the linking and CSS styling mentioned earlier possible.

I'd suggest you take a look at Mozilla's MathML "demo" pages for a more detailed discussion on how MathML's alignment with HTML and the DOM make it a superior fit for publishing mathematics _on_the_web_. There are more examples there than I had room to discuss. No matter how much you love TeX, you can't enable tooltip-style hover annotations in a printed & bound manual -- even if it was typeset with TeX. I'm not sure you could embed a link in the middle of a TeX-formatted equation in any CMS currently supporting the format, but I wouldn't want to be the first one to try it.

Finally, like most of us I have endless respect for Donald Knuth, but let's not let that cause us to fall into the trap of pretending that TeX's mathematical typesetting is free of errors or the need for manual adjustment when expressing a complex equation or notation. In particular, when it is left to automatic, TeX often chooses less-than-ideal sizes for tokens in multi-level stacks or continued fractions, and as Mozilla documents on the <mo> tracking page (here: http://www.mozilla.org/projects/mathml/demo/mo.xhtml), TeX is only capable of producing symmetric fences.

Nate

MathML: horrible

Posted Apr 29, 2011 0:01 UTC (Fri) by Comet (subscriber, #11646) [Link]

Shortly after I gave up on the idea of using MathML for a small project, simply because the MathML2 docs drove me to drink, someone on a mailing-list started a rant about XML schema abuse, to which my response was:

<paragraph><sentence><word pos="pronoun">You</word><word pos="verb"
subpos="auxilliary">should</word><word pos="verb">be</word><word
<word pos="pronoun">this</word><word pos="verb">is</word><word
<punctuation>.</punctuation></sentence></paragraph>

*That* is what is wrong with MathML -- this contrived example of abusive English markup is what MathML does to molest any poor innocent equation it encounters.

XML: horrible

Posted May 3, 2011 16:36 UTC (Tue) by i3839 (guest, #31386) [Link]

No, that is what is wrong with *all* XML based crap.

MathML: horrible

Posted May 4, 2011 15:02 UTC (Wed) by bronson (subscriber, #4806) [Link]

Bravo! Very well said. It seems like the people driving MathML don't actually like math very much but they adore XML.

MathML: horrible

Posted May 5, 2011 15:16 UTC (Thu) by PaulTopping (guest, #74605) [Link]

You guys are the crazy ones. MathML and all things XML are computer representations. That means that computer programs are the ones that are supposed to read and write them, not humans.

MathML: horrible

Posted May 5, 2011 15:20 UTC (Thu) by mjg59 (subscriber, #23239) [Link]

Then why isn't it a binary representation?

MathML: horrible

Posted May 6, 2011 7:15 UTC (Fri) by cladisch (✭ supporter ✭, #50193) [Link]

One of the goals of XML is to be compatible with SGML, which was designed to be written by humans. (Not very successfully.)

MathML: horrible

Posted May 6, 2011 13:03 UTC (Fri) by mjg59 (subscriber, #23239) [Link]

In fact, http://www.w3.org/TR/xml11/#sec-intro clearly states that XML is intended to be human legible.

MathML: horrible

Posted May 6, 2011 16:08 UTC (Fri) by bronson (subscriber, #4806) [Link]

Crazy? Look around, Paul. Most XML is edited by hand: xhtml, spring configs, ant files, pom files (editors exist but are horrid), docbook, etc etc etc.

This is true of mathml too, where the few automated editors that I can try are even more painful to use than hand-editing, presentation-only, and often get it wrong.

MathML: horrible

Posted May 11, 2011 10:00 UTC (Wed) by oldtomas (guest, #72579) [Link]

This is one of the worst things about the XMLs. If someone says "unreadable!" (and (s)he is right!) the apologists answer: "it's meant to be machine-readable, not human readable". If someone says "redundant!" (WTF do you have to repeat the whole tag name on close? Why are there *two* quote characters for attribute values? Why the F don't you have a plain straight regular escape syntax in attribute values, but have to mis-use entity syntax for that (entities are meant for completely different things, remember!), creating the mess with "internal" vs. "external" entities? On and on!) -- then the apologists retort: "it's to catch (human) input errors!".

I have another theory: XML is a denial-of-service attack on all of us.

OK, to be more precise: XML is passable as a (traditional) document representation language (family). As a data representation language it's plain perverse.

And yes, the line between document and data is somewhat broad, but for maths (and music, and vectr graphics), I'd say we're clear off this line... firmly on the "data" side.

MathML: horrible

Posted May 12, 2011 18:59 UTC (Thu) by PaulTopping (guest, #74605) [Link]

XML is plain text so that it can be easily interchanged between computers, applications, etc. It is true that some people have created mini XML-based languages that they expect people to type. This works ok for them because their language and what it describes consists of a few named options with values. As you point out here, even for this application XML is not a great language. For something like math notation, the things it represents are complicated and its XML representation is complicated as a result. In short, if the thing being described is simple, typing XML is ok but not great. If the thing being described is complex, like math, typing it is ridiculous. Most uses of XML are of the latter kind and are completely behind the scenes.

MathML: horrible

Posted Apr 29, 2011 3:14 UTC (Fri) by PaulTopping (guest, #74605) [Link]

In comparing TeX to MathML it is easy to make a category error. TeX is a human input language. In other words, it was designed to be typed by humans. MathML is a computer representation and was intended as an internal representation and not something for mere mortals to type. Just as RTF (Rich Text Format) is text and can be typed, it is not intended to be typed. RTF and all XML languages, even HTML, are not really designed to be input languages. That is not their forte.

MathML: horrible

Posted May 4, 2011 15:56 UTC (Wed) by danielpf (subscriber, #4723) [Link]

I don't buy that. If MathML was intended to be read only by computers then a proper design would care about efficiency and MathML would be coded in some kind of portable binary format, like Java code. If MathML was designed to be read by some humans, then it is absurd to invent a hard to read notation just to simplify the MathML parser and interpreter.

MathML: horrible

Posted May 12, 2011 20:05 UTC (Thu) by PaulTopping (guest, #74605) [Link]

You should read some of the more general introductions to XML. Wikipedia might be a good start. These days with fast computers and connections, but expensive software development, we choose to represent data in XML so that common software tools can be used to operate on them. XML is a text format for ease of interchange and ease of development.

For those that want speed, you can zip XML and they get really compact. This is what Microsoft's .docx format does. The W3C is also working on a compression scheme that is specific to XML that will probably do even better than zip compression. What is cool about it is that all XML-based file formats will take advantage of it. All XML tools will be updated to deal with the compression/decompression and will work on all those formats.

MathML, Firefox, and Firemath

Posted Apr 30, 2011 0:40 UTC (Sat) by fsateler (subscriber, #65497) [Link]

<apply> <power/><ci>x</ci> <cn>2</cn> </apply>

This is possibly the worst possible (ab)use of XML I've seen (or looks like it, please somebody explain if I'm wrong), based on 2 facts observable in that snippet:

1. <apply> tag. Is there a reason I would want to not apply an operation? Why don't operation keywords just nest into their operands?
2.Order-dependent parsing.

MathML, Firefox, and Firemath

Posted May 3, 2011 22:50 UTC (Tue) by Tobu (subscriber, #24111) [Link]

Content MathML looks like typed lambda calculus. Presentation MathML is much more concise for this expression, and can be mapped to Content MathML and back again, but Presentation MathML can only prettify a limited set of already defined operators. On the other hand Content MathML can define new operators and use the already defined operators as functional values, for example defining Knuth's double arrow operator using <power/> and some <recursion/> combinator (both are normal values for lambda calculus).

MathML, Firefox, and Firemath

Posted May 6, 2011 6:48 UTC (Fri) by augustm (guest, #41831) [Link]

This reminds me of the posting by a member of the MathML committee
in the time of Netscape. A latex user was asking how to convert a paper
in order to create a nice web document. The answer was

1) Latex is the problem, not part of the solution

2) Mathematica is built with a WYSIWYG editor, and is the future-
because the mathml expressions are too complicated to type by hand.

As a scientist who has written books in latex- this sounds like
telling Linus to use VisualBasic to write the kernel- it is so
much more productive and high level.... how can you not prefer it?

How is mathml, 10 years later helping a scientist produce a substantial
text? A book, a 50 page handout for students?

How can one integrate the millions of documents available at http://arxiv.org/

MathML, Firefox, and Firemath

Posted May 12, 2011 16:12 UTC (Thu) by davidcarlisle (guest, #74878) [Link]

> How is mathml, 10 years later helping a scientist produce a substantial
> text? A book, a 50 page handout for students?

It's probably not helping a lot in the production (unless it's a collaborative work with some people using tex, some MS Word, some openoffice, some... and you need a common communication format).

So let's assume for the sake of argument that the book is written in LaTeX.

In 1985 the author would have been happy to get that LaTeX typeset on to paper and the book published, but these days many people still want that, but also want online versions, version that meet legal or moral requirements for accessible renderings to audio or braille, versions that dynamically reflow in a web browser...

MathML has a lot of element markup but that is needed in a browser environment as that's how you address things via css, and makes it much easier to address things in javascript etc.

Conversion to mathml either offline with things like tex4ht or latexml or for more constrained input within the browser with asciimathml or mathjax is eminently possible and doesn't require you to throw away the latex skills.

> How can one integrate the millions of documents available at http://arxiv.org/
there are existing projects underway to convert sections of that to mathml
using latexml as having xhtml (or html5) versions of documents have many advantages when offered as an addition rather than a replacement for the exactly faithful but statically typeset TeX renderings to pdf.