Re: Labeled diagram and figure questions

As I was thinking about these issues lately, I am very excited to see this
discussion.
As diagrams are not just illustrative but an essential part of written
algebraic geometry, it seems to me that MathML ought to be able to
describe them. I am very much in favour of using SVG for diagrams, but I
think that there needs to be some kind of MathML wrapper around this, in
keeping with the philosophy that XML encodes the logical structure of the
document. I want to be able to naturally refer to parts of diagrams just
as easily as I am able to refer to other equations and have structural
ways of referring to different types of arrows, perhaps resulting in
different kinds of graphics depending on the output medium (like gray
instead of dotted arrows for existence diagrams or changing the color of a
diagram to represent commutativity instead of some kind of circle or box
if color is not available).

My question: Am I wrong if I think that MathML should encode diagrams on a
mathematical level (probably using SVG) instead of just using graphics
primitives?

Excuse my rambling,
Boris.


On Sat, 28 Jun 2003 18:59:15 +0100, David Carlisle wrote:

> 
> 
> 
> 
>> 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 Monday, 30 June 2003 01:40:08 UTC