I followed a tutorial I found, but when I went to place it on the PCB, I could not resize it, or get it small enough to be seen on the PCB.
Will start over and give it another go.
I think it has to be the exact size dimensionally for the PCB view, like all parts.
In Fritzing measure how much room there is, use coordinates bottom left and click it to change units, then set the drawing svg units the same and make it 1:1.
1 Like
I just replaced the complete text of the first two posts in this thread that make up the howto with a corrected and expanded version. If you have read the original please read the update, as parts of the original are just plain wrong!
Peter Van Epp
Thanks, Should those post be made into a sticky? I see a lot of threads asking about creating a part.
@vanepp can you please give me some idea as to what the issues were with optimized svg? I missed the change in the guide and a number of my recent parts have been submitted in optimized format - some of which are now in git, so I need to do some serious damage assessment. Note that if you use a master copy of your file as proper inkscape, and then āsave a copyā to plain svg, that has a number of benefits - no annoying warning, no loss of inkscape metadata like layer label;s. You can also automate the export process using the command line and --export-plain-svg.
Its been a while, but the main one I think is that pcb view doesnāt deal with inheritance of some of the parameters (I think likely fill) that Inkscape was optimizing in to the group above it. Some part of pcb (probably square pads if I remember correctly) wasnāt rendered correctly til I went back to plain svg. This is why Iām working on inlining all the style commands and inheritance in the python scripts so that you can run optimized in Inkscape and the script will fix the problems. It looks like from my notes of the time that
the problem was to do with the connector pins in pcb (@steelgoose is who actually identified the problem, so maybe he remembers the exact details if we are lucky)
(edit: fit the enter key instead of paste ā¦)
Found the reference in
That is strangeā¦ I imported the pcb.svg into CorelDraw, deleted the meta data, then exported it back into the FZ diode part. the Gerber drill hole size is 0.035", the same as in CorelDraw. Idiosyncrasiesā¦ this could be a problemā¦
EDIT: Got it, the āstroke and stroke-widthā are in the id=ācopper0ā layer. There is no stroke and stroke-width attributes in connector0pin and connector1pin elementsā¦ this has resulted in the stroke-width not being subtracted for circle diameter, causing drill holes in the Gerber to be drill as NON-PLATED HOLES instead of THROUGH (PLATED) HOLESā¦
FIX: In Inkscape, cut the āstroke and stroke-widthā from the copper0 layer and past them into the connector0pin and connector1pin elementsā¦
PS. Also when you save the .svg, check the box āRemove metadataā. That will get rid of a lot of that unneeded garbage and clean up the files.
This is where I fall down with Fritzing - I donāt use PCB much; Iām mostly a breadboard man 
Have you been creating this from scratch or adapting the original scour.py optimized svg output script? It should be possible to nobble it fairly easily to add the options we need.
I need to get coding on this soon. I think it should be possible to get an entire workflow going (Iāve dubbed it FritzInk)
From scratch, Iād never heard of scour.py (although I will go have a look at it now 
). I only just discovered while reading answers on stackoverflow that Inkscape is apparantly written in python using lxm. I did see a reference to an Inkscape plug in to collapse redundant groups that I need to look at. Iām also finding out why people are resistant to changing to python 3 I have (or had) pretty printing running and then move it in to the main script where it promptly broke because I hadnāt remembered to set pythin3 in cygwin so it was using python 2 . Iām so far having little luck in getting the pretty printed xml to write to a file (because its in a funny format because of a lxml limitation that just works on 2.7 but tosses type errors on 3. I was thinking that once I get the standalone scripts running looking at an Inkscape plugin would be a good bet, a one step process would be better (but it would likely preclude syntax checking of fpz files so maybe not )
Peter
Wow! Got the python script far enough last night to run it against the core pcb svg library (some 200+ files which took 5+ hours to complete under perl). It complained (with cause ) about bad xml in 5 or 6 files (as did perl) but completes doing both the convert silkscreen from white to black (which is the only part perl was doing) and inlining style commands and prettyprinting the output file in less than a minute. I ow have a list of commands that are being (or sometimes not being inherited so I can pick those out and cause them to be inlined as well now.
Thatās great progress! I am thinking I might try patching scour for the px and group issues and sending a pull request to the author. Latest Inkscape uses whatever scour you have installed in preference to itās own, so doing that might effectively give us usable version of Save As Optimized SVGā¦ Just need more time!!!
I had a look at scour, but the python was way beyond my level. At this point I have a python file that will convert a single Inkscape svg in to something with inline styles and the stroke commands inherited and the px es removed from font-size commands so the gerber script will see them and another that processes the fpz file and pulls out the layer names and connector values. Iām now working on merging those two (and changing the svg processor to pull out the connections in the svg so I can warn about missing connectors or level names in the svgs). As well I managed to get some input on the subject from El-j by posting a bug report (that wasnāt really a bug report) on github in
where he supplied some pointers to work already underway in Fritzing which look interesting, although Iāve yet to make any sense out of travis-ci except that it tests something (what it tests or how isnāt clear to me ). Along the way Iām learning github (at least sort of so far) and will eventually post the python there although I perhaps should try and post what I have so far sooner rather than later it sounds like. Iām just about to post a couple of real bug reports against parts. The convert silkscreen python script finds at least two fatal to Fritzing part errors in pcb and another 3 or 4 that arenāt legal xml but donāt break Fritizing types. So far schematic and breadboard look clean. In fact it just finished and all except pcb look to be clean xml wise.
Peter