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.
Following on from the discussion on the cafe, I've discovered that tikz (a fairly sophisticated LaTeX picture package) can be converted to SVG. Basically, running htlatex (from the TeX4ht package) on a latex document with tikz pictures in produces SVG versions of the pictures. There are a few limitations, mainly to do with text, but it seems to work.
However, including SVGs in Instiki doesn't seem to work exactly. Compare the picture in the sandbox with the original SVG:
For more examples, see the page of my talk on Comparative Smootheology at the Ottawa conference which is here.
The trick, from the pgf manual, is to load the correct output driver before loading the Ti_k_Z package. The line is:
\def\pgfsysdriver{pgfsys-tex4ht.def}
I got this hint originally from someone's user page on Wikipedia, but it's covered fully in the PGF manual.
Cross-posted from the n-Lab: Bruce Bartlett said:
Been a while since I thought about getting a good graphics engine here in inStiki, but these pictures have got me excited again. Right now I am thinking that the following procedure could work well:
You draw a picture using your favourite method (TikZ, Inkscape, etc.)
You export it as an svg file.
You copy and paste this svg text into the nLab page you are editing.
Now you click "Submit" as usual.
Here's the trick: the next time someone clicks "Edit page" in the nLab, the Instiki software is intelligent and displays the SVG text as a javascript "expand box". In other words, there's a little command in the text "Expand SVG code (+)" and if you click the (+), it expands all the code out. If you click "(-)", the code collapses again. This way we don't get large swathes of SVG code cluttering up the text area.
Perhaps the software can be more advanced and remember if someone has altered any of the SVG segments of code. If not, it shouldn't be resubmitted when someone clicks "Submit", otherwise it will make for slow uploads.
One method that would solve a lot of that would be to have the SVGs as external files that are then included at the appropriate point. I don't know whether or not that is possible, though.
Another thing is that exported files can often contain a lot of "junk" (cafeful examination of my picture will reveal that it uses 5 decimal places; perhaps slightly over-accurate). Some way of automatically trimming this down would be helpful.
I think it's okay to add another step into your scheme, between the export and copying into Instiki, but it needs to be an easy one, say a script that modifies things a little to be acceptable to Instiki. However, what that needs to do will only become apparent with a little experimentation.
I found that I couldn't just input the SVG that TikZ+htlatex gave me straight into Instiki. Even if the SVG file displayed correctly by itself then it still wasn't guaranteed to work. What gave me most grief was the text, as Bruce has found out. Basically, text boxes in TikZ (nodes and the like) can be extremely complicated but text in SVG is extremely simple. I think that if you prepare your pictures knowing that you are going to output them to SVG then it should be a little simpler, but I drew my pictures before I knew that one could do SVG (not that that would have made any difference, I drew them for my talk not for Instiki). So I've edited the text by hand in all of them.
If anyone wants some examples to play around with, then there are 9 pictures from my talk in Ottawa available on my webpage here. You can download the source for the pictures, and the resulting SVG. The SVGs have been mildly hacked to get the text right. If you do the 'htlatex' hack and compare the output with the SVG from my webpage then you'll see what I had to do. (Note: before running 'htlatex' on any of the LaTeX files make sure to uncomment the \def\pgfsys line).
However, even that editting is vastly easier than generating the SVG by hand, or even using a "graphical" program to produce it. I'm much more of a "programmer" than a "graphic designer" so I far prefer using something like TikZ than, say, Inkscape or XFig.
I've been emailing Jacques about this a little as well and he seems keen to make it easy to go from LaTeX (TikZ) to Instiki (SVG) so I think it's a Good Time to investigate and try to find out how to make it all work well.
Just a side point, having stumbled upon TikZ (all credit to the SBS boys and girls) then I'm not using xypic again. In fact, I'm thinking of writing a little script that would convert a (simple!) xymatrix diagram into TikZ so that I can convert all my old diagrams into the Brave New Format.
However, it's late Friday evening here and the weekend beckons.
By the way, when experimenting then make sure that the SVG is valid before you try importing it into Instiki. Either load the file up in an SVG-capable browser (Firefox) or something like Inkscape. Firefox is good because it'll tell you where the (first) error is - that's how I found out that the text boxes weren't working well (and remember that in valid XML then all tags have to be either balanced or end with a slash). Doing this saves a lot of time.
Bruce wrote in the sand:
Well, you can certainly upload files here in Instiki, and I think that method would be possible. But then we’re back to the Fundamental Conundrum:
If we’re going to start including files, you might as well export your graphic as a png file and include it the old-fashioned way.
It’s the old problem: SVG and MathML have not been built so that one can use them both simultaneously (I think).
Not necessarily. SVG has some distinct advantages over PNGs, scalability for one, and it's lossless (sort of). Web pages are generally made up of lots of little bits stuck together so putting the SVGs in separate files just to tidy up the content is no great issue.
I also think that SVG and MathML can be used together. Jacques said something about 'foreignObject's in SVG. But as I said above, it's late so I'm not investigating now.
The SVG at, for instance, comma object, was written by hand using foreignObjects to get MathML into it.
I'm not sure what exactly causes all the text in the SVG produced by htlatex to be stacked on top of itself at one spot in the picture, but it seems that it can be avoided by using more basic TikZ syntax rather than the matrix stuff suggested in the commutative diagrams tutorial. For instance, running this through htlatex:
\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.5) to node {$\mu$} (1,0.3);
\end{tikzpicture}
produces an SVG that seems to display fine in firefox and instiki. There is no MathML by default, so that labels including math like $A^2$ or $\sum_0^\infty C$ do not display correctly, but that can then be fixed up by hand: namely, find the <text> tags that contain the labels and replace their contents (usually one or more <tspan>s) by something like
<foreignObject markdown="1" x="-5pt" y="-12pt" width="10pt" height="15pt">$A^2$</foreignObject>
I don't know any automatic way to decide what the x, y, width, and height values should be; it depends on how big the MathML is going to end up. But if we can figure out a way to automate that, then perhaps Jacques can make Instiki read the TikZ code and parse it into this sort of SVG+MathML for the browser. I think that would be the ideal solution: the diagrams would be stored in more or less readable TikZ format in the instiki source and could easily be changed by future editors of the page, without needing to recreate the whole thing.
Apparently if you call xhmlatex instead of htlatex it is supposed to produce MathML from your formulas. The resulting MathML doesn't work for me, though; I'm not sure what's wrong. And it doesn't even try to do anything with formulas inside TikZ pictures.
The version of pgfsys-tex4ht.def that you linked to is the CVS version, the one the developers are currently working on. The claimed mathml support was added after the most recent official release of PGF (version 2.00), which is the version I have installed. Maybe we should try using the CVS version, although doing that with anything always gives me the creeps.
I cannot extract something relevant from your other link, can you explain what you got from it?
By the way, according to the PGF manual, one of the limitations of the pgfsys-tex4ht.def driver is that "Matrices do not work." So I guess that "explains" why we can't get it to work that way. (-:
Hmm, looking at my LaTeX files I see that I'm not even using the most up to date version of PGF, let alone CVS. I have no objection to trying out the CVS - it's probably enough to check out the pgfsys-tex4ht.def file. I suspect that actually one can drop this in to a stable release of PGF. In fact, if you have your own TEXMF tree then TeX searches there first so you can just stick the current version somewhere there and if it doesn't work, delete it and you won't have damaged anything.
By the way, as far as I know Till Tantau has nothing to do with TeX4ht (that is, htlatex). As part of the PGF project he's written a "translator" for how TeX4ht should interpret PGF code. It's that translator that we're mucking about with.
Taking the advice of "walking before running", I think the first "stage" is to figure out a "by hand" method for producing SVG that is acceptable for Instiki from suitable input. For diagrams designed specifically for inclusion in an Instiki installation, this should go something like:
Diagrams, such as xy stuff, that weren't drawn explicitly for inclusion may need a little pre-processing (say, to convert to TikZ as I suggested above) and a little more post-processing.
My point is, before we think about automating all this we need to establish exactly what it is we want to automate. Also, automation may not be a desirable goal. As nice as it may be to think that you can take a paper and just stuff it in to Instiki and it will look "okay", we should expect to do a little adjustment to get things to look right. Paper and screen are different media, after all, and what looks right on one may not look right on the other (I'm counting PDF as "paper" here; the point being that it is static whereas screen display can be more interactive).
Lest that sound too cautionary, let me say "well done" for tracking down stuff like the modified pgfsys file!
I definitely agree that we should not expect to be able to just stuff ordinary latex into instiki. As I said before, I think the ideal setup would be something like the current setup with itex in instiki: there is a human-readable and -writable syntax for creating pictures and diagrams, which is at least close to a standard latex syntax, which is automatically processed to produce portable output (SVG and/or MathML) viewable in a browser. But the source code of the page remains in the human-read-write-able syntax (presumably TikZ or like it), so that subsequent people editing the page can modify it without having to recreate it entirely. That's the level of automation I would like; I wouldn't be bothered if the syntax is a bit different from standard latex. I think this would be a significant advantage over attaching files (either images or SVG) or including raw SVG in the page, even if we have a (semi-)automated way to produce SVG from latex, since generated SVG is not very human-read-write-able. Do other people have different thoughts about what the ideal setup would be?
I think I have already proposed a "by hand" method for producing instiki-acceptable SVG. It goes as you suggest, with the "minor post-processing" being replacement of the <tspan> tags for text by <foreignObject> ones containing the actual math. A sample result can be seen at the bottom of the SVG Sandbox page.
I guess there are sort of two approaches one could take. One would be to try to use the MathML translation in htlatex to insert the math in the right place in the SVG. The other is to use itex2MML, which is the approach I used. At present, itex2MML appears to me to be more promising; I currently can't get htlatex to output MathML that my firefox can understand.
Has anyone been able to get TikZ to make an acceptable-looking double-shafted arrow (for a 2-cell)? Its "double lines" appear to be produced using a hack that breaks arrowheads.
Ok, never mind my complaints about the MathML produced by xhmlatex. It wasn't displaying correctly in my firefox because xhmlatex by default produces an .html file, but firefox won't display MathML correctly unless it is in XHTML mode. Changing the extension of the xhmlatex output to .xhtml fixed the problem.
Putting the CVS version of pgf in my ~/texmf, by which I mean checking it out and then copying the contents of generic/pgf to ~/texmf/tex/generic/pgf, causes htlatex to complain:
! Undefined control sequence.
\pgfsys@endpicture ->\HtmlParOn \Par
l.15 \end{tikzpicture}
I don't understand why it is complaining, since \HtmlParOn is a perfectly good command defined by tex4ht. Any ideas?
It looks like the support for generating MathML in SVG in the pgf tex4ht driver was added after Olivier Binda's email, and quite possibly he was the one who added it, see this followup.
Also, it looks as though his comment was about producing valid xhtml by not including <p> tags inside foreign elements, whereas my error is about htlatex not even compiling the code.
The CVS version of the PGF manual suggests that you need to add the
option tex4ht node/escape=true in order to activate the escape to
foreignObjects. Adding this to my code produces the error
Runaway argument?
{\EndDviMath \ShowPar
! Paragraph ended before \c:$$: was complete.
<to be read again>
\par
l.8 \node[tex4ht node/escape=true]
(A) at (0,0) {$A^2$};
In addition to the same "Undefined control sequence" error I got before. What exactly did you ask Olivier Binda? Did you mention my error?
I've created a new category on the forum: diagrams; and I've shifted this discussion into it. Please feel free to start a new discussion in that category if you feel that it is warranted. In fact, if you're not sure whether to add to an old discussion or start a new one, then I'd say start a new one. It's much easier to quickly scan through a lot of discussion titles than search through long lists of comments.
For example, it might be useful to gather all the stuff relevant to the pgfsys-tex4ht.def file in one place, and separate out the "post-processing" into another thread.
Unlike Bruce, I don't think that we're within an epsilon of solving this and so keeping the discussion easy to scan through will help.
Yes, Instiki does have a method to include files!<p >See <code ><a href="https://ncatlab.org/nlab/show/latest+changes">latest changes</a></code> for a typical example: <code ><a href="https://ncatlab.org/nlab/show/%21include+all+changes">!include all changes</a></code>. Note that <code ><a href="https://ncatlab.org/nlab/show/all+changes">all changes</a></code> has the code for shifting the thing to the right; <code ><a href="https://ncatlab.org/nlab/show/%21include+%3C%2Fcode%3E%E2%80%A6%3Ccode+%3E">!include </code>…<code ></a></code> is a pure inclusion.</p>
Bruce, how do I get those files from the SVG Sandbox? It looks like a "create page" link to me and when I click on it then I get an error. If it's not easy to upload them, could you email them to me? I can stick them somewhere here and provide a link on this forum.
(I presume that Olivier is happy for you to redistribute his files ...)
Toby, I like the include idea. Can you write up what you did? Most logical place is the HowTo on the n-Lab but if you feel that it's just a step on the way rather than part of the Proper Way of Doing Things then put it here for us to try out (start a new discussion in the "diagram" category).
<div>
@ Bruce:<p>I would leave off the <code>.svg</code> in the page name, since in principle we might choose to replace it with something other than SVG without editing the page that it appears in.<p>There's also an argument to be made that the including page's name shouldn't appear in the included page's name, since the latter might be included in more (or fewer) than one page at any given time. But conversely, if this is a step towards including TikZ code directly into the page, then it might be better to use page names that reflect that intent.</p></p>
</div>
When linking to a file in Instiki, remember to use <code ><a href="https://ncatlab.org/nlab/show/%3C%2Fcode%3E%E2%80%A6%3Ccode+%3E%3Afile"></code>…<code >:file</a></code>. Unfortunately, now I am getting application errors.
:file! (Or when I try to go directly to http://ncatlab.org/nlab/files/LD@Svg@Tests_files.zip, where it ought to be.) Very annoying …
If we're shifting the SVGs off the main pages (which I think is a very good idea) then we should have something on those main pages which links to the included page, a bit like the "edit sidebar" link on the table of contents. Obviously this shouldn't be part of the diagram itself but maybe a list of includes right at the bottom of the page.
Looking at the diagram on the adjunction page I can see why it's best not to mix MathML and SVG too much.
By the way, including just SVGs breaks the TeX export. You need to upload a PDF as well and put an \includegraphics{file} after the \end{svg}. Take a look at Jacques' page on this for details.
By the way, including just SVGs breaks the TeX export.
Another good reason to aim for being able to put TikZ in the source, rather than raw SVG. I haven't had time to work on this for a bit but I hope to soon.
I think the adjunction diagrams would look better if the whole thing were in SVG, rather than just the loopy arrows around the outside.
1 to 38 of 38