Just thought I would start a thread to share a few of my tips and tricks to working with Inkscape to produce new parts/boards for Fritzing. (please feel free to add your tips and corrections)
Setting up Inkscape.
Set transformation parameters.
Edit/Preferences/Behaviour/Transformations
Disable “Scale Stroke Width” (makes it easier to change size of holes in rings, etc)
Disable “Scale Rounded Corners in Rectangles” (makes adjusting custom PCB size more consistent)
Enable “Optimized” Store Transformations (should be enabled by default and should prevent some extra transformations from being inserted)
Removing extra transformations inserted by Inkscape.
Option 1) (Works 99% of the time)
Ungoup objects until they are no longer in a group (Ctrl Shift G repeatedly or Extensions/Arrange/Deep Ungroup) and then Re-group (Ctrl G) and rename the group to its original name.
Option 2) (should work but I have not had the best of luck as it has made some unexpected changes but worth a try)
Use Apply-Transformations extension https://github.com/Klowner/inkscape-applytransforms
Repairing Custom PCB with holes. (If Fritzing says your PCB does not have any holes but it should)
Select all board parts while holding shift. (You may need to be in node editing mode not object)
Union all board parts into a single outline (Ctrl +)
Break apart previously unioned board outline (Ctrl Shift K)
Select 2 previously un-unioned paths that should be holes (while holding shift) and union them together (Ctrl +). (You may need to be in node editing mode not object)
Repeat adding hole paths one at a time until all the holes are one object.
Select the board outline and the previously unioned holes while pressing shift and difference them from each other (Ctrl -).
You should now have a Board that Fritzing recognizes as having holes. When you use the board in Fritzing it should tell you that you have 1 hole more than you actually do. (it sees the outer path as a hole plus the actual holes).
Resizing all rings equally in Copper layer.
Resize each copper ring individually taking note of the difference in the size (before +/- after)
Move entire copper group half of the difference in size. If you increased the size move the group negative on X and Y (size difference/2). If you decreased the size move the group positive on X and Y (size difference/2).
While this is correct, it does work %100 percent of the time, it may not undo all the damage. On PCB I’ve done this and it happily turns some of the pads in to elipses (in xml editor there is a rx and an ry field that are different by a bit) to fix that you need to copy either rx in to ry or the other way around. If it goes to Fritzing like this pad creation in pcb will screw up in odd ways. Another ugly is a translate in only one of copper1 or copper0. As long as it is in the outside group nothing appears wrong (the inside layer inherits the translate) however in Fritzing pcb you change from top of board to bottom of board it appears to invert the order of copper0/copper1 and the translate only applies to one group (as the other no longer inherits it) and the pads will be offset slightly. Testing your new parts by changing from top of board to bottom of board to make sure this doesn’t happen is a good idea.
Again I tend to do something different. To get a mounting hole, I add a circle to the copper layer in the correct place and at the correct size and set the stroke-length to 0. That produces only a hole, no copper.
I have a different way to do the same thing (but it needs to be done per pad which can be a pain). Resize the pad to the new size you want and take note of the new radius value in xml editor. Undo the change (which will move the pad back to where it should be) and then in xml editor change the radius to the new radius value. This increases or decreases the size of the pad from the center without moving it as a rescale does.
Bendable legs: First parts editor breaks bendable legs utterly when you export the part. It replaces the terminal definitions with a group. So you need to either grab a copy of the original svg and use that instead of what parts editor produced or re edit the xml to be a proper bendable leg. Once you have done that Inkscape will happily convert it all to style commands which Fritzing doesn’t support (at least for bendable legs) so you need to manually edit the svg file after Inkscape and change the style commands in to inline xml. I’m working on a python script that will do this (along with removing the px that Inkscape puts on font-sizes that Fritzing doesn’t like) but it isn’t finished yet and I keep finding new ways that it breaks that should be included .
In pcb inheritance of stroke-width for the copper layers doesn’t work (with plain svg it is rarely a propblem, but optimised svg which can cure the style problem does use inheritance and breaks pcb). The problem appears to be that pads are created by a python script that can’t inherit the stroke width to figure out what the hole size should be.
Speaking of hole size, on Inkscape this post from @steelgoose will let you set the hole size for a pad:
There is a way to set the drill hole size to 0.035" in Inkscape: First, open the dialog box “Fill and Stroke”, and click the tab “Stroke style”, set the units to Inches and width to 0.020". Now go the the tool bar and set the units to inches and the width and height to 0.075". Shazam!.. The outside diameter of the circle including the stroke-width minus the stroke-width x 2… leaves you the inside of the circle (drill size). CorelDraw is a little different, the toolbar dimensions are the actual dimensions of the circle and the stroke-width is in a separate window…
edit: What is people’s take on Inkscape .92? I’m still using .91 because while trying to fix someone’s part .92 was changing the scaling (presumably because of the change from 90 dots per inch to 93 dots per inch but I’m not sure) and .91 worked correctly. I should probably upgade again and see what happens.
I was more referring to non round holes. Or making board with tabs between them. If you simply take 2 boards and place them side by side 1mm apart and union bars between them to make break away boards Fritzing will not see the slots as holes at all. You then have to break apart the outline and subtract the parts that should be holes from the outer outline in a single go as I described.
Here is an example that has I believe 27 irregular holes.
The board is only 99mm x98 mm and has 400nets routed on it.
On 5) I can’t say I have ever needed to modify bendable legs but it is good to know how.
On 6) I would assume this is only a problem with editing SVGs exported from Fritzing? I have stopped editing those ones and always start from scratch or edit a file I have kept for editing purposes.
I have been using Inkscape 0.92 since it came out and haven’t had any issues that I know were the result of changes but I may have simply worked around them.
No, its more an issue with changing Inkscape to use optimized svg. That fixes the inline style issues (you can tell it to inline the styles) but it then it optimizes inheritance too and that breaks pcb when it optimizes the stroke width in to the top copper level (leaving the script which doesn’t inherit without its stroke-width) and I can’t find a way to turn that off (since it is legal xml, there shouldn’t be any need to except for Fritzing ).
Just hit an exception to 1), if you have polygons (in this case as a terminal) even ungrouping won’t clear the translate. The bargraph schematic in this thread is the one I’m poking at.
Schematic works but is entirely red (which usually means a connector problem). The only odd thing I see is the terminals are polygons and have translates (that move the polygon when removed by blanking them in xml editor which come to think of it should be
translates can be removed (although the element may move in the drawing) by selecting the translate in xml editor, blanking the translate date and hitting set.
It appears for polygons you would have to edit the point values in the points array to move it without a translate. I think I’m going to replace them with my standard 10thou by 10thou rectangle and see what happens.
I’ll give it a try. It wasn’t the terminals as polygons as replacing them all didn’t fix it, but I think it may still be a translate. One diode has a radically different translate, so I just substituted that with the one above it to see if that cures it. One pin (pin12, connector11) affects the entire part in schematic. If it is unconnected its all red if its connected its all green (not just the pin) and I can’t see anything different about that pin other than the translate.
so select connector0 terminal (after ungrouping it in case that was the problem) and click
extensions->Modify path->Apply transform
(which I’m assuming is the new extension, perhaps incorrectly ), something flashes by (part of it is red making me think error) too fast to see, but the transform is still there when it completes. The extension (or this extension if it isn’t the right one) does seem to remove most of the transforms and thus is valuable. I ended up starting with the original schematic and ungrouping it (which I may not have done the first time) before moving the components and that seems to fix the problem, but the result still has transforms, so I’m left not knowing why the original doesn’t work. So I guess I ignore it for now since I have something that works.
I am not as familiar with the XML part as you so I can’t be of much help with that. I do use the XML editor in Inkscape but mostly for rearranging things and changing ID’s. I try to do all the other changes using the tools rather than edit the XML directly.
Glad you got it working and glad to see ungrouping all the way seems to have helped.
Another thing I read was that nudging everything slightly will cause all the transforms to converge or at least most of them. I believe they said to select all and then use the cursor keys to move them and then move them back. After that the transforms are supposed to be merged or something. Haven’t tried it yet because my ungrouping trick has worked for me thus far.
Tip 9 (which I just discovered others may already know it ) in Extensions->Arrange->Deep Ungroup if you select the whole document and start this it will recursively ungroup the entire document. Much better than the ungroup one at a time method.
Don’t feel bad,I had to go back and check that I hadn’t had a senior moment and rediscovered something we had already discussed Both of these are valuable tools!
A bb file that looks fine in Inkscape scales too large when loaded in to Fritzing. I’ve hit this before but not known how to fix it, but today I found both the cause and a fix. The original file was done in Illustrator and is apparently 96dpi. Editing it in Inkscape .9.2.1 works fine, but when imported to Fritzing the scaling in breadboard view is too large. I think what is happening is that Ink recognizes the input file was 96dpi, and saves the output file as 96dpi. Fritzing expects Ink to use 90 dpi and uses that, thus the scale problem. The cure is relatively easy (now I have found it at least). Open the file in Inkscape, do an edit select all so you have selected the entire drawing, change the units in the tool bar to in. Now in xml editor edit the ver first node and set the height and width (which will be dimensionless and thus in px, whatever px is currently assumed to be and which causes the problem) to the value from the tool bar in inches with a trailing “in”. Now when you save the file Fritzing can and will calculate the dpi value from the height and width settings in inches. So simple, but so hard to find …
.
), the transform remover won’t do the connection polygons: