I use the copper top .svg export for a basic ‘board look’ as you can see in the picture. This is a representation of the finial product in 3D. I’m going to use these designs to go after a trade-mark threw the USPTO. I have 3 more designs to finish.
The problem happens with larger Fritzing .SVG exports. There is some extra code in the .SVG file, this issue keeps the lines from being properly imported into FreeCAD. Do I need this aside ‘looks’? The simple answer is no. BUT, I am going for full effect here.
I’ve uploaded the file, but it wont even show here… Probably the issue I’m talking about…
I used the .pdf export from Fritzing as a convertible file for my workaround. pdf zipped mEgarAt_etch_copper_top_pdf.fzpz (37.2 KB)
(rename .pdf)
So the workaround that allows an .SVG import into FreeCAD is a program called, pdf2svg.
So instead of being able to directly work with a Fritzing .SVG export. I have to export as a .PDF then use pdf2svg to get a file that is ALMOST clean enough to import. After that I ran another program called scour to cleanup the new .SVG file. Then it imports into FreeCAD.
So here is the re-spun .SVG file done with pdf2svg for import
That is the file before running scour
after running scour
I have not dug into any of the original Fritzing .SVG exported code. BUT, it would be nice to find out what code Fritzing is inserting into these .SVG exports that make them incompatible with FreeCAD(& whatever other programs). Inkscape seems to open the original Fritzing .SVG file no problem. SO it could be a FreeCAD issue. But from my understanding FreeCAD is all python scripting for importing into FreeCAD, with opencascade binding of some sort.
Not something I have a ton of time to spend on, given I have a viable workaround. BUT it would still be BEST for a direct export to ‘just work’
You can rename the svg to .fzpz and upload that (for both the svg and the pdfs for that matter) and tell us they are really a svg or pdf so we rename them after download The forum doesn’t like a fair number of svg files (and even when it does it renders them and you need a save file as to get a copy).
I wonder if this has something to do with Fritzings love of putting paths/elements inside groups inside groups inside groups. I am trying to ungroup it now to see if that fixes things. First I tried Inkscape deep ungroup but that failed with warnings which I have not seen before.
This is after pressing “ctrl a” (select all) and then “ctrl shift g” (ungroup) in Inkscape. It now uploads to the forum so maybe it is fixed? It did take a very long time to ungroup and my system wanted to force it closed but I just waited. Also note to make the image show I changed the width in the posting code from 6 to 600. Use right click and save as to download the SVG
Yep I’ve hit that before. Something in the python screws up and gives you a traceback. Of more concern is that deep ungroup (unlike Inkscape ungroup) doesn’t collapse the transforms, it leaves them in. That too may be part of the problem. As always transforms are evil .
So deep Ungroup is different. It probably doesn’t effect me Ungrouping PDFs with 20,000 elements - can take an hour with std Ungroup -, but that’s still good to know.
Well, I tried inkscape and the ungroup route for the other file I have in-question. This new(other) file acts the very same way as the first one. In the end, these two board(s) interface with each other. BUT, fritzing wise, they are totally different files. Nevertheless, this file will not import with line(s) into FreeCAD without the workaround. Here is the other svgratshield_etch_copper_top.fzpz (373.6 KB)
(original svg fritzing export needs renamed)
seems fruitless as I still cannot import the ungrouped file into freecad with resulting lines. Here is a freecad screen-shot after ungrouping. It’s the same as not even touching it.
I havn’t had much time to dig into this aside this very surface level stuff we are talking about. But something we do need to look into for a future fix
At least this helps us narrow down where the issue is in the SVG. We now know it is not a result of groups.
Also from your last post showing it is the traces that do not show up I was able to determine that the shapes that do show up are either polygons or predifined shapes (rectangle, circle) with their locations defined with two location parameters. The traces on the other hand are defined as lines with four points defined (start of line x and y position and end of line x and y position).
In inkscape I selected all (ctrl a) and then object to path (ctrl shift c) which looks to have turned the lines into polygons (still has line ids).
EDIT: It should also be said that the scoured file from the first post has had the line segments converted to polygons so this last solution may be the easiest work around.
Also I do not think this is something that can be fixed in Fritzing since the advice DiodeDave gave us implies that we want the traces defined as lines in the Gerber output not polygons as the broken New Gerber output creates. The good news is if someone were to take the new Gerber output and separate it out to be just for SVG and PDF output it would make really clean polygonized files which would work for this and make manual editing in an SVG editor much easier. We would still need the old Gerber output or a completely re-written Gerber output though.
Smaller exports seem fine(in FreeCAD)… IE my example product in OP. RaceTraxEXTbase-copper-REV1A_etch_copper_top.fzpz (135.7 KB) (rename .svg)
Any fritzing files simply cleaned with the workaround will show as-is on this forum, BUT Fritzing .svg exports do not show up without renaming them for download.
Nevertheless, this file will import into FreeCAD, but any larger files, ie; prior posts, they simply do not import properly…
Interesting issue. I’ll play with this a bit more later-on. Just wanted the issue noted with workaround. So anyone playing around has a suggested route to take as a viable workaround.
An interesting experiment to see if it is only size (as opposed to different constructs or some particular construct) would be to take the RaceTraxEXTbase-copper-REV1A_etch_copper_top.svg file and duplicate it a couple of times by copy / paste in the svg to make it bigger and see if it still renders correctly in FreeCAD. If it doesn’t, then the bug looks to be in FreeCAD with file size (probably running out of memory for data that isn’t being reported correctly as failure). If that does work then it likely points to a construct that Fritzing is using that FreeCAD doen’t like. That would be more work, as you would want to section the unworking svg probably by a binary search (i.e. cut it in half and try each half then recuse down) til we can identify what construct FreeCAD doen’t like or if some number of a previously working construct breaks things. I was hoping to be able to see what was different on the original 3 svgs, but of I find they are entirely different. The pdf exported version is entirely paths, which may point more to FreeCAD not liking some particular svg construct (or of course may not ).
.
).
