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.
Well, I can't really talk since my preferred approach isn't working yet, but that seems quite backwards to me. Why try to reinvent the wheel by figuring out how to code TikZ into SVG ourselves, rather than making use of the seemingly excellent SVG driver that TikZ/PGF already has? I have a lot of other things to do with my time than figure out how to re-write a parser for the intricate syntax of TikZ; even getting to the point where we could draw simple commutative diagrams seems to me like it would take quite a while.
Also, I don't think that the tex4ht driver for tikz/pgf does go through the dvi file; in fact on my machine pgf doesn't even produce output that can be seen in a dvi file. (I get the impression that is pretty much impossible anyway, in the generality that tikz/pgf works, since DVI is only a format for displaying characters in boxes rather than really drawing.) It has separate drivers to produce PDF and PS output, as well as one for SVG, so it is already going directly from the tikz/pgf code to PDF, PS, or SVG, whatever output you tell it to make.
Bruce, I think you may be missing one of the subtleties regarding diagrams. Jacques wants Instiki to produce stuff that looks good on both screen and page. With normal text, that's not too hard to do without any tweaking. However, with a diagram then there's a inordinate amount of tweaking that goes on to get it looking "just right". That's down to the different ways in which diagrams and text are processed in the brain and, consequently, how they are used in media. We can't avoid this, not that we want to.
So it's not actually clear that we do want a system wherein someone uploads just one version of their diagram and expects the system to handle the conversion. Rather it might be better to have two versions of each diagram, one for screen and one for text.
Of course, we want to find some way to save some labour and producing two near-exact copies of every diagram is a bit of a slog. However, it is possible to design one version (on one's own computer), then export it to the other (still locally), tweak that export ever so slightly to get it to look "right", and then upload both versions.
To do this we need conversion software, but that can be local. The program 'htlatex' does TikZ to SVG but, as Jacques says, extremely badly and that's nothing to do with the text issue (my diagram that started all this has 5 decimal places for precision). On the other side, Inkscape can export TikZ (see www.texamples.net for a list of TikZ-related software). Neither may be perfect, but at least each means that one doesn't have to completely redraw a diagram.
I would like to see a better TikZ->SVG converter, but outside Instiki and the n-Lab. That's because I'm more likely to "program" my pictures using TikZ than try to draw them in Inkscape so I'd rather do the TikZ first and then tweak the SVG afterwards.
As you say in your discussion with Jacques, having the raw SVG can be a bit off-putting. However, maybe a little javascript that can hide the SVG in the text-box might go a long way to overcoming this problem. In fact, one can envision a far more sophisticated text-entry system where one was able to expand and contract parts of the page at a time, but that's another issue and not really relevant here. The point that I do want to make is that I think that SVGs are much less likely to get edited by others anyway. Firstly, people are more likely to have gotten a diagram to look right at the start and secondly, I think that there's a higher barrier to mucking around with someone's picture than someone's text. It's clear in text that the content is more important than the expression but in a diagram then the two are far more intertwined.
with a diagram then there's a inordinate amount of tweaking that goes on to get it looking "just right".
That may be true for general sorts of pictures, but I don't think it is necessarily true for ordinary commutative diagrams. I rarely have to do any tweaking of the commutative diagrams that appear in my papers; I generally write in XYpic but I expect this would be as true with TikZ. I believe commutative diagrams should really be regarded as just a different syntax for the same sort of thing that is being said in equations. As such, I think it would be exceptionally helpful for their code to be easily writeable and editable, without needing to carefully regenerate and upload two copies of something for every small change. Perhaps commutative diagrams are actually fundamentally different from general pictures and deserve to be handled differently?
You may well be right on that last point. How much of your generic commutative diagram can't be handled by an array environment? I know that it doesn't look perfect - the arrows come out a bit on the short side. What extra would you want to see in an implementation of commutative diagrams in itex?
In principle, I suppose any commutative diagram could be handled by an array environment. But, as you say, the arrows come out much too short, with too much spacing between the objects and the arrows. Labels of vertical/diagonal arrows are either too big or badly positioned, and if they are too wide they shift the arrow far out of position. Having to arrange everything in a grid is too restrictive and sometimes forces the spacing to be too big, an especial problem given only very short arrows. The problems are especially acute with diagonal arrows; see for instance the original version of the triangle identities here. In particular, with very short arrows and only eight possible directions of arrows, it gets difficult to make clear exactly what the source and target of each arrow is. For instance, the pentagon identity would be hard to make (as a pentagon), and just contemplate the 5-associahedron. Multiple parallel arrows, such as in a simplicial object, quickly get very messy. I think I would have trouble making the split codescent object here comprehensible with an array. You can't really pass arrows across, over, or under each other, as for instance to make a commutative cube. Finally, it is basically impossible to make curved arrows with an array, which means that the traditional picture of a globular 2-cell appears, so far as I can tell, nowhere on the nLab; the best you can do is draw two straight parallel arrows with an arrow between them, which is difficult (for me) to interpret correctly.
What I'd like to see in an implementation of commutative diagrams is basically the feature set of xypic/xymatrix/diagxy. You can drop an object anywhere you want, and draw an arrow from any object to any other object, with various different sorts of tips, shafts, curves, shifts, and decorations. A more advanced feature would be to draw an arrow from one arrow to another arrow, as we do with 2-cells and higher cells. You can do some of this easily with TikZ, but not all of it; certainly you could do all of it with enough work, but I haven't yet been able to get double-shafted arrows to look acceptable (has someone written a package to do that, maybe?).
By my guesstimates, the nLab has now developed into the largest collection of MathML on the web.
Really? What are you basing that on?
Bruce confessed:
Maybe I can phone up the Chicago or Trondheim mafia and arrange for a little accident?
A-ha! So it was you!
But more to the point, I'm not so sure that we either are or want to be the one's following in Knuth's footsteps. Let's work first on a system that we can use and works for us.
One of the problems with bugging Jacques to modify iTeX is that we are only one of many users of that system. So what's important to us is not necessarily what's important to everyone. Implementing TikZ really means implementing PGF and that sounds like a lot of work.
Even the pervasive xymatrix system is an overlay on top of another engine so putting that in iTeX would also be a lot of work.
However, if we had our own TikZ or xymatrix to SVG converter then we could have a working system that we were in control of so we could just get on with the real work, namely getting the n-Lab looking all nice and shiny.
I have a few ideas as to how to implement this, I'll try to get on with this.
By the way, Mike, I've had a go at a double-stranded arrow and the following seems to work:
\begin{tikzpicture}[auto, scale=2]
\node (A) at (0,0) {$A^2$};
\node (B) at (2,0) {$\int B$};
\node (C) at (1,1) {$\sum_0^\infty C$};
\draw[->] (A) to node[swap] {$\phi$} (B);
\draw[->] (A) to node {$\psi$} (C);
\draw[->] (C) to node {$\theta$} (B);
\draw[->] (1,0.4) to (1,0.3);
\draw[double, shorten >=1pt] (1,0.5) to node {$\mu$} (1,0.3);
\end{tikzpicture}
At least, it looks right on my system (and at high magnification). Is that the sort of thing that you were looking for?
Andrew, your double-shafted arrow isn't too bad, but the shafts are so close together that at normal magnification I can hardly tell there are two of them. Adding double distance=2pt puts the shafts farther apart but now the arrow tip is too small. Adding very thick to the arrow supplying the tip makes the tip the right size, but now it is too thick. Also the white in the middle cuts off rectangularly, rather than molding to the arrow tip, and there is (on my system) a ghostly gray line running across the head of the arrow. Compare with the output of the XY command: \ar@{=>}
double -implies, on the other hand, works just about perfectly (although there is still that ghostly gray line), but appears to only exist in the CVS version of PGF.
Oh, and triple arrows are not so hard once you have double arrows; just draw the double arrow extra wide and then put an extra line in the middle. And n-tuple arrows for n>3 should probably be avoided.
Thus, you'd probably be using itex2mml (I know there are other packages but my impression is that they are not as good by a long way).
Of course, that doesn't mean that people might not be using them anyway. (-: How bad is tex4ht? In theory, it has the advantage that it takes actual TeX code as input, rather than itex code which is not quite the same. That way one could turn an existing TeX document into a webpage with minimal modification.
Ah, well. Thought I'd actually come up with something useful there on the doubled arrows.
Regarding tex4ht versus itex2mml, they are different solutions for different problems. The tex4ht suite is for converting something originally written for paper into something that at least works on the web. Whereas itex2mml is designed to go straight onto the web.
I'm not all that interested in turning an existing TeX document into a webpage with minimal modification. Whenever I've seen webpages like that then I don't really like how they look. I'd much rather see webpages designed to be webpages. Otherwise, why not just put the PDF online?
I'm generally not all that interested in turning existing TeX documents into webpages either. But I can see that some people might be, and the context of the comment was the question of whether there is significant use of MathML outside the itex2mml community.
1 to 21 of 21