Importing external SVGs

[light-matters]

I'm new to the "discussions" part of github, so apologies for accidentally opening a new issue, but how do you deal with importing and embedding external SVG images?
Do you use Hickory or another library to convert SVG to hiccup? Either way, do you plan on making your own convenience functions?

I (selfishly) ask because one of my upcoming projects will be heavy in arranging SVGs and I imagine it would also be of interest to those intending to make complicated images.

[adam-james-v]

Hi @light-matters, thanks for opening this discussion.

I have a small tools namespace which works within a Clojure context, and have a load-svg function.
load-svg

That function just slurps a given filename and uses a function in the utils namespace.
svg-str->elements.

The implementation uses clojure.data.xml to parse the SVG string into a sequence of svg elements represented as hiccup vectors.

Be aware that this does not validate the SVG at all. There may be weird attrs that have no effect within the context of this library, and if any valid SVG elements break some assumptions in my library, results may appear strange. Since this is functionality I want to make more useful for people, I do want to see/hear what users struggle with so I can stabilize import behaviour.

To be specific, my library 'bakes' transforms into the element's coordinates/attrs directly, but a user may import an SVG with transform attributes, which I do not (yet) re-compute into the coord attrs. As in, I don't bake transforms from the :transforms attribute. This could easily break things. As well, my path transform functions work on absolute path coords, but a user may have relative path data. This is also not handled at the moment.

Basically, things should work fine if you have an SVG formatted in a way my lib (currently) expects.

[adam-james-v]

I think I should add a bit of documentation about the tools.clj namespace in the readme, so that users can discover these a bit easier.

I'm glad you like my approach, it's worked well for my own needs, but confirmation from others is always good to hear 😄. It's nice, especially, to hear that you also like the locally based transforms. I can work comfortably with global-first transforms, but with how I use SVG I've really been enjoying the local-first approach.

I'm excited for you to try the library out. Please don't hesitate to post issues/discussions. It's an open source project, so issues are actually extremely helpful for focusing my efforts on parts of the library that really matter.

[light-matters]

Well, since you said so, I'll bother you with another problem I'm having :).

I tested your library with the following code:

(ns scratch
  (:require [svg-clj.tools :as tools]
            [clojure.pprint :as pprint]))

(def folder "...")

(def svg (tools/load-svg (str folder "b-mir.svg")))

(println (tools/save-svg svg "test.svg"))

But unfortunately, the newly created svg file isn't displayed in the browser (I tried firefox and chromium). I get the error:

XML Parsing Error: prefix not bound to a namespace
Location: ...

I wouldn't bother you with it if it was an SVG I created, but I downloaded it from an international collaboration on gravitational waves, and the original file opens with no problems, so it looks like the problem is with the unwrapping/wrapping.

Any thoughts?

Edit: I found a link for the SVG library here, though I downloaded it years ago.

[adam-james-v]

Ok, I played around with a file from this collection a bit.

My load-svg is quite basic and the design assumes that the filtering/processing is left to the user, precisely because I cannot know exactly what details an SVG will come with. For example, the SVG files given have a lot of details packed into the opening SVG tag and meta tags which my library doesn't have functionality to handle.

I don't know the best way to handle things, probably I do need to put a bit more attention to a cleaner loading mechanism (eg. so that any SVG can at least be round-tripped through the loader and saver) but that may take a bit of time.

What does work (at least partially):

(ns scratch
  (:require [svg-clj.tools :as tools]
                 [svg-clj.composites :as c]))

;; using a different svg file...
(def a
  (as-> (tools/load-svg "e-computer.svg") s
    ;; drop 3 to remove meta tags
    (drop 3 s)
    ;; re-wrap elements with svg tag
    (svg s 300 300)))

(tools/save-svg "test.svg")

Using the above technique with "b-mir.svg" produces the following non-working svg:

<svg height="300"
     viewBox="0 0 300 300"
     width="300"
     xmlns="http://www.w3.org/2000/svg">
  <g dimmedPercent="50"
     id="Layer_1"
     layer="yes"
     rgbTrio="#4F008000FFFF">
  <g>
    <linearGradient
        gradientTransform="matrix(0.35 0 0 1 -117.1952 -14.3086)"
        gradientUnits="userSpaceOnUse"
        id="XMLID_2_" x1="350.0874" x2="350.0874"
        xlink:actuate="onLoad"
        xlink:show="other"
        xlink:type="simple" y1="43.0298" y2="14.6831">
      <stop offset="0.0056" style="stop-color:#89A4B6"></stop>
      <stop offset="0.5" style="stop-color:#FFFFFF"></stop>
      <stop offset="1" style="stop-color:#89A4B6"></stop>
      <a:midPointStop offset="0.0056" style="stop-color:#89A4B6"></a:midPointStop>
      <a:midPointStop offset="0.5" style="stop-color:#89A4B6"></a:midPointStop>
      <a:midPointStop offset="0.5" style="stop-color:#FFFFFF"></a:midPointStop>
      <a:midPointStop offset="0.5" style="stop-color:#FFFFFF"></a:midPointStop>
      <a:midPointStop offset="1" style="stop-color:#89A4B6"></a:midPointStop>
    </linearGradient>
    <rect fill="url(#XMLID_2_)" height="28.346" knockout="Off" stroke-width="0.75" stroke="#000000" width="9.921" x="0.375" y="0.375"></rect>
    <rect height="28.346" knockout="Off" stroke-width="0.75" stroke="#000000" width="2.836" x="7.46" y="0.375"></rect>
  </g></g>
</svg>

To make this work, I removed the xlink:actuate (etc.) lines and the <a:midPointStop> tags.
These are elements of the XML that have namespace prefixes (The stuff before the colon is a namespace declaration in XML).

Clearly, my basic load/save approach doesn't handle this use case very well.

You may be able to get things to work with some clever pre and post processing (Clojure is quite good at that sort of thing, at least). I will think about improving things.

<svg height="300"
     viewBox="0 0 300 300"
     width="300"
     xmlns="http://www.w3.org/2000/svg">
  <g dimmedPercent="50"
     id="Layer_1"
     layer="yes"
     rgbTrio="#4F008000FFFF">
  <g>
    <linearGradient
        gradientTransform="matrix(0.35 0 0 1 -117.1952 -14.3086)"
        gradientUnits="userSpaceOnUse"
        id="XMLID_2_"
        x1="350.0874" x2="350.0874"
        y1="43.0298" y2="14.6831">
      <stop offset="0.0056" style="stop-color:#89A4B6"></stop>
      <stop offset="0.5" style="stop-color:#FFFFFF"></stop>
      <stop offset="1" style="stop-color:#89A4B6"></stop>
     </linearGradient>
    <rect fill="url(#XMLID_2_)" height="28.346" knockout="Off" stroke-width="0.75" stroke="#000000" width="9.921" x="0.375" y="0.375"></rect>
    <rect height="28.346" knockout="Off" stroke-width="0.75" stroke="#000000" width="2.836" x="7.46" y="0.375"></rect>
  </g>
  </g>
</svg>

One final thing I noticed (and will open an issue for) is that my loading approach doesn't account for the issue of positional or dimensional values being stored as strings. My transforms expect numbers, not strings, and will break. This is actually why I have to explicitly state width and height when re-wrapping using c/svg; normally it can auto-detect the bounds and set the dims, but the numbers as strings prevents this in the latest library version.

[light-matters]

Thanks. I didn't mean to give you so much work to do. I had no idea until I started looking at these things recently that SVG can be such a minefield :(.

I'm wondering if there's some java library available that you could link to for the loading that covers namespaces and the like...

[adam-james-v]

No worries. It's my library, and I want to work on the parts that can be helpful to other people :)

To start, I do think clojure.data.xml provides the proper tools to make this work correctly. This page has some helpful snippets as a starting point. Swapping out the parser and building custom node editing fns with zippers is the next thing I'll be exploring.

For Java libraries, I don't have an exact answer. This page may be a good place to start.