Re: Math WG comments on latest CDF documents

Ron, David and Math IG,

Thanks for your comments to the CDF drafts.  Regarding your comments on 
the usage of MathML and layout issues, we do not plan to address these in 
our work package 1 items of compound documents by reference.  We do not 
prevent future CDF profile creators to specify this.  The CDF WG may 
investigate this issue in future work.  As it stands for now, the next 
work package will provide a framework for compounding by inclusion but 
there is not a plan to also deliver a MathML based profile with it.  The 
CDF WG would encourage the Math WG to propose a solution for us to 
consider.

Please let us know within two weeks if this does not satisfy your 
comments.

Regards,
Steve Speicher on behalf of the CDF WG

Also in reply to: 
http://lists.w3.org/Archives/Public/public-cdf/2006Jan/0069.html


"Ron Ausbrooks" <ron.ausbrooks@mackichan.com> wrote on 09/20/2006 09:44:11 
PM:

> The Math Working Group has reviewed the current drafts of the CDF 
documents: 
> ·         WICD Core 1.0 
> ·         Compound Document by Reference Framework 1.0 
> ·         WICD Full 1.0 
> ·         WICD Mobile 1.0 
> We remain concerned that the issues raised in The Math Interest 
> Group's comments posted by David Carlisle on January 27 haven’t been
> addressed. The most critical issue with regard to MathML in compound
> documents is the lack of support for aligning the baseline of child 
> elements with that of enclosing text, or even mandating that width 
> and height be made available in communication between parent and 
> child documents. We would wish for the ability for child elements to
> take part in line breaking as well, but that’s less crucial. 
> The Compound Document profiles and recommendations have an excellent
> opportunity to address these issues, in keeping with the following 
> requirement from the Compound Document Use Cases and Requirements 
Version 2.0
> : 
> ·         3.2.3.3 CDI WICD Core MUST define layout semantics across 
> elements from varying namespace boundaries 
> CDI WICD Profiles must describe layout behavior in a way that is 
> meaningful when various component languages interact. CDF may define
> a vocabulary that specifications can use to describe the information
> that layout algorithms need from or provide to parent or child 
> objects in another document format. Examples of parameters that 
> parent elements need to provide to child elements are width and height. 
> It would seem that child objects – like inline MathML – which 
> produce content that is “text-like” need to have the ability to 
> participate in the layout flow of the surrounding text. For the 
> implementation rendering the child document to have access to the 
> available width and height, or the ability to provide its intrinsic 
> width and height to the parent, is the minimal requirement, but this
> doesn't seem to be explicitly mandated anywhere in the 
> recommendations. And while the intrinsic width and height are 
> sufficient to handle layout problems for many image objects, they 
> don’t provide enough communication for good layout of math. 
> Mathematics can contain subscripts and superscripts of arbitrary 
> size and complexity, large operators, fractions, matrices, and any 
> combination of these; there are established standards for properly 
> laying all of these out, but they generally require knowledge of the
> baseline. In particular, the baseline of the math needs to be 
> aligned with the baseline of the ambient text. While CSS can be used
> to request positioning the math at the baseline, CSS doesn't 
> currently contemplate a baseline for replaced content, so the result
> of baseline alignment is to align the bottom of the replaced math 
> with the surrounding baseline. Even if the CSS assumptions can be 
> changed, a containing application can’t align the ambient baseline 
> with the math baseline if only the width and height of the math are 
> communicated. (This wouldn't seem to be an issue solely for MathML. 
> Other content types, such as musical notation or chemical diagrams, 
> XForms objects, bibliographic content, or indeed Ruby markup if it 
> hadn't been incorporated into the XHTML namespace, may also produce 
> replaced content which should be rendered inline, and which would 
> need baseline information for correct layout.) 
> Similarly, mathematical expressions can reach nearly arbitrary 
> length, and math layout engines typically allow for linebreaking 
> within math. A method to allow negotiation of linebreaking between a
> child object and a parent would thus be very desirable – and again, 
> this would seem to be potentially useful for other types of content. 
> CSS can be used to handle some of these issues in some situations, 
> and current browsers (as David indicated previously) have provided 
> ad hoc solutions (or even added native MathML layout support). But a
> general and consistent solution to the problems of layout 
> negotiation between components and parents needs the child’s 
> intrinsic height and width to begin with, and baseline information 
> as well. And even if we succeed in getting improved CSS support for 
> baseline alignment (that is, getting CSS to allow for a baseline as 
> a property of even replaced content), mechanisms for passing these 
> between child and parent documents need to be mandated in order for 
> the CSS to be properly implemented, especially in situations where a
> plugin is used to render the child. 
> We’d very much appreciate your consideration of these issues. 
> Thanks, 
> Ron Ausbrooks 
> Writing on behalf of the Math Working Group
>

Received on Tuesday, 31 October 2006 15:38:55 UTC