Re: Labeled diagram and figure questions

> I couldn't find two fairly common ones: dotted and
> two-headed (ie, for surjective maps) diagonal arrows. 

If you mean that the stem is dotted, as in ....> then I believe you are
correct, the only dotted arrow in Unicode 4 appears to be 2911, which is
a dotted right arrow.  MathML (and XML generally) is more or less
constrained to the character set provided by Unicode so unless you
use mglyph to point to a particular font, these arrows are unfortunately
not available. It is of course possible to lobby Uniocde to add more
characters (the last three Unicode releases 3.1, 3.2 and 4.0 have all
added many mathematics characters due to pressure form the Stix
consortium, this working group and others) So if you can cite a body of
literature using those characters then it isn't impossible that they
would be added (but is out of our hands).


>    As far as I have been able to tell, the current intent for, say,
> commutative diagrams, is to offer limited support via mtable.

Yes mtable offers the same kind of support for commutative diagrams as
plain tex or latex array constructs without extensions such as xypic or
pstricks: horrizontal arrows may be decorated using mover, vertical
arrows may be decorated just by placing the label next to the arrow in
the appropriate cell. This is enough for simple cases but for many 
diagrams you will need more.

You didn't mention which version of the mathml spec you have been
looking at but in the current "last call" draft of mathml 2 2nd edition
we do say a bit more about images (but not commutative diagrams)
and give an example of using SVG to produce an image.

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 Saturday, 28 June 2003 13:59:27 UTC