From: Patrick Ion <ion@ams.org>

Date: Tue, 26 Mar 2013 11:13:12 +0200

Message-ID: <515166A8.8010402@ams.org>

To: Frédéric WANG <fred.wang@free.fr>

CC: www-math@w3.org

Date: Tue, 26 Mar 2013 11:13:12 +0200

Message-ID: <515166A8.8010402@ams.org>

To: Frédéric WANG <fred.wang@free.fr>

CC: www-math@w3.org

Dear Frédéric, I would agree heartily with what Ross says about the semantic marking of arrows in commutative diagrams. The extra long equals that is used from time to time, often just to straighten up other arrows by essentially duplicating a node (say to make a square out of a triangle), doesn't seem to me essential. Of course, the equal sign actually introduced by Robert Recorde had by present-day standards very long bars, say about 5 times longer than today, i.e. 8em or more---see http://www.jstor.org/discover/10.2307/27955396?uid=3738128&uid=2&uid=4&sid=21102045047697 It could be argued that there should be a character for a stretchy double arrow body (without a head), but we have never been able to get the idea of a full arrow kit adopted, although it would be much more flexible. By this I mean the arrow equivalent of the piece collections for stretchy parens, brackets etc. That and a consistent use of direction-changing operators generalizing the bidi one in Unicode, to say a dihedral group of order 16, would have greatly reduced the number of characters needed, increased flexibility, and could have simplified implementation. In general though, I'd suggest that a combination of SVG for larger diagrams and MathML for equational decorations (the whole possibly to be viewed as a math object) should be the way to go. This applies to operators in cartouches, such as occur in some algebraic papers, and I'd say to such things as braid group calculations, although there are now fonts for them around, I think. There are going to come situations where there are active three- or more-dimensional commutative diagrams being bandied about, I guess. Spectral sequences and associated lemmas (e.g. 5- and 9- et al.) and the sort of triangles used in contexts with derived functors like, say, Kashiwara's also make for difficult composition, but I can imagine wanting to set up dynamic illustrations of calculations with them featuring waves of changes across the diagram as more and more becomes clear when the required special cases of general rules are reckoned. After all that's how the results are actually worked out, so that would just be a little more fancy example of the injunction to `show your work'. But we don't yet have a markup that is clearly well-suited to these situations, so there's no implementation problem. I applaud with enthusiasm your important continued push to implement more of MathML right. The Math WG is deeply in your debt, but it's no doubt the benefit to the math community that's most significant. All the best, Patrick On 3/25/13 10:50 PM, Frédéric WANG wrote: > Hi Ross, > > Thanks for you feedback. > > I should say that I'm considering the AMScd package, so very basic > commutative diagrams. For more complex diagrams, I don't think it's a > good idea (or even possible) to use pure MathML but it's better > instead to rely on SVG for the graphical elements. IIUC, that's what > does XyJax (Xy-pic package for MathJax) or another package being > developed for LaTeXML. > > AMScd only implements diagrams with vertical/horizontal arrows. So > here we can just use a table with stretchy operators inside. All > arrows and bars usable in AMScd are already defined stretchy in the > MathML operator dictionary. Only the case of the equal sign is not > clear, thus my message. > > On 25/03/2013 21:34, Ross Moore wrote: >> Hi David, and others. >> >> When designing and developing Xy-pic, many years ago, we decided that >> the most convenient representation was putting an '=' as a label >> above a single line, with all the stretchiness being in the line. >> This fits with labeling using other characters for different special >> meanings. >> Authors can choose to use a double line, if they like, but although >> the spacing between the lines can be controlled, there is no easy way >> to match it to the actual separation of a specific font character. >> The syntax to use a double line is quite different to that of placing >> a single character. ........Received on Tuesday, 26 March 2013 09:16:17 GMT

*
This archive was generated by hypermail 2.3.1
: Tuesday, 26 March 2013 09:16:17 GMT
*