Not signed in (Sign In)

Not signed in

Want to take part in these discussions? Sign in if you have an account, or apply for one below

  • Sign in using OpenID

Site Tag Cloud

2-category 2-category-theory abelian-categories adjoint algebra algebraic algebraic-geometry algebraic-topology analysis analytic-geometry arithmetic arithmetic-geometry book bundles calculus categorical categories category category-theory chern-weil-theory cohesion cohesive-homotopy-type-theory cohomology colimits combinatorics complex complex-geometry computable-mathematics computer-science constructive cosmology deformation-theory descent diagrams differential differential-cohomology differential-equations differential-geometry digraphs duality elliptic-cohomology enriched fibration foundation foundations functional-analysis functor gauge-theory gebra geometric-quantization geometry graph graphs gravity grothendieck group group-theory harmonic-analysis higher higher-algebra higher-category-theory higher-differential-geometry higher-geometry higher-lie-theory higher-topos-theory homological homological-algebra homotopy homotopy-theory homotopy-type-theory index-theory integration integration-theory k-theory lie-theory limits linear linear-algebra locale localization logic mathematics measure-theory modal modal-logic model model-category-theory monad monads monoidal monoidal-category-theory morphism motives motivic-cohomology nforum nlab noncommutative noncommutative-geometry number-theory of operads operator operator-algebra order-theory pages pasting philosophy physics pro-object probability probability-theory quantization quantum quantum-field quantum-field-theory quantum-mechanics quantum-physics quantum-theory question representation representation-theory riemannian-geometry scheme schemes set set-theory sheaf sheaves simplicial space spin-geometry stable-homotopy-theory stack string string-theory superalgebra supergeometry svg symplectic-geometry synthetic-differential-geometry terminology theory topology topos topos-theory tqft type type-theory universal variational-calculus

Vanilla 1.1.10 is a product of Lussumo. More Information: Documentation, Community Support.

Welcome to nForum
If you want to take part in these discussions either sign in now (if you have an account), apply for one now (if you don't).

nLab > Diagrams: XYMatrix -> SVG

Bottom of Page

1 to 37 of 37

  1.  
    • CommentRowNumber1.
    • CommentAuthorAndrew Stacey
    • CommentTimeJun 11th 2009
    • (edited Jun 11th 2009)

    There's lots more tweaking and stuff that I could do, but there comes a point where it's useful to have other points of view ...

    I've been working on a program with the original intention of converting xymatrix diagrams into SVG. It got a bit bigger and is on the way to being a LaTeX to XHTML+MathML+SVG converter. If you want to try it out, you can play with it here:

    http://www.math.ntnu.no/~stacey/PHPLaTeX

    The two main selling points are:

    1. It's written entirely in PHP, so it's quite portable.
    2. It tries to emulate TeX's method of parsing a document by reading and expanding tokens. This means that it can process macros.

    So if you write \newcommand{\R}{\mathbb{R}} then you'll be able to use \R for \mathbb{R} for the rest of your document.

    It's an alpha release, if even that, so don't expect it to do anything right. Also, you can't cut-and-paste the diagrams into the n-lab because it uses something that Jacques doesn't allow. However, if my method of getting MathML embedded into SVG produces reasonable results, then I don't think it would be hard to add support for the extra bits. (Instiki sanitises incoming SVGs and so has to be told to let through stuff.)

    Anyway, have fun playing with it if you feel so inclined. Let me know what's missing (I know that there's lots missing, but if you tell me then that tells me what to prioritise), and what it does wrong. You can download the source if you feel so inclined using bzr (just point it to the same place).

    Oh, and it currently only supports LaTeX maths environments. I'll put in support for dollars later since so many people use them (though they really ought to know better).

    • CommentRowNumber2.
    • CommentAuthorTobyBartels
    • CommentTimeJun 13th 2009
    This comment is invalid XML; displaying source. <blockquote>Well, I got it to break.<p >The input<blockqoute ><code >\[ \xymatrix { A \ar [d] _ f \ar [r] ^ g &amp; B \ar [d] ^ h \\ C \ar [r] _ i &amp; D } \]</code></blockquote> (which is valid in my LaTeX+Xy system) gives the errors<blockquote >Warning: Division by zero in /amd/abel/home/www/stacey/PHPLaTeX/latex.php(833) : runtime-created function on line 492<p >Warning: Division by zero in /amd/abel/home/www/stacey/PHPLaTeX/latex.php(833) : runtime-created function on line 493<p >Warning: Division by zero in /amd/abel/home/www/stacey/PHPLaTeX/latex.php(833) : runtime-created function on line 498<p >Warning: Division by zero in /amd/abel/home/www/stacey/PHPLaTeX/latex.php(833) : runtime-created function on line 499</blockquote></blockqoute></p></p></p></p>
    • CommentRowNumber3.
    • CommentAuthorTobyBartels
    • CommentTimeJun 13th 2009
    This comment is invalid XHTML+MathML+SVG; displaying source. <div> It's the space after the second <code>\ar</code> that breaks it. The input <blockquote><code>\[ \xymatrix { A \ar [d] _ f \ar[r] ^ g &amp; B \ar [d] ^ h \\ C \ar [r] _ i &amp; D } \]</code></blockquote> does not give these these errors. On the other hand, it doesn't seem to draw all of the diagram either; at least, I can't see the label on <i>f</i> or any of the bottom row.<p>Also, the forum software seems to be moving my &lt;blockquote&gt; tags around!</p> </div>
    • CommentRowNumber4.
    • CommentAuthorAndrew Stacey
    • CommentTimeJun 13th 2009

    Fixed both. Thanks.

    The first was subtle. The program has to detect the end of an arrow which it does by comparing tokens against a known list of arrow components. When it finds one that doesn't match, that's the end of the arrow. However, the non-matching token has to be put back into the stream. To ensure that this "putting back" doesn't mess things up later on, it inserts a null character after it. The script automatically trims off leading whitespace before looking for the components of an arrow but the null character was effectively stopping this cull so the next thing the script examined was a whitespace, which isn't on its list of known components and so heralded the end of the arrow.

    The second issue is because it's not too hot yet on estimating how big the diagram will be. I've increased the default size and your diagram should now display. The original xymatrix command has options for specifying row and column separation. I should probably add to that a way to increase or decrease the margins of the diagram. Or it may be possible to not specify a bounding box and let the renderer figure it out, I'm not sure. I'm still very new to SVG so am making it up as I go along.

    Thanks for testing!

    • CommentRowNumber5.
    • CommentAuthorTobyBartels
    • CommentTimeJun 13th 2009
    The labels on the arrows still seem off. I found the label on f; it's right on top of the arrowhead! And the label on i is rather farther from the arrow than would be easy to read if there were more of the diagram below. Since this stuff might depend a bit on how the browser reads it, here's a temporary screenshot.
    • CommentRowNumber6.
    • CommentAuthorAndrew Stacey
    • CommentTimeJun 14th 2009

    Yes, I haven't gotten the labels on the arrows anywhere near correct yet.

    • CommentRowNumber7.
    • CommentAuthorAndrew Stacey
    • CommentTimeJun 16th 2009
    • (edited Jun 16th 2009)

    Okey, dokey. I've made a few improvements. Try this one:

    \[
\xymatrix{
A \ar@/^2ex/[d]_{fg} \ar@([ur],[ul])[r]_i &
B \ar[d]|{fg} \ar@{}[ld]|h \\
C \ar@{{)}{-{|}-}{>>}}[r]_k & 
D
}
\]
    • CommentRowNumber8.
    • CommentAuthorTobyBartels
    • CommentTimeJun 16th 2009
    This comment is invalid XHTML+MathML+SVG; displaying source. <div> That looks pretty good!<p>I'd move all of the labels just a <em>little</em> higher; the ‘<i>g</i>’ on my test input doesn't quite clear its arrow, and all of them seem slightly lower than ideal. (I can provide another screenshot if it doesn't look that way to you.)<p>Your test input has some transparency issues; I'm viewing all of this on a grey background, but the two labels placed with <code>|</code> (‘<i>f</i><i>g</i>’ and ‘<i>h</i>’ from the line beginning with <code>B</code>) have white backgrounds. Also, I just noticed that if I move the label ‘<i>i</i>’ above its arrow (with <code>^</code> instead of <code>_</code>), then it disappears. Finally, I tried changing the shape of the arrow labelled ‘<i>h</i>’ from <code>@{}</code> to <code>@{=&gt;}</code>, but it was still invisible.</p></p> </div>
    • CommentRowNumber9.
    • CommentAuthorAndrew Stacey
    • CommentTimeJun 16th 2009

    Hmm, I wonder if there's some way to detect the background colour. The only way I could think of punching a hole in an arrow was to overlay a rectangle of the background colour but if the user changes that without me knowing, then the hole is wrong. I don't know how to implement it otherwise without a complicated calculation regarding the path ... I'll do some maths and see if it's possible to easily truncate a bezier curve.

    The 'i' does drop off the top, but then you've got to admit that the curve goes pretty high so it's not surprising that it reaches the edge of the picture. One thing still to do is add an option to enlarge the margins - xymatrix format allows for stuff before the diagram adjusting the separation of the nodes and stuff like that, I'll extend it to add options for the margins.

    Lastly, @{=>} is not a valid format. Valid styles have either one token (in which case they specify the head) or three (in which case they specify all three). So you should try @{{}=>}. And that's reminded me that I haven't sorted out the alignment of arrowheads with double and triple arrows so it won't look quite right (any thoughts on how best to fix that? I could define a load more arrowheads, or I could try adjusting the separation a little - I'm still learning SVG!)

    • CommentRowNumber10.
    • CommentAuthorTobyBartels
    • CommentTimeJun 17th 2009
    This comment is invalid XML; displaying source. <svg><blockquote >Lastly, <code >@{=&gt;}</code> is not a valid format.</blockquote> That's funny; it worked when I tested it in my TeX system.<p >Anyway, when I try either <code >@{==&gt;}</code> or <code >@{{}=&gt;}</code>, I get bad XML! <blockquote >XML Parsing Error: mismatched tag. Expected: </svg>.<br />Location: http://www.math.ntnu.no/~stacey/PHPLaTeX/index.php<br />Line Number 309, Column 3:<p ><code >&lt;/mrow&gt;&lt;br&gt;--^</code></blockquote></p></p>
    • CommentRowNumber11.
    • CommentAuthorTobyBartels
    • CommentTimeJun 17th 2009
    (OK, yeah, this forum software really doesn't know what <code> means, does it? I might add that it put one of its unnecessary </p> tags in the wrong place too.)
    • CommentRowNumber12.
    • CommentAuthorAndrew Stacey
    • CommentTimeJun 17th 2009

    Quoting from the xy-guide (p5-6):

    The arrow styles ... are all examples of the general arrow style constructions: @variant{_tail shaft head_}, @variant{_head_} that in describes arrows with the indicated tail, shaft, and head ... Notice that there is no distinction between shafts and tips using [the second] form, thus it is necessary to include all three of tail, shaft, and head, when using it.

    So @{=>} shouldn't work in TeX either! Okay, a little experimentation reveals what's going on. Basically, it's trying to be helpful and guess what you meant. If you specify two tokens then it first tries it out as a single tip (so @{>>} is the same as @{{>>}} which is the same as @{{}-{>>}}), if that doesn't work then it tries it as a stem plus a tip (which is what happens for @{=>}), and if that doesn't work then it gives up (try @{<>} for example). However, the @{==>} and @{{}=>} should work on PHPLaTeX and I've fixed what was making them not work (by the way, they give the same result because it ignores unknown markers. But if someone defines a marker = then the first will suddently become that one whilst the second will stay as it is.) Basically, I'd fixed something else that had broken this. Thanks again for testing!

    Oh, and the g probably doesn't clear its arrow because I haven't told the program that g has a non-zero depth (the capability for depth is built in but I haven't told it that anything has non-zero depth as yet).

    Oooo! Just thought how to do the hole-punching. I can use clipping paths.

    (and, yeah, I know that the markup filters are a load of rubbish. I guess that the 'Html' is the most confusing as it isn't a 'pass through' filter but tries to sanitise it first. Given that I have KSES installed there's no reason why I shouldn't have a 'pass through' filter but I've been busy with other things! Maybe if PHPLaTeX gets to beta stage I'll implement that as a filter then we can all use TeX and be Happy Once Again.)

    • CommentRowNumber13.
    • CommentAuthorAndrew Stacey
    • CommentTimeJun 17th 2009

    Okay, hole punch implemented! Try the All-New \ar[r]|f.

    • CommentRowNumber14.
    • CommentAuthorAndrew Stacey
    • CommentTimeJun 17th 2009

    Ah, now I see where @{=>} comes from. That's on p3 of the xyguide. Hmm, that contradicts what it says later. I'll have to look at the more detailed guide to see what the actual mechanism is for deciding what refers to what. At a guess, the possibilities for "stem" and "tip" have empty intersection so it tests each part to see if it is a "stem" character or a "tip" character and assigns it accordingly. So "stem tip" becomes "{} stem tip". I'll have to think how to implement this. It does mean that I would have to be careful if I decided to extend the arrow set.

    • CommentRowNumber15.
    • CommentAuthorTobyBartels
    • CommentTimeJun 17th 2009

    That's interesting about Xy Guide. I'm not sure that you need to recreate all of Xy's behaviour, as long it's well documented how to get results that one wants.

    The double arrow shaft now works for me, and the labels are properly transparent. On the other hand …

    Seeing the label ‘$ f g $’ clearly against the arrow makes me even more sure that they should all be a smidge higher. And the double arrow shaft extends beyond the arrow head (which even Xy does not do perfectly, I admit), and guess what? Between the two shafts, the background is white again! (Although that doesn't look so bad; you can pretend that it's a deliberate part of the style.)

    Also, the shape < (both at the tail and at the head) seems to be anchored at the wrong end.

    • CommentRowNumber16.
    • CommentAuthorAndrew Stacey
    • CommentTimeJun 17th 2009

    I wonder if I can do the double arrow with a mask rather than the TikZ method of multiple overlays. Worth investigating as that would get rid of the background colour issue.

    The arrowheads needs a little thought. One option is to define different arrowheads for each variant of the shaft (at least, one each for single, double, and triple). Alternatively, it may be possible to shift the markers slightly. I'll have to do a bit more reading of the SVG specs to see what's possible there. Nor am I surprised to see that I've gotten the anchor point wrong on one arrowhead! Given how many there are, I'm amazed they all aren't crooked in some fashion.

    Do you think that all the labels should be shifted up, or is it just on letters like 'f' and 'g'? If the latter then that'll get fixed when I add the depth routine properly. The former just needs a fudgefactor adding to the label positions, or maybe some padding around the label (since part of the xymatrix syntax allows for adjusting this padding, presumably it's a good idea to put some in somewhere).

    And I just remembered that the labels on the arrows ought to be in script style.

    • CommentRowNumber17.
    • CommentAuthorTobyBartels
    • CommentTimeJun 17th 2009

    Do you think that all the labels should be shifted up, or is it just on letters like 'f' and 'g'?

    It's most noticeable for them, but my opinion is that should all be shifted. But perhaps I should wait until you do the depth routine and then look again. (It's not really important either way.)

    And I just remembered that the labels on the arrows ought to be in script style.

    Actually, I often tell Xy to override that default; they're easier to read in textstyle, as long as there's room for that. But if you add support for \textstyle etc, then I don't really care what the default is.

    • CommentRowNumber18.
    • CommentAuthorAndrew Stacey
    • CommentTimeJun 18th 2009

    Okay, arrowheads much much better. The lines don't overrun the arrowheads and take a look at what happens in the middle!

    Here's one to try:

    \[
\xymatrix{
A \ar@3{{o}{-{//}-}{o}}[d] \ar@/^2ex/@3{>{-{o}-}{>>}}[r] &
B \ar@{{}{--}>}[d] \\
C &
D
}
\]

    Adding support for label and node styles will be easy (but haven't done it yet). I need to work on the size algorithm next.

    • CommentRowNumber19.
    • CommentAuthorTobyBartels
    • CommentTimeJun 18th 2009

    Ah yes, that's very nice. I haven't run it through anything new yet, but right now I have nothing to report!

    • CommentRowNumber20.
    • CommentAuthorTobyBartels
    • CommentTimeJun 19th 2009

    After reading your documentation, I found another error: it doesn't handle quotation marks correctly! (^_^)

    • CommentRowNumber21.
    • CommentAuthorAndrew Stacey
    • CommentTimeJun 19th 2009

    There's no pleasing some people!

    There's quite a large subset of what ought to be in it that isn't yet (like quotation marks). I thought I'd concentrate on SVGs first since that is the raison d'etre for this program. One of my reasons for making an early version public was to see what order to implement stuff in - stuff that people complained about would be highest priority.

    • CommentRowNumber22.
    • CommentAuthorBruce
    • CommentTimeJul 26th 2009
    Congratulations Andrew! This is very impressive.
    • CommentRowNumber23.
    • CommentAuthorAndrew Stacey
    • CommentTimeJul 29th 2009

    Thanks.

    Long way from usable, though. Needs extensive testing and some of the routines (particularly estimating the size of the nodes and labels) aren't finished yet. Any help would be appreciated!

    Time, time, time ...

    • CommentRowNumber24.
    • CommentAuthorzskoda
    • CommentTimeAug 3rd 2009
    For http://www.math.ntnu.no/~stacey/PHPLaTeX I get the denial message (while simultaneously logged here) what was not the case before.
    • CommentRowNumber25.
    • CommentAuthorTobyBartels
    • CommentTimeAug 3rd 2009

    It works for me now. Was it down for a bit?

    • CommentRowNumber26.
    • CommentAuthorzskoda
    • CommentTimeAug 7th 2009
    It persists on internet explorer on my new installed desktop (though it worked weeks ago on old desktop and on mozzila on my laptop).
    • CommentRowNumber27.
    • CommentAuthorAndrew Stacey
    • CommentTimeAug 10th 2009

    There's no cookies and no logins in the PHPLaTeX set up so being logged on anywhere shouldn't make any difference to what you get. Can you send me (or post) the exact error message? I know that there's a stylesheet that causes problems on Macs, maybe it does for IE as well.

    • CommentRowNumber28.
    • CommentAuthorMike Shulman
    • CommentTimeOct 8th 2009

    Right now, in firefox/ubuntu the PHPLaTeX page gives me the error

    Error loading stylesheet: An unknown error has occurred (805303f4)
    http://www.w3.org/Math/XSL/mathml.xsl

    It works in epiphany, though, so I'm puzzled about what's wrong. Any ideas?

    • CommentRowNumber29.
    • CommentAuthorAndrew Stacey
    • CommentTimeOct 8th 2009

    The external dependence on stylesheets causes a problem for a few browsers (namely, they don't like it when a stylesheet isn't on the same server as the page). I was thinking about making it all local when I got distracted off this project. It shouldn't take long to fix so I'll take another look and report back here when it's done.

    • CommentRowNumber30.
    • CommentAuthorUrs
    • CommentTimeOct 8th 2009
    This comment is invalid XHTML+MathML+SVG; displaying source. <div> <blockquote> It shouldn't take long to fix so I'll take another look and report back here when it's done. </blockquote> <p>Andrew, you're great, seriously. We should pay you. :-)</p> </div>
    • CommentRowNumber31.
    • CommentAuthorTobyBartels
    • CommentTimeOct 8th 2009

    As I recall, Andrew is the only one paying, for the hosting. You should tell me when and where you want money, Andrew!

    • CommentRowNumber32.
    • CommentAuthorUrs
    • CommentTimeOct 8th 2009

    Yes, isn't that great. He is the only one working and the only one paying! ;-)

    Seriously, Toby is right: Andrew, let us know how we can donate our share.

    • CommentRowNumber33.
    • CommentAuthorAndrew Stacey
    • CommentTimeOct 8th 2009

    I need to dig out my paypal account, that's all. Once I can find that, we can pay for the hosting out of it and anyone who wants to contribute can pay me via that, then I only need to top it up. The only thing is that I set up my paypal account before moving to Norway so the password could be in one of several places. Now, where's that spade ...

    • CommentRowNumber34.
    • CommentAuthorAndrew Stacey
    • CommentTimeOct 8th 2009

    Back on topic, I've downloaded the stylesheets from w3c and put them in the base directory of PHPLaTeX. Hopefully, that's fixed that problem and it's usable again. It works on my machine (though I should point out that the machine it works on is not the host machine so working here should mean that it works on firefox anywhere. Slightly better than "it works on my machine" but still in the spirit of that certification program, I deem!)

    • CommentRowNumber35.
    • CommentAuthorUrs
    • CommentTimeOct 8th 2009

    Yeah, passwords, it's a pain.

    • CommentRowNumber36.
    • CommentAuthorjcmckeown
    • CommentTimeJan 11th 2011

    as it happens,

    \[  
\xymatrix{  
A_{} \ar[d]\ar[dr]\ar[drr] & \\  
A_0 & A_1 \ar[l] & A_2\ar[l]\cdots  
}  
\]

    comes out looking funny for me. maybe this is a known featug?

    Out of curiosity, how vital are those body and div tags inside your foreignObjects? when I hand-edit them out, the result looks in my instiki-at-home the same as with those tags in your demo.

    • CommentRowNumber37.
    • CommentAuthorAndrew Stacey
    • CommentTimeJan 11th 2011

    Oof! I haven’t looked at this script for a long time.

    When I wrote it, it wasn’t clear how to embed MathML into SVG on the wiki. Since I wrote it, Jacques has fixed that issue and chose a different (and more correct!) route than I did. So my script should be altered to conform to that choice (meaning: get rid of the body and div tags as you say). Also, the intention was never to produce a polished article, but something that would set out the framework to be further tweaked to get it to look correct.

    Lastly, the TeX->SVG conversion for TikZ has come on a long way and I’m using that these days.

1 to 37 of 37

  1.