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.
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.
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.
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.
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.
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.
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.
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.
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…
Boy…
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:
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…
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.
Seems the USE elements are still not noticed. Workaround: very repetitive SVG code.
Also: text is acting up in several ways: wrong position, wrong size, or not shown at all. Haven’t figured a workaround or a pattern even.
The hand-coded SVG was valid according to the W3C-validator and showed up what I expected in Chrome and Inkscape, and had less text trouble in Firefox.
Please don’t mix different support channels. The issue that you refer to was reported as RH-76279 SVG import changes shape and coming into Rhino as blocks
-wim