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.
I think it's time to sum up our discussions on graphics in Instiki. I'm getting a little lost as to what we're aiming for.
MathML+SVG is not ideally implemented yet so any method that produces mixed diagrams (i.e. graphics and text) is going to be imperfect and the resulting diagrams will need tweaking.
Drawing diagrams in (La)TeX is not a simple affair and the packages that do so are extremely complicated (under the hood/bonnet). Jacques is, understandably, reluctant to implement a hack in itex but is similarly reluctant to implement the whole machinery.
On the other hand, he is willing (may already have done so) to implement a system that allows for alternatives: a picture for the screen and another for the LaTeX output. Indeed, this is already in place if the LaTeX picture is a PDF.
So we need converters. Inkscape will export TikZ so one can convert from SVG to TikZ. I don't know how "nice" the resulting TikZ is, though.
On the other hand, the best bet for TikZ to SVG is TeX4ht and this results in fairly horrendous SVG.
When putting diagrams into Instiki, due to the poor interaction of MathML and SVG then one oughtn't to stack thinks too deeply. It's reasonable to have MathML embedded in SVG or vice versa, but to have MathML embedded in SVG embedded in MathML is asking for trouble. Since the worst seems to be MathML in SVG (for visual reasons rather than technical), it's best to have only simple mathematics embedded in a diagram (probably a good guideline anyway).
Big diagrams can be put on separate pages and included in, but there is potential for reuse within the page so small diagrams should stay inline. Well-formed SVG is more compact than MathML so although the raw syntax looks a little out of place, it's not so bad.
<div>
I have a comment on just one of these points; otherwise I agree.<p><blockquote>Big diagrams can be put on separate pages and included in, but there is potential for reuse within the page so small diagrams should stay inline. Well-formed SVG is more compact than MathML so although the raw syntax looks a little out of place, it's not so bad.</blockquote>If the reuse is the reuse of the entire diagram, then having it on a separate page and included in actually makes reuse easier. I guess that you mean reuse with variations, where we want it to be easy for people to get at the code. That makes sense, but I'm not sure that I've actually seen well-formed SVG that features compact code; certainly the SVG in the Lab now is huge compared to anything written there in iTeX.</p>
</div>
Toby, with the unerring discerning eye of a referee you have found the one part where I was a bit vague because I didn't really understand what I was saying! The "reuse" I referred to is not manual reuse of code but some sort of reuse by SVG that means that the server doesn't have to send so much data to the client. I don't really understand it - I haven't looked at the syntax of SVG to know what it's about. Also, having diagrams inline saves a little server overhead. I've no idea how much or whether it's worth it, but given the current state of the server then saving it whatever we can may not be a bad thing!
Urs, if you put an SVG into Instiki then when you export the page as LaTeX then the picture disappears. That's because LaTeX can't handle SVG so \begin{svg} ... \end{svg} ends up getting gobbled up by the export handler. To get round this, there's the command \includegraphics{file} which does get exported. On the web then \includegraphics{file} does nothing. So when you put an SVG on Instiki then you ought also to upload a corresponding PDF and make sure that you write something like:
\begin{svg}
...
\end{svg}
\includegraphics{picture}
to ensure that both the screen and print look right.
Some of us are arguing that this ought to be replaced by a single system so that one could just write
\begin{tikzpicture}
...
\end{tikzpicture}
and Instiki would generate the SVG for the web and the TikZ code would survive onto the paper. Others of us are thinking more along the lines of a double system like the current but where instead of \includegraphics{file} one has
\begin{svg}
...
\end{svg}
\begin{tikzpicture}
...
\end{tikzpicture}
I'm in the latter group as although the former would be ideal, I don't think that it is yet realisable.
This shifts the issue to generation of the code so that you don't have to make the same diagram twice. I'm working on this and will hopefully have a prototype for testing soon.
Found it (I think):
5.6 The 'use' element
Any 'svg', 'symbol', 'g', graphics element or other 'use' is potentially a template object that can be re-used (i.e., "instanced") in the SVG document via a 'use' element. The 'use' element references another element and indicates that the graphical contents of that element is included/drawn at that given point in the document.
I'm getting a clearer picture of how it works. When you define, say, an arrowhead, then you want to reuse it lots. All the pictures on a page can use the same definitions, but I don't think that inclusions can do so. I think it's a bit like local variables in functions.
<div>
Can you put something on the SVG Sandbox to test this?<p>Even knowing nothing about SVG, I very much doubt that inclusions will have any more difficulty reusing definitions than inline diagrams. The inclusions are handled by the server; what the browser receives is the same either way.<p>(I could easily believe that definitions can't be reused in a separate SVG diagram, but that would be a problem both ways.)</p></p>
</div>
Can you put something on the SVG Sandbox to test this?
Done. And it seems to work as you thought it would. Hmmm.
Also threw up something about what's allowed in SVG in Instiki. My original diagram had MathML embedded in foreignObject tags, but was within div's to get the alignment right. Those divs caused problems with Instiki's parser.
Anyway, that's my excuse for why the diagrams look so rubbish!
And I feel justified in my use of slash names for included SVGs, since it really makes a difference which page they're included on. (Not to suggest that inline code is a bad idea —as long as it's human-readably short!)
Looking a little ahead, we can have a standard SVG style page with a (small) number of predefined objects which can be included in any page that has SVGs on it. I'm thinking at the moment of arrowheads, but other things may be desirable.
Of course, we don't want to send out loads of stuff just for the sake of it, so maybe not one page but a few (a bit like \usepackage{..}) but it would make for a unified look across the 'lab.
1 to 12 of 12