Want to take part in these discussions? Sign in if you have an account, or apply for one below
Vanilla 1.1.10 is a product of Lussumo. More Information: Documentation, Community Support.
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:
So if you write \newcommand{\R}{\mathbb{R}}
then you'll be able to use \R
for 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).
<blockquote>Well, I got it to break.<p >The input<blockqoute ><code >\[ \xymatrix { A \ar [d] _ f \ar [r] ^ g & B \ar [d] ^ h \\ C \ar [r] _ i & 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>
<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 & B \ar [d] ^ h \\ C \ar [r] _ i & 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 <blockquote> tags around!</p>
</div>
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!
Yes, I haven't gotten the labels on the arrows anywhere near correct yet.
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
}
\]
<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>@{=>}</code>, but it was still invisible.</p></p>
</div>
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!)
<svg><blockquote >Lastly, <code >@{=>}</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 >@{==>}</code> or <code >@{{}=>}</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 ></mrow><br>--^</code></blockquote></p></p>
<code>
means, does it? I might add that it put one of its unnecessary </p>
tags in the wrong place too.)
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.)
Okay, hole punch implemented! Try the All-New \ar[r]|f
.
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.
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.
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.
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.
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.
Ah yes, that's very nice. I haven't run it through anything new yet, but right now I have nothing to report!
After reading your documentation, I found another error: it doesn't handle quotation marks correctly! (^_^)
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.
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 ...
It works for me now. Was it down for a bit?
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.
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?
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.
<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>
As I recall, Andrew is the only one paying, for the hosting. You should tell me when and where you want money, Andrew!
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.
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 ...
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!)
Yeah, passwords, it's a pain.
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.
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