I used Inkscape to create the .svg files. Initially, all 3 .svg files (breadboard, schematic, & pcb) were very generic. I used the parts editor and created a very generic part.
I reworked my breadboard and schematic .svg to add details and text. Now when in parts editor, when I load the new schematic .svg, the image doesn’t show up in the view. I even tried creating a new part again, using this schematic .svg and it doesn’t appear in the view. I see nothing wrong with the .svg, but I’m no expert.
FritzingCheckPart.py to the rescue your view box is screwed up:
Error 89: File
‘svg.schematic.2.8lcd_977328b1a4d86b634597db07bf1143a4_3_schematic.svg.bak’
At line 18
ViewBox ‘-63.000001 0 0 153.00001’
has characters other than 0-9, whitespace or ‘.’ or not four values.
It must be dimensionless and have 4 numeric values
This is technically probably a bug in the script, but negative values are uncommon in viewbox, Fritzing’s usually start at 0. I attempted to fix this by readjusting the viewbox, but that screws up. I’d suggest redoing schematic from the template available here:
which has the advantage of being the correct scale. You are also lacking terminalIds in this schematic which will cause problems later. It is possible to fix up the current schematic svg, but it is likely to be a fair amount of work and I expect starting from the template will be easier (for some value of easier.)
I tried to fix the .svg in Inkscape, but failed. Used the template to create a new schematic.svg that works. Now that this problem is sorted, on to the next one.
While adding details to the breadboard .svg to make it more attractive, I’ve ran into a problem with text. On the real board, by the 4 pin connector is white text ‘J4’, and by the 14 pin connector is the text ‘J2’. I created the ‘J4’ text in Inkscape, then copied and modified it to give me the ‘J2’. Now when I load the .svg in parts editor, the ‘J4’ appears correctly, but the ‘J2’ is scaled down in size. Here’s a link to the file:
You need to remove the trailing .fzp to recover the svg file (which is what this really is) because the forum often has problems with rendering svgs. The major change was to remove 2 space:preserves (they break the tspan removal code) and run it through FritzingCheckPart.py. That may help because it will remove extra font-size commands (although I don’t see any) and remove the px from the font-sizes. Inkscape likes to leave a font-size inline command while actually using the font-size in the style command. Fritzing prefers the inline font-size (which is often smaller than the one in the style that Inkscape is rendering.) If the font-sizes have the trailing px (which is required by the CSS standard which Inkscape supports), the Parts editor (usually after an edit though) will set the font size to zero which causes the effect you are seeing. All of these should be removed in this svg by the parts check script. Fritzing also doesn’t support nested tspans (again not present here I don’t think) so the script just removes all the tspans and replaces them with equivalent text xml and it inlines the style commands as not all parts of Fritzing support style (notably bendable legs.)
Thanks, but your fix didn’t work, and I deleted the file without taking a screenshot of the new problem. You did fix the small font problem, but in the process, the other font (that I duplicated to make the one you fixed) became super sized and it’s color was changed to black.
So naturally, I opened your file in inkscape and looked over the xml to see if I could fix the new problem and what changes were made by you. Seemed like no matter what I tried to fix the problem, the other text was affected. in Inkscape that is. I went back to my file, deleted the duplicated text and created a new text object to replace it. That solved the problem.
Not really sure why that was a problem this time around, as I have duplicated text before in inkscape and it’s never caused a problem before.
Anyway, thanks to your help, I now have the part all pretty looking and working in fritzing, but I want to check the .pdf exports with the real part. Now how good is exporting a .pdf from fritzing and printing it? In the case of this part, it appears good, but I noticed a problem with another part I created…
I find Inkscape to be quirky. I keep a copy of preference.xml from the installation and when it goes weird (such as deciding to make a copy as an image rather than xml) I replace preference.xml with the version from install and that usually fixes the problem. I assume something changed (possibly something I did via a keyboard hotkey by mistyping) and it just sometimes stops working correctly. About pdf expoert, as far as I know it works most of the time (I haven’t used it though) I usually use the gerber export which sometimes has problems with paths (i.e. pcb view looks fine but gerber output is wrong.) Kjell has fixed at least 5 bugs in gerber export in the development version (but so far you need to build that from source I believe.)
I don’t think inkscape is quirky, I get along with it quite well considering I am a newbie at it. I think the inkscape to Fritzing interaction needs work and I think most of the problems can be solved on the inkscape side of things.
Anyway, here is my ‘beta’ part, please run it thru your parts checker and let me know if there are any problems. Fritzing pdf export of the PCB silk screen and the left side 14 pin connector line up with the board I have. The 4 pin, right side connector (for the sd card) should line up, but i haven’t checked it because I don’t have a header soldered in there yet.
Quirky is possibly an incorrect term (although there are bugs in Inkscape that I occasionally hit too), I think the real problem is ignorance on my part. I think what happens is I type aiming to change text, without having the text field selected. As a result the text is taken as hot key presses which sets some condition (such as changing the result of a copy / paste operation to paste an image of the original instead of the xml that I wanted) and I don’t know what I did and thus not how to change it back (because it gets set in the preferences.xml file and is thus persistent.) Annoying Inkscape certainly is . Not all of the problems are solvable in Inkscape because Fritzing does not fully support CSS and Inkscape does. The two are fundamentally incompatible and Inkscape has no reason to change (nor any interest in doing so.) The part check script started out to do exactly that (it could also be perhaps be done in Fritzing, but when I first did the script, Fritzing development was stopped with no new release planned.) Since I needed to parse the xml to make the changes, I could also flag and correct errors in parts and over the course of a year or more the script as it stands grew. I am slowly working on making the script more robust to add it to the input tool chain for parts submission on github (i.e. your part will need to be able to pass the scripts checks to be included in core parts.) On to your part.
Mostly very good, just a few issues: FritzingCheckPart.py script output (edited for space, as the output is typically long even for a good part):
Modified 1: File
‘svg.breadboard.2.8lcd_05ce3fb27514cf8fb52325ad444b9354_9_breadboard.svg.bak’
At line 225
Removed px from font-size leaving 2.11666656
… (many more)
The script removes the px from the end of the font-size because if it is there (which is required for CSS compliance which is why Inkscape adds them) when the part is edited or loaded as an svg in the parts editor the font size will be set to 0 (or in the example below to a large value.) There is an example in
when the breadboard svg was loaded in to the parts editor. The font size will be set wrong (typically it is set to zero and the text disappears, in this case it appears to have been set large for some reason. In either case you need to remove the px from all the font-sizes in all the svgs. It is done by the script automatically, but can also be done with a text editor by doing a global remove of “px” (you do need to insure you don’t have a “px” that isn’t part of a font-size though!)
Connector8 doesn’t exist when it must to stay in sequence
The pin numbers should start at connector0 and go up in sequence, that isn’t true here. It is only a warning because it only sometimes breaks the hover on a pin to get the pin label function not anything more serious.
Warning 20: File
‘svg.pcb.2.8lcd_05ce3fb27514cf8fb52325ad444b9354_9_pcb.svg.bak’
At line 42
copper1 layer should be at the top, not under group silkscreen
This is slightly misleading in that copper1 is actually under copper0 not silkscreen, but the order should be silkscreen, copper1 with copper0 as a group under copper1 (at present copper1 and copper0 are reversed.) I don’t know of any problem this causes other than Fritzing will prefer to select silkscreen if it is the lowest group (thus a warning rather than an error.)
While this shows as an error (because in schematic it likely is one), in this case it is ignorable, because Fritzing will use the center of the pin as the termination point as was intended. Technically you can and should remove the connectorxterminal elements in breadboard, but it won’t hurt anything. repeats for all the pins on breadboard.
Error 69: File
‘svg.schematic.2.8lcd_05ce3fb27514cf8fb52325ad444b9354_9_schematic.svg.bak’
At line 16
Found a drawing element before a layerId (or no layerId)
This one is the only real error. The schematic svg lacks a layerId (in Inkscape you need to do an “edit->select all” then Object->group and name the group “schematic”). If this part is exported as an svg, at least schematic will not show up in the sketch due to the lack of the layerId.
Error 74: File
‘svg.pcb.2.8lcd_05ce3fb27514cf8fb52325ad444b9354_9_pcb.svg.bak’
At line 133
Connector connector18pin has no radius no hole will be generated
This isn’t actually correct, because there is a circle (the connectorId is attached to the rectangle which overlays the circle) so a hole will be drilled. But from a usability standpoint it is better to have the connectorId on the circle so someone modifying the part can change the hole size easily.
With that done and no major problems, load the part in to Fritzing and test it. This is to catch errors that the script can not (such as a terminalId existing but being in the wrong place). Here is a sketch of a typical test:
Here all connections are connected to .1 header connectors and routed in all three views to make sure the connections go where expected and the terminalIds (mostly in schematic) are in the correct place. That is the reason for the 45 degree offset of the connections in schematic. If the terminalId is wrong or missing (which the script should catch), the wire will connect to the middle of the pin (or the wrong pin completely which the script will not catch). In this case they are all correct. In pcb view all the pins are routed, and then every other trace is moved to the top of the board (except for SMD parts which only have one side) to make sure both layers are working correctly. Then the resulting sketch is exported as a gerber and checked in a gerber viewer for correctness (in this case I used gerbv from the geda project) as there are bugs in the gerber code that sometimes make the gerber output incorrect even though pcb view looks fine. This is also a good place to check the hole sizes of all the pads, as the gerber output has a drill size table for the holes that will be drilled. In this case your hole sizes are too small. For .1in headers the standard hole size is 0.038in, in yuor part the holes are only 0.035 as we see by exporting the test sketch to gerber and then editing the drill.txt file in the gerber output (it is much longer than this, but the drill sizes are at the top):
; NON-PLATED HOLES START AT T1
; THROUGH (PLATED) HOLES START AT T100
M48
INCH
T100C0.038000
T101C0.035118
%
The top number is the .1 headers in the test sketch, the second number are the pads in your part. To correct that you need to change the dimensions of the pad in pcb view. In Inkscape (the other svg editors are different I think) the calculation is this:
Hole diameter = Pad diameter - (2 * stroke-with of the pad)
In your case using connector0pin as an example that is:
diameter = 0.075in (from the w and h fields in the tool bar when it is set to in)
0.50799996 at a scale of 0.26458 which is a problem, because we need the stroke-width in inches for the above calculation. It is possible to convert this value in to inches. Instead I rescaled the pcb svg to the standard 10.41667 scale (where one drawing unit = 1/1000 of an inch) and did the calculation there. Rescaling svgs is explained here:
Doing that points out the problem. The diameter of your pads is slightly too small, they are around 0.075in (when they should be 0.078in) and the stroke width is 20.00025558. If I reset the diameter to 0.078 and the stroke-width to 20, the holes will be the correct 0.038in. However changing the diameter via the tool bar will move the center of the pad slightly (causing misalignment) so the trick to do is to change the w and h parameters to 0.078 in the tool bar and then record the radius from the xml editor window (which will be 29.) Now undo the w and h changes to restore the pad to its original position and instead change the radius from its current value to 29. This changes the diameter relative to the center of the circle leaving its x y position the same which is what we need in this case. As a side issue the radius is currently an ellipse not a circle (because of floating point roundoff during the rescaling) and thus has a rx and ry in xml editor. We want to change both to be 29 which will make it a circle with r=29 again. Then change the stroke-width to 20 and you are done. Alternately you can do the scale mathematically like this to calculate a new radius and stroke-width at the current scale (but I find rescaling easier):
scale 10.41667 / 0.26458 = 39.37058734598231
so work backwards radius 29 / 39.37058734598231 = 0.736590484291045
So in your original svg setting
each circle to radius 0.736590484291045 and stroke-width 0.5079934374421 will have the same effect, a pad with a 20 thou copper width and 0.038 hole in the gerber output. Here is an updated part with the schematic layerId added and the rescaled pcb svg with 0.038 hole pads:
The easy way is likely to create a new account with the new name, otherwise you would need to contact the web page maintainer (there is a link to do so on the login page somewhere I believe.)
I originally read your report and I was a bit lost by the time I finished reading it. So I’m re-reading this and ready to fix the part, fixed the schematic.svg already. I read to the end of your reply and find you’ve fixed it all…
I was going to finish it and fix all the problems…
your view box is screwed up:
