Sandbox > SVG

What this page is for

What this page is for

This Sandbox is specifically for mucking about with SVGs. The point is that these pictures can get rather large (particularly if automatically generated - does anyone write their own?). A Sandbox, such as this one is for trying things out. Usually those are little things, such as getting the correct syntax for something, so if the Sandbox gets really big and takes ages to load and resubmit, it gets difficult to try out lots of little changes. One SVG, such as my original one, can easily swamp the ‘box. However, as I’ve found out, getting SVGs to work in Instiki can take a little tweaking so this ‘box is for that.

One shouldn’t leave an SVG here for long. I don’t think that there’s much to be learnt from looking through someone else’s SVG code (unlike in the original Sandbox where it can be useful to scan through and see how something is done). Rather, you should muck about with your SVG, get it right, and then transfer it across to the requisite page.

A reasonable rule would be that the author should delete it when they are finished with it, and that the maximum lifespan of a picture here is, say, 1 week. To make this easier to police, please timestamp your SVGs.

Obviously as we play with these then we’ll learn various strategies. These should be added to the FAQ or HowTo pages as appropriate. Maybe we should have a list of SVGs in the n-Lab so that people can find examples of what can be done and how to do it, this could be commented with what has had to be done to get it to work in Instiki. If someone has a particularly nice example, or one they’re particularly proud of, but doesn’t really fit into an “honest” page on the n-Lab then may I suggest they put it on their userpage (I’ll probably do that with the “map of manifolds” one since it doesn’t really fit anywhere else).

Original import from the Sandbox

Testing tikzpicture to svg capability.

Timestamp: 2009-05-08

(removed; see revision 10)

Not bad! Thanks to Jacques, the sphere is fine now. This picture is probably a little too big to leave in the sandbox so I’ll remove it soon - just want to show off a little first! For the original, see Comparative Smootheology at Ottawa.

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.

Bruce Bartlett

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.

Andrew Stacey

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

Bruce Bartlett

Doing a quick LaTeX -> Inkscape -> SVG -> nLab test Bruce Bartlett:

Timestamp: 2009-05-08

(removed; see revision 10)

As you can see, the trouble with this method is that Inkscape is exporting the text as spline primitives… which takes up way too much space. I guess that just returns to the old problem: you can’t mix MathML and SVG. Now I remember (I knew there was some kind of nasty problem with this MathML, SVG and Instiki thing… and now I remember). Bruce Bartlett

Ok, I’m giving it another go. Now I’m trying Andrew’s method — you do a diagram:

(removed; see revision 10)

Mike: Here is a little diagram produced from the following TikZ code:

<svg xmlns="" xmlns:xlink="" width="134.177pt" height="81.21pt" viewBox="0 0 134.177 81.21" version="1.1">

run through htlatex, and with the <tspan>s then manually replaced by the appropriate foreignObject tags:

(removed; see revision 10)

Bruce : Hey, this is great Mike! For anyone reading this thread, who wants to contribute, don’t forget about the nForum page where we are discussing this stuff.

Toby: Here's the diagram again, but without the SVG code in the edit box, thanks to the magic of inclusions!

A 2 A^2 B \int B 0 C \sum_0^\infty C ϕ \phi ψ \psi θ \theta μ \mu A B C D f g h k

(This is included from the new Inclusion Sandbox.)

Bruce: The files I received from Olivier Binda, which includes a nice comprehensive test suite of how his patch to htlatex (which changes ordinary text in SVG into foreignobject tags) performs, are available here:

These three diagrams are testing re-use of SVG code. The arrowheads are reused from diagram to diagram. The first picture defines the arrowhead once and then reuses it for each of the arrows. The second picture does not define the arrowhead so must get it from the first picture. The third picture also does not define the arrowhead but refers to the arrowhead from the picture in the Inclusion Sandbox. As can be seen, it works. One thing to test would be to have different arrowheads here and in the Inclusion Sandbox but with the same name and see which one gets used (my guess would be the definition closest above where it is used).

(removed; see revision 12)

Given that inclusions and references seem to work fine, it seems a reasonable idea to have a list of “standard” arrowheads. Here’s one such, loosely based on the types of arrowhead that the xy package considers as standard.

Date stamp: 5th June 2009
filledArrow basicArrow doubleArrow barArrow bardoubleArrow parenthesisArrow reversebasicArrow reversedoubleArrow reversebarArrow reversebardoubleArrow reverseparenthesisArrow slashArrow doubleslashArrow crossArrow plusArrow vbarArrow doublevbarArrow circleArrow

What do people think? Are there others that ought to be considered as “standard”? Are these okay, or do they need tweaking?

Discussion on the n-Forum.

And just for Toby and Mike:

𝔄 𝔅 \mathfrak{A} \begin{svg} <svg xmlns="" version="1.1" width="70" height="20"> <path d="M 5 10 L 35 10 L 65 10" marker-mid="url(#vbarArrow)" marker-end="url(#basicArrow)" stroke="black" stroke-width="1" /> </svg> \end{svg} \mathfrak{B}

Layer 1 A B C D f k g h

Here’s an SVG from Inkscape:


Now here’s the same, saved with “Optimised SVG”:


Now here’s the same, but with the latest version of the plugin from scour installed:


Finally, here’s the same but run through the command-line version of scour:

category: meta

Last revised on October 5, 2018 at 07:22:06. See the history of this page for a list of all contributions to it.