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 comma 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 finite 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 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 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).
    • CommentRowNumber1.
    • CommentAuthorBruce
    • CommentTimeMay 16th 2009
    Right now I'm thinking that it would be better for us to change strategy: instead of trying to get a working TikZ system for the nLab via Tex4ht, we should instead just start coding in basic TikZ commands directly into itex2mml. This approach has numerous advantages:

    1. It doesn't require a TeX system on the server. This means (a) it will be much faster and (b) it will be portable, so we would probably gain the support of Jacques.

    2. We can start implementing things right away, starting with the "draw" command. We can setup the nLab to run the current working version of itex2mml.

    The disadvantages are:

    1. We have to start coding things into itex2mml.

    2. It is unlikely we'd ever get all of TikZ to be exportable to SVG (we'd probably get less out than we could with Tex4ht). I doubt SVG is up to the task, from what I've seen of it (how could the web designers ever expect such a crappy format to take off?? ). Tex4ht could do more since all it has to do is transform low-level commands in the dvi file into svg, which can always in principle be done. I am talking about "removing the bottom man" and coding directly from high-level into medium-level (i.e. directly from TikZ to SVG without going down to pgf or dvi first).
    • CommentRowNumber2.
    • CommentAuthorMike Shulman
    • CommentTimeMay 16th 2009

    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.

    • CommentRowNumber3.
    • CommentAuthorBruce
    • CommentTimeMay 16th 2009
    Well, I am thinking that to draw some basic diagrams, all you need is some straight/curved lines, arrows, and double lines, and the ability to put text labels on these. In the beginning at least (before one starts having matrices, etc.).

    I'm envisaging someone drawing a commutative diagram in a reasonably low-level way as:

    \begin{tikzpicture}
    \draw[->] (0,0) node{$A$};
    \draw[->] (0,0)--(10,0) node{$B$}
    \draw[->] (0,0)--(0,-10) node{$C$}
    \draw[->] (-10, 0)--(-10, 10) node {$D$}
    \end{tikzpicture}

    Support for labels as well, of course (I'm still a novice at TikZ).

    I think these sort of low-level TikZ commands can easily be put into itex2mml. That at least gives you some basic graphics capability with very little effort. And support for further TikZ commands can be added in incrementally, similar to the way support for AmsTeX was added in incrementally to itex2mml.
    • CommentRowNumber4.
    • CommentAuthorBruce
    • CommentTimeMay 19th 2009
    I have been discussing this issue with Jacques Distler. Comments / profound criticism needed.
    • CommentRowNumber5.
    • CommentAuthorAndrew Stacey
    • CommentTimeMay 19th 2009

    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.

    • CommentRowNumber6.
    • CommentAuthorMike Shulman
    • CommentTimeMay 20th 2009

    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?

    • CommentRowNumber7.
    • CommentAuthorAndrew Stacey
    • CommentTimeMay 20th 2009

    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?

    • CommentRowNumber8.
    • CommentAuthorMike Shulman
    • CommentTimeMay 21st 2009

    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?).

    • CommentRowNumber9.
    • CommentAuthorBruce
    • CommentTimeMay 22nd 2009
    WANTED: Two weeks of a computer-savvy mathematician's time to revolutionize the future of mathematics (not to mention science) on the web.
    CONTEXT: By my guesstimates, the nLab has now developed into the largest collection of MathML on the web. It looks and works great (at least if you tweak the fonts like I do and skip the crappy Stix fonts, use Georgia instead). By Jacques' great work in creating Instiki and itex2mml, we are now at the cutting edge. The web designers are looking to us. We have to take the bull by the horns. We need to follow Knuth's example. If we sort this thing out we could seriously change the future. I hope you guys realize this: we aren't a bunch of insignificant people on the sidelines who are unlikely ever to change anything.
    • CommentRowNumber10.
    • CommentAuthorBruce
    • CommentTimeMay 22nd 2009
    By the way, I found out in the talk Jacques gave last year about mathematics on the web, that the only reason he got involved in this web-mathematics stuff is because he injured his arm and couldn't write for some time (but he could type). Maybe I can phone up the Chicago or Trondheim mafia and arrange for a little accident?
    • CommentRowNumber11.
    • CommentAuthorMike Shulman
    • CommentTimeMay 22nd 2009

    By my guesstimates, the nLab has now developed into the largest collection of MathML on the web.

    Really? What are you basing that on?

    • CommentRowNumber12.
    • CommentAuthorAndrew Stacey
    • CommentTimeMay 22nd 2009

    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.

    • CommentRowNumber13.
    • CommentAuthorAndrew Stacey
    • CommentTimeMay 22nd 2009

    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?

    • CommentRowNumber14.
    • CommentAuthorBruce
    • CommentTimeMay 22nd 2009
    About that double stranded arrow: in the manual there is a \draw[double, -implies] option for drawing those things. But I admit I haven't got it to work. Maybe I have an old version? We would also like a \draw[triple] and so on...
    • CommentRowNumber15.
    • CommentAuthorBruce
    • CommentTimeMay 22nd 2009
    Mike asked:

    Really? What are you basing that on?

    Nothing, just a hunch. Could be wrong. I'd be surprised. No-one uses these technologies (MathML and SVG). My reasoning is: if you're going to be outputting a lot of MathML, you're probably going to be writing in TeX. Otherwise you're not serious enough about math to be outputting a lot of MathML. 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). Therefore you'd be in "Jacques' universe". And the impression I got from his talk is that his blog, and the n-category cafe (and therefore I assume also the nLab, which has more pages) represent the biggest collection of MathML out there at the moment.

    Each of these are just hunches.
    • CommentRowNumber16.
    • CommentAuthorBruce
    • CommentTimeMay 22nd 2009
    Andrew wrote:

    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.

    ---
    Do you envisage a kind of tex4ht system, or a from-the-ground-up system, or something else?
    • CommentRowNumber17.
    • CommentAuthorMike Shulman
    • CommentTimeMay 22nd 2009

    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.

    • CommentRowNumber18.
    • CommentAuthorMike Shulman
    • CommentTimeMay 22nd 2009

    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.

    • CommentRowNumber19.
    • CommentAuthorMike Shulman
    • CommentTimeMay 22nd 2009

    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.

    • CommentRowNumber20.
    • CommentAuthorAndrew Stacey
    • CommentTimeMay 22nd 2009

    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?

    • CommentRowNumber21.
    • CommentAuthorMike Shulman
    • CommentTimeMay 22nd 2009

    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.