Allow for Non-Pixel Sized SVGs

[dmsenter89]

The SVG format allows the height and width of an SVG to be specified in units other than pixels, such as milimeters. This seems like a very useful feature to support for converting image data to for simulation. Currently MeshmerizeMe requires the height and width to be given in pixels, and does not contain any code to handle coordinate transforms within the SVG. We should add a feature that allows for SVGs with height/width specified in units other than pixels.

[mountaindust]

There is a bug associated with this as well: SVG does not require the height and width to be specified in the svg tag at all. An example is given on the wikipedia SVG page:

<?xml version="1.0" encoding="UTF-8" ?>
<svg xmlns="http://www.w3.org/2000/svg" version="1.1">
  <rect x="25" y="25" width="200" height="200" fill="lime" stroke-width="4" stroke="pink" />
  <circle cx="125" cy="125" r="75" fill="orange" />
  <polyline points="50,150 50,200 200,200 200,100" stroke="red" stroke-width="4" fill="none" />
  <line x1="50" y1="50" x2="200" y2="200" stroke="blue" stroke-width="4" />
</svg>

If you create an svg out of this, it throws an error in svg_parser.get_paths because it width/height is an empty string (I know there's no path here, just a line... I'm not suggesting we include line objects at this time).

Another related issue: the for loop in svg_parser.get_paths will just overwrite the width and height dict fields on each pass. This is undesirable behavior: if we want to expect just one svg tag, we should throw an error if more than one occurs. Otherwise, if we want to accommodate more, then we need to have an implementation that specifically does so - as is, it's a run-time bug that potentially could have been hard to track down.

[mountaindust]

The more I think about this, the more I suspect the OP is a bit more complicated than necessary. The W3C SVG specification, particularly on units and coordinates makes good reading (just as an FYI, Inkscape appears to assume this default conversion table (90 dpi) by default; if you open an SVG with width="90" height="90" and then the same one again but with width="1in" height="1in", you get exactly the same thing).

In fact, maybe reliance on the viewport for establishing placement of the Lagrangian mesh is not the best way to go. You already assume that your SVG is "simple" in certain ways, allowing you to directly pluck the path information just by looking at the d= field - e.g., there is no coordinate transformation or viewBox environment acting on the path. Perhaps more importantly, it appears that path objects do not support units (if you just add px after each number in the d= field, nothing draws). So, after dispensing with all of that, you are left with the assumption that your path object is specified in pixel units relative to a global origin, regardless of what the viewbox looks like.

So then, why not just match that origin to one that also exists in the Eulerian grid and assume your coordinate system has either the same units or a standard transformation, like 100px per 1.0 m (the stated unit of Lx and Ly in IB2d)? 100px per 1 m would make sense because 100x100px seems to be the default viewport in Inkscape, and Lx=1.0, Ly=1.0 is pretty standard for IB2d. Then you don't have to worry about any of this mess, including width and height not being specified in the svg field and overwriting dict fields. For robustness, we can also throw an error if a transform field or viewBox is encountered.