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 bundles calculus categorical categories category category-theory chern-weil-theory cohesion cohesive-homotopy-type-theory cohomology colimits combinatorics complex-geometry computable-mathematics computer-science constructive cosmology definitions deformation-theory descent diagrams differential differential-cohomology differential-equations differential-geometry digraphs duality elliptic-cohomology enriched fibration 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 kan lie-theory limit 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 newpage nlab nonassociative noncommutative noncommutative-geometry number-theory object 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 string string-theory subobject superalgebra supergeometry svg symplectic-geometry synthetic-differential-geometry terminology theory topology topos topos-theory 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.
    • CommentAuthorMike Shulman
    • CommentTimeOct 8th 2009

    Until the magical day when itex has a syntax that can output SVG, is there a nice easy way to generate images for diagrams etc. that we can suggest to people? What method do people use who do this? One I've found is textogif but maybe there's a better one?

    Another thought: what if we set up a little CGI script or something on the nlab server which would take as input some xypic code and output an image (using textogif or some such)? That would lower the bar for people to contribute; I've had a couple people tell me they'd be happier about writing on the nlab if it were easier to make diagrams. Probably taking code from a webform and running tex on it directly would be a security risk, but maybe it could be sanitized somehow.

    • CommentRowNumber2.
    • CommentAuthorAndrew Stacey
    • CommentTimeOct 8th 2009

    This is what I was aiming for with PHPLaTeX, but interest seemed to wane a little and I got busy with the n-lab migration. It needs a couple of minor tweaks: the width calculation routine needs finishing, and the n-lab SVG sanitiser needs to allow certain tags in the foreignObject field.

    If this really is a stumbling block for people then I could prioritise it.

    • CommentRowNumber3.
    • CommentAuthorMike Shulman
    • CommentTimeOct 8th 2009

    I was thinking of PHPLaTeX as closer to the magical day, and since it seemed to have stalled for various reasons, I was proposing a stopgap that I thought would be easier and quicker. But if it wouldn't take a lot of work to make PHPLaTeX usable, that would be really awesome! It might even bring us to the magical day, if we could just make Instiki recognize a syntax denoting a block that it should pass to PHPLaTeX (presumably cacheing the result).

    • CommentRowNumber4.
    • CommentAuthorAndrew Stacey
    • CommentTimeOct 8th 2009

    PHPLaTeX isn't going to be the magical day that you have in mind whereby you can type xy-syntax straight into Instiki. A) it's written in PHP, not ruby and B) it's too slow. My vision for PHPLaTeX is to use that to generate the SVG then cut-and-paste the SVG into Instiki. As this is a once-only process, it doesn't matter that PHPLaTeX is reasonably slow. So I think it is more like the stop-gap approach.

    Taking code from a webform and runing TeX on it is what all the other versions do. That's how LaTeX works here, for example, and on wordpress and other blogs. They do cache the results which is why they can get away with it (imagine having to run TeX every single time!). Urs managed to put a diagram in the n-lab using codecogs this way (that caused an issue or two with the migration but we fixed that).

    So I see codecogs or whatever as the immediate stop-gap. PHPLaTeX (or something) as a midterm solution, and integration as the best solution. However, that best solution is going to take considerable work since SVG and MathML don't really play together all that well at the moment so any solution is not optimal. I get the feeling that Jacques would rather wait until SVG and MathML are truly integrated before figuring out the best way to put them into itex2MML.

    I'd rather that even in the mid-term, an n-lab page should not have external dependencies. So sending diagrams off to some external site is suboptimal, in my view. SVG is my preferred solution, however it's generated.

    • CommentRowNumber5.
    • CommentAuthorTobyBartels
    • CommentTimeOct 8th 2009
    • CommentRowNumber6.
    • CommentAuthorMike Shulman
    • CommentTimeOct 8th 2009

    Why couldn't instiki cache the output of PHPLaTeX the same way that other places cache the output of TeX? Then its speed wouldn't matter except when saving.

    Also, if we generate an image with codecogs or whatever (which unfortunately doesn't seem to have the 2cell option given to XY) and then upload that image to the nlab, that doesn't seem to be an external dependency any more; is there a problem with that?

    • CommentRowNumber7.
    • CommentAuthorAndrew Stacey
    • CommentTimeOct 9th 2009

    Yes, I guess caching would solve that problem. And uploading an image generated by codecogs, or wherever, would also solve that problem. But if you're going to generate it via codecogs, why not just generate it on your own system? Then you can use whatever you like. Someone who actually does this (p_l_lumsdaine, perhaps) should put instructions for generating a picture from LaTeX source on the HowTo.

    • CommentRowNumber8.
    • CommentAuthorMike Shulman
    • CommentTimeOct 9th 2009

    I'm happy generating images on my own system, but I think codecogs might be easier for people who are less willing or able than I am to figure out how to do that. That said, textogif is fairly straightforward.