## February 2, 2004

### MathML News

In the Sisyphean task of implementing the conversion of LaTeX symbols to MathML Named Entities, here’s another update to the itex2MML executable used by my plugin. Urs Schreiber discovered that variant Greek letters weren’t supported. Now they are…

\varepsilon
&varepsilon; ($\varepsilon$)
\varkappa
&varkappa; ($\varkappa$)
\varphi
&varphi; ($\varphi$)
\varpi
&varpi; ($\varpi$)
\varrho
&varrho; ($\varrho$)
\varsigma
&varsigma; ($\varsigma$)
\vartheta
&vartheta; ($\vartheta$)

As always, my distribution contains a MacOSX binary, as well as the source code to compile the new itex2MML. But, in a new wrinkle, Abiola Lapite and James Graham have made precompiled binaries for Windows and Linux.

In other MathML news, Design Science has MathPlayer 2.0 in beta. The exciting news is that this MathML plugin for IE/Win will finally support XHTML+MathML documents.

Modulo some finessing of MIME-type issues, we, here at Musings, may even be able to support Internet Explorer someday.

Update (2/3/2004): Whoops! Urs found a missing binary operator, \circ. Turns out there were a whole bunch of standard ones missing:

\circ
&SmallCircle; ($\circ$)
\bigcirc
&bigcirc; ($\bigcirc$)
\wr
&wr; ($\wr$)
\odot
&odot; ($\odot$)
\uplus
&uplus; ($\uplus$)
\diamond
&diamond; ($\diamond$)
\sqcup
&sqcup; ($\sqcup$)
\sqcap
&sqcap; ($\sqcap$)
\rhd
&RightTriangle; ($\rhd$)
\lhd
&LeftTriangle; ($\lhd$)
\unrhd
&RightTriangleEqual; ($\unrhd$)
\unlhd
&LeftTriangleEqual; ($\unlhd$)

A new copy of my distribution is up, along with new Windows and Linux binaries.

Update (2/7/2004): Some portability fixes from Bob McElrath. itex2MML should now compile correctly on Alpha and, presumably, other 64-bit processors. No new functionality with this update, so, if the previous one was working for you, there’s no need to download it again. But, if you were having trouble compiling the previous version, you might want to give the latest one a try. Ah, the beauty of Open Source …

Posted by distler at February 2, 2004 10:38 PM

TrackBack URL for this Entry:   http://golem.ph.utexas.edu/cgi-bin/MT-3.0/dxy-tb.fcgi/306

### Re: MathML News

The exciting news is that this MathML plugin for IE/Win will finally support XHTML+MathML documents.

I hate to sound negative, but reading the site, it sounds like this development is, at best, not a great improvement over the current situation. Admittedly I don’t really know what the current situation is with MathML in IE, so maybe I’m overreacting. Nevertheless, the implementation looks less than ideal.

The first problem is that IE still doesn’t handle XML documents without MathML. This means that, in order to take advantage of the new functionality, one has to be careful to ensure that only XHTML+MathML pages get sent to IE with an XHTML MIME type - presumably it will still choke on non-MathML XHTML pages. One could work around this by using the XHTML+MathML doctype everywhere, I suppose, but that shouldn’t be necessary, and is difficult on sites where there is much existing non-MathML content.

Clearly, this is also a problem when not all users will have the plugin. Unless there is some way clever of detecting the plugin server side (does it add something to the “accept” header?), you have to send text/html to all IE users so those without the plugin can get at the content.

You have to use the text/xml MIME type. I think I’m right in saying that text/xml has more scripting issues than application/xhtml+xml. It seems odd to support one and not the other.

I also assume that the XSLT processor in IE requires a well-formed document (their page makes no mention of the requirement for wellformedness)? Does the current mathtype plugin already required wellformed [itex] sections?

Posted by: jgraham on February 3, 2004 6:04 AM | Permalink | Reply to this

### Don’t be so glum

The current version of MathPlayer requires some nonstandard, bastardized, MathML-in-HTML4. With MathPlayer 2.0, I’ll be able to send out the same Standards-compliant XHTML+MathML page.

There remains the sticky problem of of detecting that the user has MathPlayer2.0 installed and setting the MIME-type accordingly. Surely, this is a solvable problem.

I think I’m right in saying that text/xml has more scripting issues than application/xhtml+xml.

That’s true of Mozilla. I assume it’s not true of IE.

And, yes, well-formedness is the minimal requirement in order to play in this league. But you knew that already …

On the bright side, their new plugin will begin to address the accessibility issues of MathML.

Posted by: Jacques Distler on February 3, 2004 8:18 AM | Permalink | Reply to this

### Re: Don’t be so glum

The current version of MathPlayer requires some nonstandard, bastardized, MathML-in-HTML4. With MathPlayer 2.0, I’ll be able to send out the same Standards-compliant XHTML+MathML page.

I rather optimistically assumed that MathPlayer already worked with the same syntax as XHTML, but retained the requirement that the MIME type be set incorrectly. If that’s not the case, this is really a worthwhile improvement.

There remains the sticky problem of of detecting that the user has MathPlayer2.0 installed and setting the MIME-type accordingly. Surely, this is a solvable problem.

Maybe it’s worth asking/suggesting that something like “application/xml+xhtml” or even just “application/vnd-dessci-xml+mathml” be added to the IE accept header when the plugin is installed. This would provide an easy way of detecting MathML enabled IE users.

And, yes, well-formedness is the minimal requirement in order to play in this league. But you knew that already …

Yes, but I can imagine MathPlayer not requiring well-formedness, which, apart from irritating the XML crowd no end, would mean pages written with MathPlayer in mind wouldn’t work in Mozilla.

On the bright side, their new plugin will begin to address the accessibility issues of MathML.

That does indeed look excellent. I guess I’ve asked this before, but are you aware of any tools for converting itex/LaTeX/MathML to text? I would love to be able to provide pages with bitmapped equations and good alt text for those unfortunates without a proper MathML enabled browser. Having good alt text would obviously also make the content avaliable to a range of text/voice/small device browsers without the manufacturer having to implement specific MathML support.

Posted by: jgraham on February 3, 2004 10:51 AM | Permalink | Reply to this

### Re: Don’t be so glum

People with visual impairments have many different needs. Those who are blind usually want to not only hear the math, but also potentially feel it (using whatever braille math notation they have learned), and probably “navigate” it for better understanding. Alt text for an image may solve one of their needs (if the alt text provided is clear, unambigious, etc), but can’t address their other needs. However, there are probably 100 times more people with poor/weak vision, and the alt text doesn’t help them much. Being able to see the math (and document) in a larger font is important. There is another large group of people who benefit from audio reinforcement of what they read, which typically means synchronizing highlighting with the audio.

MathML has the possibility of meeting all of those people’s needs. Images are a very poor second. Admittedly, I’m biased. I work for Design Science on accessibility issues for MathPlayer. We are working on all of those areas to make mathematics more accessible to those with vision-related impairments.

Alt text may make life easier on implementors, but it doesn’t go very far to make life easier for user’s with vision-related impairments. For more info on Design Science’s accessibility work, see Design Science’s accessibility Web page.

Posted by: Neil Soiffer on February 3, 2004 12:04 PM | Permalink | Reply to this

### Zoom!

However, there are probably 100 times more people with poor/weak vision, and the alt text doesn’t help them much. Being able to see the math (and document) in a larger font is important.

Absolutely! That’s why we, here at Musings, use MathML for equations and SVG for figures (see, for instance, this entry). They all rescale together when you hit the “text zoom” button in your browser.

Posted by: Jacques Distler on February 3, 2004 12:16 PM | Permalink | Reply to this

### Accessibility Issues

Obviously, using MathML has the potential to be much much better than gifs for maths content. Certianly a browser which has built in support for MathML and can render the content in the most appropiate way for the reader is by far the best solution.

The immediate advantage of being able to provide gifs / alt text as an inferior alternative presentation of maths is that it allows people using the current generation of browsers to have some access to the content, even when their browser does not have specific support. Users of Opera, for example, do not have the option of native MathML support. On the other hand, their browser does allow resizing of images (whereas IE doesn’t even allow resizing of all text). For that reason, people with visual difficulties may find Opera to be an attractive browser. In this case Maths-as-gif serves them much better than not displaying anything at all. Similarly, people using text browsers will find decent alt-text to be more helpful than a blank space.

The immediate problem with MathML is lack of implementations. Most people don’t care about Maths in general, let alone MathML, and most browser makers don’t see the profit in implementing it. The advantage of short term hacks like alt-text and gifs is that they work in situations where the alternative is to display nothing.

Posted by: jgraham on February 3, 2004 12:27 PM | Permalink | Reply to this

Post a New Comment