W3C home > Mailing lists > Public > www-math@w3.org > October 2005

Re: building accessible math websites -- need comments

From: David Carlisle <davidc@nag.co.uk>
Date: Tue, 11 Oct 2005 14:38:08 +0100
Message-Id: <200510111338.OAA11415@penguin.nag.co.uk>
To: www-math@w3.org, beshenov@bk.ru

> After  the  some tests, we found that there are too many
> bugs  in  MSIE  parser  to use it for rendering XML (it can't process
> xhtml-math11-f.dtd,   for  example).

IE can parse the normative DTD at

Are you using a different, older,  version of the DTD?

> That's  why  we  need  to  send
> "text/html".  In  this  case,  IE  plugin  is  only  Active-X object,
> connected via "object" XHTML element.

If you use the MathPlayer 2 that should not be necessary, it can
intercept xhtml+mathml documents and internally add the microsoft
specific object required. Alternatively if you reference the pmathml.xsl
stylesheet, this should work for either mathplayer or techexplorer, for
documents served with an xml mime type.

> +   Gecko   requires  special  fonts.  We  compiled  special  package
> containing  free  TrueType's  FreeSerif,  FreeSans,  CMEX10,  CMMI10,
> CMR10,  CMSY10,  Math1,  Math2,  Math4,  Math5. It is all fonts users
> need.

For windows and mac at least MIT made a nice font installer package

> +  Gecko  can  wordwrap  math,  if math is inline. So, we can specify
> "white-space:   nowrap"   in   the   style-sheet,  because  classical
> math-notation  using  wordwrap on operators (after the "+", "-", "=",
> for example). So, we don't need simple text wordwrap.

I'm not sure what the issue is you are raising here? You can use mrow
nesting to control line breaking in mozilla (it never breaks inside an

> We  don't  know,  why  it  is so, but after some tests we
> changed "m:" to "mml:" and everything is OK.

Odd, if you can reproduce that, take it up with the product maintainers.

> For  MSIE we should send everything as "text/plain". For others -- as
> "application/xml" (xhtml+xml).

I assume you mean text/html rather than text/plain. If you are
distinguishing on the server, then this is OK, although as I say above
you should be able to use (xhtml+xml) in all (or at least more)  cases.

> we  found  that  many  UA's  (old  geckos, for example) can't process
> invisible  symbols

Yes, It's true that some versions have had problems with invisible
operators. You always have an option to not use them (If you look at the
content-to-presentation stylesheet on the w3c site the apply function
invisible operator is commented out for exactly this reason.
That was a rather old stylesheet though (written for mozilla 0.9x and
IE5 originally). This is of course a general problem with working on
widely distributed software: if the software has a bug and the bug gets
fixed, how long do you need to support the broken version?: probably for
some years in the case of software that is as widely distributed as a
web browser. Your CMS option setting preferences sound like a reasonable
solution to this problem. Another possibility that allows you to always
send invisible operators  is to put them in an <mo class="invisible>
together with some css that makes these things really invisible even on
older mozillas that would otherwise render it as a missing glyph symbol.


This e-mail has been scanned for all viruses by Star. The
service is powered by MessageLabs. For more information on a proactive
anti-virus service working around the clock, around the globe, visit:
Received on Tuesday, 11 October 2005 13:39:17 UTC

This archive was generated by hypermail 2.3.1 : Tuesday, 6 January 2015 21:27:36 UTC