Re: building accessible math websites -- need comments

[adding -www-math back to cc list]


   Hello!

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

   DC>  IE       can      parse      the      normative      DTD      at
   DC> http://www.w3.org/Math/DTD/mathml2/xhtml-math11-f.dtd

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

   Sorry,  it  is  my error. Thanks!

   Last versions of MSIE CAN parse DTD. But there are different problem.
   MSIE  downloads  DTD's  and XSL's from w3.org (or it's copies on same
   servers)  too slow.

Oh yes, that is certainly the case. As discussed on this a day or so
ago, I tend to avoid putting a doctype on files served as XML, for this
reason

   So,  during  the usability tests we found that many users with dialup
   connections  can't wait for downloading, they think that something is
   incorrect and closing pages.

I'm not surprised. While I was editing that DTD _I_ was working over a
dialup connection most of the time doing a CVS check over the phne
wasn't a lot of fun either:-) There si however no need to put a DOCTYPE
on the file at all in most cases. If you _do_ use a DOCTYPE make sure it
is the standard xhtml+mathml one that is recognised by mathplayer then
mathplayer will intercept the document and stop IE downloading the DTD,
and add any object etc that is needed.

   MSIE  process  Math  with downloading DTD's, gecko's don't. Maybe, in
   some cases sending "text/html" is good solution ?..

It's good in the sense that it works, but it's bad in the sense that it
is just wrong a document served as text/html should be HTML or
(arguably) XHTML 1.0 meeting the "compatibility requirements". an
XHTML+MathML document is neither of those things.

Yes If you put on a DOCTYPE send the document as 
   >> That's why we need to send "text/html". In this case, IE plugin is
   >> only Active-X object, connected via "object" XHTML element.

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

   Okay,  I  know.  Maybe, CMS is not standard solution, but with CMS we
   can  use  user-preferences based on cookies, so, people who installed
   both  MP and TE can choose, what plugin optimization they need. Is it
   useful?.. In my opinion, it is...

Yes I agree. Such a system is often very desirable. I have pushed hard
that it should never be _needed._ With, for example the pmathml.xsl
stylesheet I wanted it to be possible for people to put up an
xhtml+mathml document on a typical "free" website with no possibility of
server customisation, ie it should be as easy to put up mathematical
document as an textual one. However (as you found) getting such cases to
work does involve some compromises that may not be appropriate in all
cases (or ever:-) so a server side solution (which will always be more
flexible of course) may well be preferable for your application.

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

   DC> For  windows  and  mac  at  least  MIT made a nice font installer
   DC> package http://web.mit.edu/atticus/www/mathml/

   I  know. We used "FreeSerif, FreeSans, CMEX10, CMMI10, CMR10, CMSY10,
   Math1,  Math2,  Math4, Math5", because users need math-fonts and good
   Unicode-fonts  (from  FSF,  for  example).  Also, it is a problem for
   newbies to use MIT installer on linux platforms ;-) Am I right?..

It's a problem for _anyone_ to install fonts on linux (or X-windows, not
just linux:-) recent builds apparently need you to disable pango as well
If you have a simple font installation package for linux that works for
linux mozilla builds a_lot_ of people would be interested in that!

   Anyway, the fonts are not the problem.

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

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

   Okay. But maybe the "nowrap" rule in the CSS-stylesheet is better and
   more  accurate  than  using  the  hight-level  "mrow" element in EACH
   formula ?..

yes or no, if you definitely don't want any wrapping then yes, if you do
want fner control then perhaps not.Of course mozilla's treatment of mrow
is a bit more agressive than suggested by the spec (although it is
conformant) The spec suggests that line breaking should be progressively
discouraged the deeper the mrow nesting.

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

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

   Ok.

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

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

   But   if   MSIE  user  have  no  installed  plugins,  he  can't  open
   xhtml+html's? Right?..

True although you can use application/xml (if using the stylesheet)

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

   DC> Your  CMS  option  setting  preferences  sound  like a reasonable
   DC> solution  to this problem. Another possibility that allows you to
   DC> always  send  invisible  operators  is  to  put  them  in  an <mo
   DC> class="invisible>  together with some css that makes these things
   DC> really  invisible  even  on  older  mozillas that would otherwise
   DC> render it as a missing glyph symbol.

   Maybe,  but  server-side  symbols  deleting  can  be used not only as
   special   option.   We  can  cut  invisible  operators  according  to
   "User-Agent".

   Also, changing preferences is very simple process. For example:

   <p><input  type="checkbox"  name="invisible"  />use  MathML invisible
   operators</p>

   <p>You  can switch off option, if you see any strange symbols in this
   field:</p>

   <div style="width: 100px; padding: 10px; min-height: 20px; font-size:
   150%;  font-weight:  bold;  background:  #ddddee; text-align: center;
   vertical-align: center">&ApplyFunction;&InvisibleTimes;</div>

   <p>If  you  see only the coloured block, everything is OK. Please, do
   NOT use this option with aural-brousers.</p>


See above,  I did not mean to sggest that you should not use server side
code, I was just floating other alternatives.

   [...]

   Anyway,  your comments is very useful and I'll correct the speech. If
   I  resume  the  main idea of work, using CMS for Math optimization is
   not the best solution and there are many other solutions, but CMS can
   be  very useful while popular browsers and it's plugins can't process
   Math  in  the  one  manner and some popular releases of programs have
   bugs in MathML processing.

This is true, the same can be said of course of the xsl stylesheets.
It's a shame that they have to be there (and the need for them gradually
decreases) but they were designed to "hide" any nastyness required to get
systems to display mathml, leaving the source files as clean
xhtml+mathml files. The server side transforms you suggest are similar
in that respect. I hope I didn't imply that the client side solutions
were always superior. In fact the argument is moving more and more
towards server side solutions I suspect. Having MathML display in
netscape mozilla and IE was good progress at the time, but now people
want to browse the web on their mobile phone, and these devices require
a lot of document manipulation to fit a small screen, and don't offer
much in the way of onboard processing, so getting the server to send
something more suitable has many advantages..

   P.S.  I  have  many  problems  with  posting to www-math, because the
   system does not sending the approval msgs (or it is the problems with
   my  pop3  provider,  I'll try to change pop3 server). Can you forward
   this to www-math?..

Done.

   Thanks!




________________________________________________________________________
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:
http://www.star.net.uk
________________________________________________________________________

Received on Tuesday, 11 October 2005 20:40:57 UTC