Re: Stretchy equal sign for commutative diagrams

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/frederic

Received on Tuesday, 26 March 2013 10:30:40 UTC