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.
Igor Khavkine is having problems with included svg-graphics not discplaying at reductions deformations resolutions in physics.
Can anyone help? Does it only work if one includes the svg-source code directly?
Yes, SVGs have to be inline. This is actually a browser thing, not an Instiki thing. For some strange reason, Firefox doesn’t allow SVGs as an “image” format, only as an embedded format. I don’t know about other browsers, but certainly some are behind FF in SVG support (I think Opera is better for SVGs, but it’s worse for MathML sadly).
Thanks, Andrew.
So Igor has now made the SVG source code be included directly. There is still a problem, though:
the code being included is apparently not quite the code in the inclusion file. For instance currently it strips off all the code for arrow heads.
Do you know what causes this and what might fix it?
Bleugh. Normally I’ll not hear any complaints against my beloved SVG, but this time I have to admit that the peculiarities of it are a little irritating.
SVG comes in many shapes and forms: being an XML dialect, it can itself be further refined. So editors such as Inkscape can add their own extensions to basic SVG. That’s fine for Inkscape, it’s also fine for stand-alone SVGs, but it makes them potentially non-compliant when included in to other XML documents - in some cases, such as on the nLab, the containing document has to know what dialect of SVG the included file will be. So we accept only ordinary SVG here. Fortunately, decent editors such as Inkscape can export their documents in “Plain SVG”. But of course the first step is knowing that that is what you have to do! So:
Step One: Save your SVGs from Inkscape as “Plain SVG” (but see below …)
Even then, the SVG can contain a lot of crud. Also, there are often different ways of specifying the same information. Instiki is quite strict on what it will select - it works on a whitelist system rather than a blacklist. (It has to in order to be safe; there are some quite nasty things that one can insert in to pages without it being at all obvious what’s happened.) So the SVG should be further processed to ensure that all of its information is in the right places and Instiki will not strip it out. To do this, one uses a Python script called scour. So:
Step Two: Run your SVG through scour, use the following options:
python ~/local/share/scour/scour.py --remove-metadata --strip-xml-prolog --enable-id-stripping -i diagram.svg -o diagramSc.svg
(hopefully obvious which bits need changing for someone else’s system)
If you have a modern enough version of Inkscape, it comes with scour built-in as an extension (or it can be added). In which case Steps One and Two can be combined in to:
Step One-and-Two: Save your SVGs from Inkscape as “Optimized SVG” (but check that the extension version is the same as the latest version of scour).
That’s my usual workflow. However, in this case I discovered a further wrinkle which was extremely irritating. As I said, Instiki likes to have its information presented in a certain way. The above puts that information in that way. Except that there is at least one piece of information that Instiki likes to have in the alternative way, and this was controlling how the arrowheads were being displayed. So that bit of information needed further processing to put it back again. Doing this involved:
cat diagramSc.svg|perl -lpe 's/^ *//;s/overflow="visible"/style="overflow:visible"/g' > diagramScLab.svg
Once I’d done that, it all worked.
(Personally, I think that Instiki should accept things as scour presents them, so I’ll mention this to Jacques as something to think about.)
Anyway, I did this on the diagrams at the relevant page.
Thanks a lot for taking care of this and for the explanations. We should add some of this to the HowTo pages.
I have now added a section How to include SVG into the HowTo-page.
1 to 6 of 6