Re: Math on the web without MathML (CSS 2.1 rendering for HTML and XML)

Neil Soiffer said:
> On Tue, 11 Jul 2006 juanrgonzaleza@canonicalscience.com wrote:
>> In a IAP 2006 talk devoted to math on the web
>>
>> [http://web.mit.edu/violeta/www/IAP2006/]
>>
>> Ian Hutchinson cited some of rendering problems of MathML. One of
>> them was "often large braces or integrals are too big".
>
> I wasn't at Prof. Hutchinson's IAP talk, but I'm sure you have misquoted
> or misunderstood what he said.

I aknowledge your impartial remark. Let me cite Prof. Hutchinson:

<blockquote>
What Types of Web Publishing is MathML good for? (in principle)

- Islands of mathematics inside browsable material. [e.g. problem sets]
- Documents that will be read predominantly on-screen. [increasing
proportion]
- Conveniently navigable and searchable documents. [e.g. user manuals]
- Small documents that should load and display quickly. [e.g. announcements]

MathML cannot compete with PDF as printable medium.
</blockquote>

<blockquote>
Annoyances that remain

Besides the need for readers to download plugins or fonts, and their
inability to print, some rendering problems remain in MathML. Although
minor, they are annoyances; some are built into the standard.

Examples:
- multiple-character identifiers are rendered roman
- it is impossible to label aligned equations at the page edge
- often large braces or integrals are too big
- fonts are not as well chosen as TeX, e.g. italic v looks like
</blockquote>

Therefore my original quote was accurate when read the source: some
rendering problems remain in MathML...

Ian Hutchinson added something would be of great interest for the WHATWG
and his future HTML5

<blockquote>
Most of these problems are avoided if ordinary HTML is used.
</blockquote>

Of course, Ian Hutchinson recognized the font problems and sometimes
alignment problems of the pure HTML approach. Fortunately, CSS can be used
for the improvement.

In base to statistics in past 5 years Ian Hutchinson said

<blockquote>
There is substantial interest in translating TeX to HTML!

Predominantly this comes from students, academics, and researchers worldwide.

Numbers of TtM downloads are too small to make a believable assessment of
user base that prefers MathML.
</blockquote>

> It is quite likely that whatever problems
> Prof. Hutchinson pointed out are those of the renderer he was showing,
> not MathML.

Not true (as others claims from MathML folks). He exactly said:

<blockquote>
some are built into the standard.
</blockquote>

> Also, in cases where the default behavior of MathML is not
> desired, MathML allows control over how large or small the character
> should be (within the constraints of the renderer).

Regarding the stretching of parentheses in MathML, Luca Padovani recently
recognized:

<blockquote>
A quick analysis of the MathML markup reveals that there is no way to
preserve the structure of the formula and still have a "correct" rendering
at the same time.
</blockquote>

> Also to be noted is that Prof. Hutchinson is a proponent of MathML, not
> a opponent -- he authored one of the leading TeX to MathML converters
> (TtM), and MIT (or at least the Information Services and Technology
> Department) endorses the use of MathML:
> http://web.mit.edu/ist/topics/webpublishing/mathml/index.html

Prof. Hutchinson finalized if talks recognizing that

<blockquote>
MathML has a number of weaknesses.
</blockquote>

Hutchinson asked, will MathML ‘take off’ and take over web mathematics
publishing?

His reply was:

<blockquote>
My guess is that it won’t. But with luck it will gradually become more
widespread.
</blockquote>

After of a carefully study of MathML capabilities, of the (unfortunate)
history of mathematical markups for the web, and some experiences at the
Center (remember that we are using MathML 2.0 in publishing), we abandon
the MathML approach, encourage to all us users, collaborators, and
visitors to abandon MathML, and sincerely wait that rest of scientific and
mathematical community prefer CSS approaches for HTML, XHTML, and XML
markup documents.

>
>> > Rendering of large brackets requires positioning of bracket-fragment
>
>> > characters
>>
>> There is no such one requirement.
>
> All of the math typesetting systems that I am aware of that have had
> widespread usage the last 40 years use fragments for laying out parens,
> etc.  Stretching a paren or using a large font size results in
> unacceptably poor looking results.  If you have a system for math
> typesetting and it doesn't allow positioning of bracket fragments,

Nobody said that a CSS approach does not allow the use of fragments. That
was said here is that CSS lets other techniques also. Those novel
techniques (visit XML-MAIDEN project for some details) let us draw
arbitrarily large curved and squared brackets _without_ requiring special
fonts at the client side.

> either it relies on some new font technology or is producing math
> display whose quality has been deemed unacceptable in the past.

Or simply once again MathML folks ignore CSS...

> Neil Soiffer
> Senior Scientist
> Design Science, Inc.
> www.dessci.com
> ~ Makers of Equation Editor, MathType, MathPlayer and MathFlow ~
>


Juan R.

Center for CANONICAL |SCIENCE)

Received on Thursday, 13 July 2006 11:56:21 UTC