W3C home > Mailing lists > Public > www-math@w3.org > June 2003

Re: Labeled diagram and figure questions

From: Stan Devitt <jsdevitt@stratumtek.com>
Date: Sun, 29 Jun 2003 07:45:28 -0400
Message-ID: <3EFED158.30609@stratumtek.com>
To: David Carlisle <davidc@nag.co.uk>
CC: osserman@math.mit.edu, www-math@w3.org

In this very interesting exchange I have seen some discussion of
requirements for labeled diagrams and some of possible realizations
( e.g. mapping to pdflatex or SVG + MathML).

What I was kind of expecting to see, but did not,  was a discussion of
something more analogous to the design of a latex package for
commutative diagrams but probably in XML with its own name space
and suitable for automatically transforming to one of these realizations
via the universal style sheet kind of idea.  Of course it would use MathML
for the embedded expression markup and maybe SVG.

Note that the only real difference between such an approach and how
content mathml is handled in browsers at present is that the content 
mathml spec
is part  of the official spec.   Browsers still generally rely on the 
universal style sheet
to get it into a  format that  can be displayed. 

This is an  approach that can also be used generally to address the general
issue of  how to develop extensions.  As a design matures, missing core 
primitives
could be identified and flagged for  moving  into the main spec.

Stan Devitt



David Carlisle wrote:

>
>SVG is probably the answer to commutative diagrams as well, this is more
>than capabable of drawing arced arrows between nodes at arbitrary points
>and placing mathematical text positioned to label the nodes and arcs.
>SVG has an extension mechanism that allows (at the language definition
>level) mathml fragments to be embedded and positioned within SVG, and
>this is all you really need for commutative diagrams.
>Unfortunately unless you have a system (like the W3C's amaya) that
>natively supports both SVG and MathML (and XHTML) and allows these to be
>freely mixed, current rendering technologies struggle to cope with these
>combound diagrams. In Internet Explorer for example, one has teh
>MathPlayer and Adobe extensions that render respectively MathML or SVG
>embedded in the hTML, but currently there is no API that allows the
>various components to cooperate on multiple nested namespaces. This
>problem affects all XML vocabulary (SVG in particular) not just MathML,
>the W3C's TAG technical architecture group has it as an item that they
>are committed to looking at as it isn't really something that can be
>solved by each language independently.
>
>If you are going to print rather than going to a web browser the
>situation is a bit better as there are stylesheets available that map 
>mathml to svg so could convert a mathml+svg document to an svg one which
>could then be printed, or you could convert an svg+mathml diagram to
>xypic+latex probably so long as you were reasonably constrained in your
>use of svg (ie explict coordinates, not calculating coordinates on teh
>fly using javascript) 
>
>As you may note all of the above is somewhet speculative, and we decided
>intentionally _not_ to say anything about it in the spec. We do however
>plan to produce a note discussing options for producing commutative
>diagrams and other figures, although work on that is on hold currently
>while we finish up the text of the 2nd edition spec.
>
>  
>
>>It seems to me that simple
>>support for images with MathML tags placed at specified locations (similar
>>to xfig's support for figures encoded in a combined ps/latex format)
>>    
>>
>
>That model does in fact relate quite well to the svg related route
>described above (or just a normal htl <img> what xfigs combined output
>is doing is making an eps image of the diagram without text, and a latex
>document that overlays tex fragments over that.
>
>You could do that now in a web browser, include the image (as svg using
>adobe's plugin, or as an image) and then overlay mathml fragments 
>using CSS absolute positioning.
>
>Currently you'd probably have to figure out and hand author the CSS
>position rules by hand, but that's just an authoring tool issue
>(I remember when you had to do the same for TeX:-) xfig or a similar
>tool could in principle write out the CSS positioning for you.
>
>
>  
>
>>   I would be very interested to hear what the working group's perspective
>>is on these issues. 
>>    
>>
>
>All of the above is personal ramblings and not an official WG position.
>
>We would in fact be very interested to see requirements that people have
>for diagras. As I mentioned we do plan to publish a note describing teh
>options for doing this in teh not too distant future, and more use cases
>may be useful.
>
>Thanks for your interest,
>
>David
>
>  
>
Received on Sunday, 29 June 2003 07:43:31 GMT

This archive was generated by hypermail 2.2.0+W3C-0.50 : Saturday, 20 February 2010 06:12:55 GMT