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.
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.
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.
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).
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.
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?
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.
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.
1 to 8 of 8