Messy SVG import


Recently noticed you can import SVG in V6 now - great addition!
The first attempts failed though - the curves come in messy and scattered on first 2 files I tried.
(compared to Illustrator import where all looks fine). Problematic files attached. (4.2 KB)


(Brian Gillespie) #3

RH-39013 is fixed in the latest WIP

(Wim Dekeyser) #4

I tried SVG import a few times in the past without success and have now installed the latest WIP.
It doesn’t seem like anything is getting in at all.

Attached is a file that was downloaded from the internet and a version thereof that I’ve manually stripped to the bone. In the process of gradually getting rid of stuff, the previous WIP would first echo “Error importing file “C:[path]\[name].svg””, then nothing at all, and finally "Successfully read file “C:[path]\[name].svg” but each time, nothing would come in. (4.4 KB)


Hmm, nothing useful comes in here as well.
The solution flag should be removed…

(Brian Gillespie) #6

Hmm. I’ve reopened the bug and attached your file.

(Tim Hemmelman) #7

Hi Wim,

I’ll take a look at your SVG file(s) today. Just curious what app(s) do you have that will read those files? I tried Edge, IE, Chrome and InkScape and none of them gave me anything. Can you give me an image (or an app that will read it) of what 1-original.svg is supposed to look like? Thanks.


(Wim Dekeyser) #8

Hi Tim,
Sorry about that one - it’s not self-explanatory… The original logo on the web page is white on a black background.

I take it into Inkscape to ungroup and stuff but looking at it in IE, for example, works fine but then you’ll have to change the background color…

The bare-bones one does not show up in IE but is black in Inkscape.

(Tim Hemmelman) #9

OK. I see that now. I changed the colors and now can see it in Chrome. I didn’t try InkScape but I’m sure it works. This needs to work in Rhino. I’ll start working on it today.


(Tim Hemmelman) #10

Hi Wim,

Just curious, do you recall which build of Rhino you were using when you tried to open your svg file? I went to work on this and realized it was working already. I hadn’t made any additional changes since the fix I made fro Jarek’s files. So I suspect that if you get the latest build it will work for you. If you get the latest build and still find it doesn’t work (latest build is Apr 26 and I made the changes on Apr 21) please let me know.


(Wim Dekeyser) #11

I don’t recall but I’ll check in the morning, Tim.
From my post it sounds like I installed the 26th version on the 27th and tried that one. But I’ll check when I get to work.

(Tim Hemmelman) #12

Hi Wim,

To be completely honest. I tested with an internal build from today after determining it worked in my debug build. I suppose there’s a chance that something outside of the SVG code had changed and made an impact (not likely but it sounds like you tried the build I would have that thought would work). There’s a good chance there will be a new public build tomorrow afternoon. If you don’t already have the build from the 26th you may as well wait and just get the one from tomorrow. Thanks for checking it out.


(Wim Dekeyser) #13

Just to confirm, I tried it in the 26th version and it doesn’t work there.
I’ll test again when I get the new WIP installed!

(Tim Hemmelman) #14

Hi Wim,

A couple more questions. Do you use a comma or a period as a decimal point for your locale? Do you get a messy picture like Charles above? If yes, what is the rough width of what you see? The reason I’m asking is the string to double and string to integer conversions were not taking into account that some locations use a period for a thousands separator and not a decimal point. That’s the only thing I can think of that would be preventing the build from the 26th from working right. I’ll commit the fix immediately and there’s a chance it will get in today’s public WIP.


(Wim Dekeyser) #15

Hi Tim,
The decimal separator around here is the comma.
I don’t get a messy picture, though. Nothing at all comes in - command line echo:

Successfully read file "C:\Temp\1-original.svg"
Command: '_SelAll
No objects added to selection.
Command: ZEA
Command: '_Zoom
Drag a window to zoom ( All Dynamic Extents Factor In Out Selected Target 1To1 ): _All
Choose option ( Extents Selected 1To1 ): _Extents
Unable to zoom some views - no objects are visible.

And this is in the May 2nd release…

OK… I’ve played with this a lot more now.
I tried importing the same SVG file again in the same session and got this message:

A block definition named "path-1" already exists.

I guess it’s unexpected behavior that an import would create a block at all - but in the end, I suppose, this is correct in this case…

I then went into the Block Manager and did a block count on that instance and got this:

Block Name, Top Level, Nested, Total path-1, 0, 0, 0

Grasping at straws I then exported that block to the CSV format and opened that file to read the following:

"Object Count","Layer Name","Object Name","Object Category","Object Type","Attribute Keys","Attribute Texts","Object Keys","Object Texts" "1","ClippingPlanes","path-1","curve","closed polyline"

That explains…
The first layer in my template is the ClippingPlanes layer. It is turned off.
Turning on this layer shows the SVG geometry successfully imported.

I guess I was lucky there was a < defs > element in that original SVG file or I would never have found the contents.

Would you agree with me that importing a SVG file into a hidden layer is a bug? In my mind, it would have to come in on the active layer…


(Tim Hemmelman) #16

Hi Wim,

You’re right that anything in the <defs> node gets turned into a block definition. I just looked at the code and I don’t set a layer anywhere in the plugin so it must be the way RhinoCommon adds objects to the document. I should be able to force the layer to be the current layer in the document though.


(Brian Gillespie) #17

RH-39013 is fixed again in the latest WIP


And works perfect now!
I think it was ‘only’ the decimal separator…