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!)
Warning 35: File
‘part.2.8lcd_39de3ee585f2ffe550adae879937fb0f_8.fzp.bak’
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.)
Error 18: File
‘part.2.8lcd_39de3ee585f2ffe550adae879937fb0f_8.fzp.bak’
Connector connector0terminal is in the fzp file but not the svg file. (typo?)
svg svg.breadboard.2.8lcd_05ce3fb27514cf8fb52325ad444b9354_9_breadboard.svg.bak
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:
test.fzz (18.7 KB)
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
stroke width 20 / 39.37058734598231 = 0.5079934374421
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:
2.8 SPI TFT Module-improved.fzpz (10.3 KB)
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.)
Peter