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

Re: Labeled diagram and figure questions

From: <osserman@math.mit.edu>
Date: Sat, 28 Jun 2003 14:53:19 -0400
Message-Id: <200306281853.h5SIrJG16557@lagrange.mit.edu>
To: www-math@w3.org

>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).

   In hindsight, I think I meant dashed rather than dotted arrows, where the
situation isn't quite as bleak as only having a single direction, but where
I still don't think there are any diagonals.
   I can certainly provide a body of literature on this particular example:
dashed arrows are used frequently in algebraic geometry in diagrams when 
one is a given a particular set of maps, and wants to describe a condition
(usually existence or uniqueness) on a hypothetical additional map.
Moreover, due to the nature of the usage, diagonal dotted arrows are
ubiquitous in foundational definitions (as in "valuative criteria" and
"formal smoothness (unramifiedness, etaleness)"). A typical example is on
page 101 of Hartshorne's basic Algebraic Geometry textbook.
   On the other hand, it occurs to me that stretching a dashed arrow
described by a given glyph seems like a rather poor idea, in that you really
want the width of the dashes to remain constant, rather than the number.
So something like SVG is sounding more and more like the correct solution.

>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.

   All right, this is basically what I wanted to hear -- it's not too
important to me whether the necessary support is via MathML or SVG, as long
as it exists (and as long as authoring software programmers can be convinced
to take advantage of it). Given that typical usage would be MathML imbedded
in SVG imbedded in a far larger mathematical document, it strikes me as
slightly odd that in some sense this would occur within the SVG framework.
I saw the SVG example, but there was (as far as I can recall) no mention of
being able to place MathML elements inside it.

>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.

   Mozilla seems to think it can handle this, or will at least be able to at
some point, and that's enough for me (given that what I have in mind is more
for professional use that commercial use, I have no compunctions about
making my users stick to particular software). Or am I missing something?

>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 based on this discussion, it would at least make
sense to mention in the spec, where the example of an SVG figure is treated,
that SVG has extension support for MathML imbedded in it.

>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'm rather ignorant on CSS formatting -- from a quick glance at a summary
of CSS positioning, it seems that relative positioning wouldn't let you
place more than one tag in a given image, whereas absolute positioning has
a problem that seems to me more serious than simple authoring: it would be
very unfriendly towards dynamic page generation using fragments of MathML
pages (preauthored or not). This would in particular be a disaster for the
application I have in mind, which involves as a central feature a search
capability which would of course dynamically show results compiled from
fragments matching the search (perhaps one could hypothetically dynamically
reauthor the page on each search, rendering the *entire* page into latex and
then author it back into MathML, but this seems limiting, very slow, and
unnecessarily work-intensive).
   I really don't understand why MathML shouldn't include a simple IMG
element into which one could conveniently place MathML fragments. It seems
like the clean and semantically correct solution to the situation.

>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.

   Flipping through any algebraically geometry book (Hartshorne's is
definitely a good example) will give you a sense of what is likely to be
used in the field -- a fair number of diagonal arrows, dashed arrows, hooked
arrows, and two-headed arrows, and all of them labelable. Arced arrows for
compositions would also be nice. Page 214 has an example using most of these
(and this is a basic textbook published more than 25 years ago). 
   It is also a good example for how not to do figures -- there are lots of
them, and they were clearly generated as fixed images, as none of the labels
match the font of the book itself. Now, the use of xfig has at least to some
extent made this problem a thing of the past, and I see no reason why you
shouldn't move ahead and finish the job, at least for documents authored
into MathML directly.
   Thanks for your response,

Brian
Received on Saturday, 28 June 2003 14:53:21 GMT

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