W3C home > Mailing lists > Public > public-cdf@w3.org > January 2006

Math IG comments on CDF Last call documents

From: David Carlisle <davidc@nag.co.uk>
Date: Fri, 27 Jan 2006 23:19:55 GMT
Message-Id: <200601272319.XAA02127@penguin.nag.co.uk>
To: public-cdf@w3.org




Math IG comments on the Last Call CDF documents:

WICD Core 1.0 
http://www.w3.org/TR/2005/WD-WICD-20051219/

WICD Full 1.0 
http://www.w3.org/TR/2005/WD-WICDFull-20051121/

WICD Mobile 1.0 
http://www.w3.org/TR/2005/WD-WICDMobile-20051121/

Compound Document by Reference Framework 1.0 
http://www.w3.org/TR/2005/WD-CDR-20051219/


Summary
=======

The current Framework (and hence the profiles defined based on that framework),
do not support features necessary for display of compound document
formats such as XHTML+MathML, and which have been available in common
desktop browsers for many years. The Math Interest Group urgently
request that the Framework (and Core and Full profiles), support the
automatic determination of the size and alignment of the rendered
referenced (or included) language fragment.




Historical background
=====================

As you will be aware, MathML has long been a primary example of a W3C
Recommendation designed for use in a Compound Document Format, having
been first issued as a W3C Recommendation in 1998 within a few months of
the XML recommendation.


Common desktop browsers have been capable of displaying (X)HTML+MathML
documents by reference since the initial recommendations. (Roughly
speaking Internet Explorer 4 and Netscape 4 era browsers). The
mechanisms for referencing external MathML content differed between
MathML systems and browsers (applets, plugins, object tag or embed tag,
etc) They also suffered from problems with spacing and alignment
although that could be overcome to a certain extent using scripting
interfaces to modify alloted size.

Similarly common desktop browsers (IE 5.5, IE6,
Mozilla/Netscape/Firefox) have been able to display XHTML+MathML "CDI"
format markup for 4 years or so. Here the situation is rather better
than in the CDR case, standard markup can be used, although differences
in browser internal interfaces mean that it is more difficult than one
would like to manipulate the resulting DOM from script.

Thus it has been apparent for at least 8 years that a recommendation was
needed specifying the markup and APIs that should be used to provide
cross platform access to this capability and the Math Interest Group was
very supportive of the creation of the Compound Documents activity.

Unfortunately there appears to be a real danger that the current CDF
working drafts are standardising a framework that would not support
MathML (or any language with similar requirements) at all. 

We understand that the current priorities are aimed at the Mobile and
other small footprint applications, and that MathML would not be
included in the Mobile profile, but it is Essential that the _Framework_
support MathML, and highly desirable that the Desktop profile should
similarly support the possibility of MathML (if not actually requiring
MathML rendering).



While standardised access to DOM scripting and interaction is desirable,
the most fundamental requirement is the ability to _display_ the
embedded language (MathML in our case). The main requirement here is
that there has to be negotiation between the renderer of the host
language and renderer of the embedded language as to the screen area and
position. The size of a mathematical expression can _not_ be specified
in the markup, it must be calculated by the MathML renderer (as the size
and alignment depend on properties of the rendering engine, current
fonts, lineheights and so on, and thus further depends on the state of
the CSS engine). Both the width, and the vertical positioning of the
embedded rendering must be calculated, so as to align the baseline of
the mathematical expression with the baseline of the surrounding text.

In the case of CDI formats, this size negotiation is available in IE
(via its activex component interfaces, and in mozilla browsers, where
the mathml rendering is added as a native extension) in the older CDR
formats using plugin and applet markup, it is possible to use javascript
to manage the size negotiation, but again the functionality is there
(and has been for many years), what was lacking is any standardised
interface.


The requirements for such a compound document rendering were outlined in
this 1998 submission to the Math Working Group
http://www.w3.org/Math/W3CDocs/mathmlrequ.html
and for a more modern expression of the requirements, a presentation at
the W3C's CDF workshop:
http://www.w3.org/2004/04/webapps-cdf-ws/papers/designscience.html


The nearest the current documents get to discussing the size of the
rendered content is
3.3/1 Rightsizing
http://www.w3.org/TR/2005/WD-WICD-20051219/#rightsizing
which is unfortunately totally inadequate, it is not possible to put the
size of a mathematical expression explicitly into the markup, it depends
on so many factors, and in particular it depends on the MathML rendering
engine being used, and on user defined CSS stylesheets which may alter
the ambient environment such as current font size.



The CDR framework document gives an example of a
XHTML+MathML document (using inclusion rather than reference) however the
example is over simplistic as it uses a displayed equation so doesn't
demonstrate the essential ability to be able to render inline equations
such as E=mc^2 with the equation forming a natural part of the text
stream, using the current text size, and with letters correctly aligned
on the baseline of the surrounding text.


David Carlisle
Co-Chair Math Interest Group
Writing on behalf of the Group


________________________________________________________________________
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 Saturday, 28 January 2006 01:10:07 GMT

This archive was generated by hypermail 2.2.0+W3C-0.50 : Tuesday, 8 January 2008 14:10:40 GMT