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

Date: Tue, 26 Mar 2013 11:26:32 +0100

Message-ID: <515177D8.6080605@free.fr>

To: www-math@w3.org

Date: Tue, 26 Mar 2013 11:26:32 +0100

Message-ID: <515177D8.6080605@free.fr>

To: www-math@w3.org

Patrick, Thank you for your message. The title of my message is a bit misleading, as I said I'm only considering the simple commutative diagrams allowed by the AMScd package and I hope that in the future we will be able to beautiful MathML+SVG diagrams. I agree that the long equal sign is not fundamental for commutative diagrams (and probably even less in other situations), I think it's just an artifact of the AMScd implementation, namely to rely exclusively on tables and on normal stretchy rules to layout the diagrams. This unfortunately only allows vertical and horizontal arrows/bars and so the = sign is necessary to transform the triangle into a square as you indicated. It seems to me that the goal of stretchy rules in mtable is to make such simple diagrams possible with MathML code only. Perhaps the Math WG should have refrained to suggest using that for simple commutative diagrams. But SVG was probably not really available at the time the first MathML specifications were written and mixing these languages was probably even less possible. I think the idea here is that the AMScd / MathML commutative diagrams are very simple and so can make the implementation easier for the authoring tools and for the rendering engines until more sophisticated commutative diagrams are implemented. For example for MathPlayer, I guess implementing stretchy rules in mtable was easier than to wait for Microsoft to implement SVG in Internet Explorer. Similarly, for authoring tools, LaTeXML and MathJax are taking the same approach: implement AMScd first until SVG-based packages are ready (both projects have plans about that). However, I should say that we have the opposite situation with Gecko, where SVG is better implemented than mtable stretchy rules and Jacques Distler's Instiki relies heavily on MathML+SVG for commutative diagrams. BTW, Jacques Distler mentions that MathJax has issues regarding mixing SVG and MathML, but I think it's probably a bug in Webkit, not MathJax [1]. So, if we accept the idea that at least for MathPlayer in IE < 9 and AMScd implementations, MathML-only commutative diagrams make sense, my point is that the projects should try to agree about the equal sign. MathJax and LaTeXML's AMScd implementation is to use <mo stretchy="true">=</mo>. MathJax's MathML rendering engine supports that syntax but other MathML implementations like Gecko or math fonts do not have provision to stretch the equal sign. By default, the equal sign is not stretchy in the MathML operator dictionary, so the problem is only to allow stretching when an explicit attribute is specified. As others mentioned, we can just use Unicode characters for that purpose so it's really not a font problem (except that the construction is not present in the Open Math table). I already reported a bug to Bugzilla [2] and someone volunteered to fix it. Anyway, even if the rendering engine is not able to stretch the equal sign, the commutative diagram will still make sense, just that it will not look like the LaTeX rendering. [1] https://bugs.webkit.org/show_bug.cgi?id=93358 [2] https://bugzilla.mozilla.org/show_bug.cgi?id=854339 On 26/03/2013 10:13, Patrick Ion wrote: > 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. > ........ > > -- Frédéric Wang maths-informatique-jeux.com/blog/fredericReceived on Tuesday, 26 March 2013 10:30:40 UTC

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