From: David Carlisle <davidc@nag.co.uk>

Date: Sat, 28 Jun 2003 18:59:15 +0100

Message-Id: <200306281759.SAA17764@e3000>

To: osserman@math.mit.edu

CC: www-math@w3.org

Date: Sat, 28 Jun 2003 18:59:15 +0100

Message-Id: <200306281759.SAA17764@e3000>

To: osserman@math.mit.edu

CC: www-math@w3.org

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

*
This archive was generated by hypermail 2.3.1
: Tuesday, 6 January 2015 21:27:33 UTC
*