FritzingCheckPart.py is a python script that checks parts files for use by the Fritzing EDA program (fritzing.org). It started to correct some of the issues that Fritzing has with the output from the Inkscape (inkscape.org) open-source SVG editor program. It then grew into checking the format of the various file (FZP and SVG) that make up a fritzing part. As a part of that, it also prettyprints XML (with varying success). It does best with post-processed fritzing SVG files because it understands their format and has modified the XML (mostly moving CSS style commands into inline XML, which as a side effect makes prettyprinting easier) to better suit fritzing. A standalone script, PP.py, is included, which will pretty-print an XML document without any fritzing-related conversions.
The script uses python3 and the lxml library extensions to python. Since Fritzing runs on Windows, Linux, and macOS, the script should run on those platforms too, and it may. I don't have macOS, so I don't know that it will run there (although there is no reason it shouldn't, I just haven't done it.)
I run the script from cygwin on Windows. It will likely run on one of the native python implementations (you may need to use pip to install the lxml extension) but I haven't done so. For cygwin you need to install cygwin . Use the setup program as detailed on cygwin.org. The basic install with the following additions does fine:
python3: Py3K language interpreter python3-lxml: Python XML2/XSLT bindings
(and all their associated dependencies)
with that in place from a cygwin terminal copy the python scripts
FritzingCheckPart.py
FritzingTools.py
PP.py
PPTools.py
to /usr/local/bin
chmod ugo+x /usr/local/bin/*.py
Tested on Ubuntu 18.04 LTS Python3 is required
git clone git@github.com:vanepp/FritzingCheckPart.git
#alternative
# git clone git@github.com:KjellMorgenstern/FritzingCheckPart.git
pip install --user lxml
Assuming you have Fritzing installed the following will check (and complain about!) the parts in core:
mkdir tst
FritzingCheckPart.py fritzing-0.9.3b.linux.AMD64/fritzing-parts/core tst
(replace the fritzing-0.9.3b.linux.AMD64/fritzing-parts/core with the path to your fritzing-parts core directory!)
which should produce output like this (in large volume) on the console:
**** Starting to process file 10x2-Epaper-Breakout-Board-v11.fzp
Error: File
'/cygdrive/c/fritzing/fritzing.0.9.3b.64.pc/fritzing.0.9.3b.64.pc/fritzing-parts/core/10x2-Epaper-Breakout-Board-v11.fzp'
Connector0 doesn't exist (connectors should start at 0)
...
PP.py xml_file [another_xml_file ...]
will pretty-print the XML file to xml_file leaving the original file in xml_file.bak internally it sets the file type to SVG so that it will split blanks into lines such as attribute="value" attribute="value" into
attribute="value"
attribute="value"
with appropriate indenting. Since this is meant for post-processed Fritzing SVG files, it may or may not do what you want. So try it and see. It won't split on blanks in text or quoted strings but may screw up on general XML sometimes, so use it if it is useful.
There are several modes (selected internally by the number and type of the arguments to the script.):
dir to dir:
FritzingCheckPart.py src_dir dst_dir
This processes all the fritzing files it finds in src_dir and writes their output in to dst_dir. Dst_dir needs to be empty to avoid damaging existing files. Subdirectories to match the fritzing file set up will be created in the dst_dir. If you are processing part.fzp type files the output will go in to dst_dir at the top level and the svg and subdirectories will remain empty. In the case of core in the example above the identical directory format will be recreated under dst_dir. To run this a second time you need to empty the dst_dir via command like
rm -R dst_dir/*
This is mostly used for testing (against core as a source of diverse files, many with errors) and to allow a mass correction of core if desired. Note you only want to run this mode against core as the other modes will change files in core that are under git control and tend to break Fritzing.
FritzingCheckPart.py part.filename.fzp
part.filename.fzp format (from an unzipped .fzpz file which will have files of the form
part.filename.fzp
svg.breadboard.filename.svg
svg.icon.filename.svg
svg.schematic.filename.svg
svg.pcb.filename.svg
The input files will be renamed to filename.bak with the script output, the fixed up (we hope) xml, written to the original file name ready to be rezipped and loaded to fritzing. If something goes wrong, the original data is in the .bak files (so long as you haven't run the script twice). First the fzp file will be processed to get the connector information and the expected svg files, then each svg file in turn will be processed. So you need to pay attention to the file name in the error messages, as it may not be referring to the input file, but an svg file linked from the input file.
FritzingCheckPart.py parts/user/filename.fzp
the input file is in directory user/filename.fzp (and the user in the path is required to be present, the script will error out if it is not). The svg files are in
user/svg/user/breadboard/filename.svg
user/svg/user/icon/filename.svg
user/svg/user/pcb/filename.svg
user/svg/user/schematic/filename.svg
which is the standard place where imported parts are stored by fritzing (in the core exampe at the start of this, the "core" directory is the same as "user" here). Again the fzp file will be processed followed by the associated svgs. So again you need to pay attention to the file name in the error messages, as it may not be referring to the input file, but an svg file linked from the input file.
FritzingCheckPart.py filename.svg
this form does what checks it can on the SVG file (which aren't that many as it lacks the data from the fzp file to know what connectors it should be checking for). What it does do is the original purpose of this script which is to change the style(attribute:value;attribute:value) commands to the equivalent inline xml attribute="value" attribute="value" as parts of fritzing, (specifically bendable legs) don't support style type attributes and won't work if they are present. It changes font-size=3.5px to font-size=3.5 as the trailing px, required by CSS, causes font size errors in fritzing. It converts silkscreen (in PCB) items from the old standard white (which Inkscape with a white background won't display successfully) to the new standard of black. It will discover and complain about (but not so far, do anything about, due to positioning/scaling issues) terminals with zero height or width. These are not selectable by Inkscape making them difficult to move in the SVG. Unfortunately, you need to manually change the size (which changes the position) and then move the terminal to the correct position. It would be nice to automate this, but it isn't done now. Last but not least, if this is a PCB SVG file, it moves stroke-width commands which would be inherited by a lower level group in to that group. The scripts that produce gerber files are not able to access inherited values (as they aren't reading the XML) and thus if a stroke-width would be inherited from a higher level and thus is not present at the level the pad is generated at gerber production fails. I expect this will be the main use for this script. After modifying an SVG file with Inkscape, you need to run this script to correct the modifications that Inkscape has made for CSS compliance before feeding it to Fritzing (which isn't CSS compliant in at least some cases).
There are four internal configuration settings (you need to edit the listed .py file and change these with a text editor):
in file PPTools.py
DetailPP = 'y'
Enabled by default. If detail prettyprinting of an svg appears to have screwed up, set this value to 'n' to disable detail prettyprinting and try again. If it works without the detailed prettyprinting please file a bug.
in file FritzingTools.py
ModifyTerminal = 'n'
Disabled by default because it will make a change that will change the spacing of the terminal position in the SVG, which you will manually need to correct using an SVG editor if the width or height is 0. I enable this (by setting the value to 'y') and then pay attention to the modified messages to tell when it has changed a terminal from 0. If the terminal is 0 width or height, at least Inkscape (which I use) will not select the element to move it. You have to manually select the element and change its position with the toolbar which I find it annoying. With the value set to 'n (the default), you will get a warning message like this one from a current core part:
Warning 16: File '/cygdrive/c/fritzing/fritzing.0.9.3b.64.pc/fritzing-parts/core/../svg/core/schematic/4071_4_x_2_input_OR_gate_multipart_schematic.svg' At line 66
Connector connector6terminal has a zero height and thus is not selectable in Inkscape
This warning is all that it will do. It is up to you to edit the svg and set the height/width to something other than 0 and correct the x/y positioning.
With the value set to 'y' on the same file (in this case changed to an
exported part so as to not change core which will break parts update, but the same file as above) there is a different message in a different place:
'svg.schematic.prefix0000_fa1ebd566edf2f3d943a0046711f2d3c_1_schematic.svg' At line 23
Connector connector6terminal had a zero height, set to 10 Check the alignment of this pin in the svg!
This message tells you the script has moved the x/y position of the connector. Depending on the scale, height or width could become incorrect, as ten isn't appropriate for all scale factors. The warning message is no longer present as there is now this change notification instead. As a result, you need to edit the SVG and check that the terminal is 10 thou (or your preferred size, 10 thou is mine) and in the correct x/y position as expected by the part. The upside is that Inkscape will now select the terminal and move it if you move the entire terminal, which it wouldn't before.
in file FritzingCheckPart.py
IssueNameDupWarning = 'y'
This value (enabled by default) if set to 'n' will suppress the Warning 28: a message which indicates the name field is not unique. While it should be unique according to the parts file format document, Fritzing doesn't appear to care, and it seems to be only used for display in pin labels when hovered over. It is fairly common to not be unique and thus clutters up the error message display. I usually set this to 'n'.
in file FritzingCheckPart.py
Debug = 0
This value enables debugging messages (set to 1 for file output to the console but no further debug messages, set to 2 for enter/exit routine debug messages, and to 3 for detailed but very verbose debug messages). It is used for debugging the script itself so you will leave it at 0 for normal operation.
The most likely bug relates to prettyprinting. To prettyprint svg files the lines are split on blanks (' ') and each element is indented and printed on a new line. Obviously (and for text, comments and referenceFile names so far, detected and corrected for) lines with spaces that are supposed to be there in the final document will get screwed up by the above and will need their tags added to the exemption regex in the code. The original file(s) are saved in a .bak file (i.e. filename.svg will be moved to filename.svg.bak with the script output in filename.svg). However if you run the script a second time without copying the .bak file somewhere safe the original file will be overwritten without further warning, so be careful. In case of script error you will likely want the original file ... There also may be any number of other bugs I haven't found yet. If you come across one please report it and I'll see if I can fix it.
Making a square pad in pcb via a path with a hole in it usually (but apparently not always) works in Fritzing. This script however will toss
'/cygdrive/c/fritzing/fritzing.0.9.3b.64.pc/fritzing-parts/core/../svg/core/pcb/DRV8825_breakout_pcb.svg' At line 17
Connector connector136 has no radius no hole will be generated
Which isn't correct (but also isn't easy to fix). You can either ignore this error as invalid (as long as the gerber export works which it does in this case) or replace the pad with a standard circle with a radius and stroke width (which would be my choice in the matter!) which will remove this error.
Potential error messages and what to do about them:
First the dreaded trace back:
$ ./FritzingCheckPart.py Bean_revE.fzp Traceback (most recent call last): File "./FritzingCheckPart.py", line 51, in rc, FileType, Path, File = tools.ProcessArgs (sys.argv, Errors) TypeError: 'int' object is not iterable
if you get a message like this, then I have screwed up and offended the python gods and they have taken exception (this is basically a software error). The best bet is to provide the call above and if possible a copy of the file that caused it so I can try and fix it.
now on to expected error messages:
Most (but not all, as the first few below show) error messages are of the form:
Error: File '/cygdrive/c/fritzing/fritzing.0.9.3b.64.pc/fritzing.0.9.3b.64.pc/fritzing-parts/core/blend_micro1.0.fzp' At line 444
which gives you the file name followed by the line number (if known, sometimes it isn't) of where the error was detected.
Of note is the filename will be blend_micro1.0.fzp.bak if you are
processing an individual part (which will normally be the case). The reason for this is the output file
blend_micro1.0.fzp
has been prettyprinted, and the line numbers won't match the input file (blend_micro1.0.fzp.bak) so you need to look for the error in the filename listed in the error message and then match it to the same text (which will have a different line number and possibly format very likely) in the output file if you need to. The input file will give you the place in the file that the error occurred. You should fix it there and then remove the .bak extension and rerun the script in the corrected input file.
Usage messages (which are a type of error as they are fatal, but don't have numbers any more)
Usage: PP.py filename (filename ...)
Indicates you didn't give a filename to the PP.py script. It wants
one or more xml files such as
PP.py test.svg
or
PP.py test1.svg test2.xml test3.fzp
Usage: FritzingTools.py filename.fzp or filename.svg or srcdir dstdir
Either no or too many arguments to the script. It wants either a
single file name or 2 directories.
Usage: FritzingTools.py src_dir dst_dir
src_dir filename isn't a directory
In this mode both arguments need to be directories and src isn't.
Usage: FritzingTools.py src_dir dst_dir
dst_dir filename isn't a directory
In this mode both arguments need to be directories and dst isn't.
Error messages in the order they occur in the code so essentially random but numbered so you can index by the number to get the error description and an explanation of the error (with the move of the Usage messages above, some numbers are now missing though.)
The os routines returned an exception when the input file was renamed. Hopefully the cause is obvious from the os messages.
The os routines returned an exception when the input file was opened. Hopefully the cause is obvious from the os messages.
The os routines returned an exception when the input file was written. Hopefully the cause is obvious from the os messages.
The os routines returned an exception when the input file was closed. Hopefully the cause is obvious from the os messages.
The xml parser got an I/O error trying to parse the named file.
The xml parser found illegal xml at the line and column listed after this. Note the lxml parser is stricter than either Inkscape or Fritzing and will report errors that both Inkscape and Fritzing will accept as valid xml. If you look however, there really is an error there and you should correct it. Below is an example from the Bean_revE.fzp file currently in core:
/cygdrive/c/fritzing/fritzing.0.9.3b.64.pc/fritzing.0.9.3b.64.pc/fritzing-parts/core/Bean_revE.fzp:161:90:FATAL:PARSER:ERR_SPACE_REQUIRED: attributes construct error
line 161 from Bean_revE.fzp
<p layer='schematic' hybrid='yes' svgId='connector81pin' terminalId='connector81terminal'hybrid='yes' /></schematicView>
there are two errors in this line. There is a missing space between connector81terminal' and hybrid='yes' and the second hybrid='yes is wrong. The line should be corrected to this:
<p layer='schematic' hybrid='yes' svgId='connector81pin' terminalId='connector81terminal' /></schematicView>
which is correct XML and the complaints from parser will stop. You will get a lot more errors, but again they are really there, even though the part with these errors loads and runs happily in Fritzing.
The file name provided either isn't a file or isn't readable and has been ignored.
for a fzp file in order to find the svg files.
Indicates that it needs a directory (for example core/file.fzp) in order to figure out where the svg files are (../svg/core/... in this case). Supply the directory and it will be happy.
dst_dir
must be empty and it is not
The dst_dir isn't empty (perhaps from a previous run). If you are sure the directory is expendable rm -R dst_dir/* will fix this.
dir_name os_error_message (os_error_number)
A problem creating one of the dst directories. Hopefully the os error messages will make the cause clear.
'src_file' to 'src_file.bak'
'file_name_from_os'
os_error_message (os_error_number)
A problem occurred trying to rename the src_file to src_file.bak. Hopefully the os error messages indicate why.
Id xxx present more than once (and should be unique)
The listed id is present more than once and should be unique (often Fritzing ignores this but it is incorrect)
This is one of those messages without a line number as after all the connectors have been processed, no connectors were found.
'filename'
Connector connector2terminal is in the fzp file but not the svg file. (typo?)
This connector is specified in the fzp file, but isn't in the associated svg file. Depending on what type of connector it is this may or may not be fatal (a svgId is fatal a terminalId is not). In either case it is incorrect.
'filename'
File type xxx is an unknown format (software error)
Another case of software error where the type isn't svg, fzppart or fzpfritz. Shouldn't happen.
'filename.svg'
During processing svgs from fzp, svg file doesn't exist
The filename referenced for this view in the fzp file doesn't exist. Fritzing will try and find something to substitute, but this is still an error.
'Filename.svg'
Has a different case in the file system than in the fpz file
'filename.svg'
This doesn't matter on Windows as the file system is case insensitive however it does matter on Linux and probably MacOS where the file system is case sensitive and the wrong case file will not be found. Change either the FZP or the file in the file system to the same case and all will be well on all systems. While I could correct this in the fzp file it seems better to do it manually because it isn't clear whether the fzp file is incorrect or this particular file system is incorrect, and thus is better left to a human decision rather than a program.
'filename.fzp' At line 1
No ModuleId found in fzp file
There isn't a moduleId in the fzp file. This is likely fatal as I don't think the part can load without a moduleId. Add a moduleId to the file (preferably export a new part to get a Fritzing approved moduleId).
'filename.fzp' At line 20
A bus is already defined, schematic parts won't work with busses
A non empty Bus definition has already been seen. Fritzing won't currently support both busses and schematic parts.
'filename' At line 20
More than one copy of Tag sometag
Tag sometag should only occur once in the fzp file and we have seen another copy of it here.
'filename.fzp' At line 2
Multiple ModuleIds found in fzp file
There is more than one moduleId set in the fzp file (there should only be one)
'filename.fzp' At line 20
State error, expected tag tag not a view name
There is something wrong in the fzp file (or this code). The tag we have doesn't match the expected state of a correct fzp file. Best bet is to check the format of the fzp file against a known good version, as there is probably an extra or missing line in this file.
'filename.fzp' At line 20
View name missing
We have no viewname (iconView breadboardView schematicView pcbView) which should be present.
'filename.fzp' At line 20
Multiple view tags schematicView present, ignored
There is more than one view of this name defined in the file when there should only be one of each.
'filename.fzp' At line 20
View tag schematicView not recognized (typo?)
View tag isn't one of (iconView breadboardView schematicView pcbView) which it should be.
'filename.fzp' At line 20
No image name present
The file name for the svg file is missing in the fzp file.
'filename.fzp' At line 20
Multiple viewname image files present
There is more than one image file name present, there should only be one.
'filename.fzp' At line 20
No layerId value present
There is a layerId attribute present, but it has no value (and it needs one).
'filename.fzp' At line 20
View viewname already has layerId layername, layername1 ignored
The layerId isn't unique and it must be.
'filename.fzp'
No views found.
There are no views found in the fzp file. There isn't a line number because this occurs after we have seen all the lines that may contain a view.
'filename.fzp'
Unknown view viewname found. (Typo?)
Found a view name that isn't one of iconView breadboardView schematicView or pcbView (probably a typo)
'filename.fzp'
No valid views found.
Didn't find any of iconView breadboardView schematicView or pcbView in the list of view names.
'filename.fzp'
This is a smd part as only the copper0 view is present, but it is on the bottom layer, not the top. If you wanted a smd part change copper0 to copper 1 at line 20 If you wanted a through-hole part add the copper1 definition after line 19
This is a smd part, but it is on the wrong layer (and thus likely an error). If you really want the part to be on the bottom for something this error can be ignored.
'filename.fzp' At line 20
State error, tag stack is at level 8 and should only go to level 7
This error indicates that there are too many lines in the fzp file as the tags have gotten deeper than is possible for a valid file.
'filename.fzp' At line 20
Connector has no id
A connector has no id associated with it and it must have one.
'filename.fzp' At line 20
Connector has no Name
A connector has no Name associated with it and it must have one.
'filename.fzp' At line 20
Connector connector3 has no Type
A connector has to have type male or female and has neither.
'filename.fzp' At line 20
Connector connector3 has no description
A connector doesn't have a description. When you hover on a pad in breadboard or schematic you won't get a description.
'filename.fzp' At line 20
Connector connector3 missing view name
The connector doesn't have a view name.
'filename.fzp' At line 20
Viewname bbreadboardView invalid (typo?)
The viewname isn't one of breadboardView schematicView pcbView and it should be.
'filename.fzp' At line 20
Layer missing
The layer attribute is missing in the fzp file.
'filename.fzp' At line 20
No layerId for View SchematicView
A layerId wasn't specified for this view earlier in the fzp file.
'filename.fzp' At line 20
LayerId here doesn't match View schematicView layerId schematic
A layerId here doesn't match the layerId specified earlier for this view (or views in the case of pcb view which can have multiple layerids.)
'filename.fzp' At line 20
Connector connector4 layer copper0 already defined, must be unique
This connectorid layer combination is already defined and must be unique.
'filename.fzp' At line 20
hybrid is present but isn't 'yes' but yyes (typo?)
The hybrid flag is present but with an invalid value (it must be yes).
'filename.fzp' At line 20
Tag svgId is present but has no value
The listed tag is present but has no value set.
'filename.fzp' At line 20
svgId missing
There is no svgId present for this connector and one is required.
'filename.fzp' At line 20
Bus bus2 already defined
There is aready a bus with this id and ids must be unique.
'filename.fzp' At line 20
Bus nodeMember connector2 does't exist
The nodeMember specified doesn't exist and it must.
'filename.fzp' At line 20
Bus nodeMember connector2 already in bus bus3
The nodeMember specified is already in the specified bus and can't be in two at once.
'filename.fzp' At line 20
Subpart has no id
The subpart is missing the id field (required)
'filename.fzp' At line 20
Subpart id subpartid already exists (must be unique)
The subpart is already in use for another subpart and must be unique.
'filename.fzp' At line 20
Subpart has no label
The subpart has not label and it needs one.
'filename.fzp' At line 20
Subpart subpartid already defined (duplicate?)
The subpart has already been defined and must be unique.
'filename.fzp' At line 20
Connector id missing, ignored
The subpart definition is missing the id field.
'filename.fzp' At line 20
Connector connector2 doesn't exist (and it must)
The connector id isn't already defined in the fzp file and it must be.
'filename.fzp' At line 20
Subpart connector connector0 already in subpart sub1
The connector id is already part of another subpart and can only be in one subpart.
'filename.fzp'
No connectors found to check
There are no connectors defined when we tried to check that the connectors are in the correct sequence.
'filename.fzp'
Connector0 doesn't exist (connectors should start at 0)
There isn't a connector0 and there should be.
'filename.fzp'
Connector connector5 doesn't exist when it must to stay in sequence
Connectors 0 to 4 exist, then it skips to something above 5. This causes label problems (as fritzing assumes the labels are in sequence and will misnumber the missing and following connections).
'filename.fzp' At line 20
Connector connector1pad is an ellipse not a circle, (gerber generation will break.)
This indicates a connector in a pcb svg is an ellipse (i.e. has rx and ry rather than r as a radius in the xml). This is usually because of a removed translate that has changed horizontal or vertical scale. The easiest fix is to copy one radius value to the other in xml editor (making sure the new radius value still keeps the intended hole size).
'filename.fzp' At line 20
Connector connector2pin is a duplicate (and should be unique)
The listed connector has already been seen in the svg file and should be unique. As long as the two are defined identically fritzing seems to ignore this, but it should be corrected.
'filename.fzp' At line 2
First Tag tag isn't an svg definition
The first tag in an svg file should be svg. If it isn't there will probably be a problem. Compare your file against a known correct one is probably the best bet here.
'filename.fzp' At line 20
Found first group but without a svg definition
Similar to the error above, we have found a group but haven't seen a svg id yet.
'filename.fzp' At line 20
Found a drawing element before a layerId (or no layerId)
A drawing element (perhaps a connector) has been found before the layerId. If it is a visible part of the drawing, it likely won't be present if the drawing is exported as a svg, so it is better to have the layerId first. This also may mean that the layerId is missing entirely in which case one should be added befoe any drawing elements.
'filename.fzp' At line 20
More than one silkscreen/copper0/copper1 layer
We have already seen a layer of this name in this svg, a second one is an error.
'filename.fzp' At line 20
Silkscreen layer should be at the top, not under group copper1
As it says the silkscreen layer should be at the top not under any other group.
'filename.fzp' At line 20
copper0 should be under copper1 not the same level
As it says copper0 should be under copper1 not at the same level.
'filename.fzp' At line 20
Too many layers, there should only be copper1 then copper0
There is a layer under copper1/copper0 which there shouldn't be.
'filename.fzp' At line 20
Connector connector1pad has no radius no hole will be generated
This has been determined to be a through hole part (as no hole is normal for a smd part) but there is no radius for the pad and thus no hole will be generated which is usually an error.
'filename.fzp'
This is a smd part as only the copper0 view is present but it is on the bottom layer, not the top.
Smd parts should normally be on the top side of the board so this is most likely an error.
'filename.fzp' At line 20
Copper0 and copper1 have non identical transforms (no transforms is best)
There is a transform in one or the other of the copper layers but not the other. What this breaks is moving a component from the top of the pcb to the bottom in inspector. The order of the transforms changes as does the scaling making the part wrong on the pcb. Ungrouping and then regrouping copper1/copper0 will usually fix this (the ungroup removes the transform).
'filename.fzp' At line 20
terminalId can't be a path as it won't work.
The terminalId can't be of the specified type (currently path, but there may be others that will get added). Unless it has a center such as a rectangle, line, or polygon fritzing won't take it as a terminalId and will default to the center of the svgId which likely isn't what you want. I prefer to use a rectangle of .01in by .01in for terminalID.
'filename.svg'
While looking for connector1pin, Subpart subpart2 has no connectors in the svg
This subpart doesn't have any connectors defined in it and it should.
'filename.svg'
Subpart subpart2 is missing connector connector1pin in the svg
The listed pin is missing in the svg file (it may be defined in another subpart, in which case it will have a warning message there).
'filename.fzp' At line 20
Both terminalId and legId present, only one or the other is allowed.
As the message says, there are two terminal definitions and it must be only one or the other.
'filename.fzp' At line 20
Subpart connector subpart1 has no pins defined
This subpart has no pins defined and it usually needs at least one (there may be cases where this can be ignored though ...)
'filename.svg' At line 20
connector connector1pin isn't in a subpart
This connector isn't part of a subpart groupname and it should be.
'filename.svg' At line 20
Connector connector1pin shouldn't be in subpart subpart2 as it is
The fzp file says this connector should be in another subpart, not this one (at the time this error is issued we don't know what the other subpart is which is why it isn't listed).
'filename.svg' At line 20
Connector connector1pin in incorrect subpart subpart2
This will usually accompany Error 83 above indicating that the connector is in a subpart where it isn't defined in the fzp file. Again, because at this point we don't know where the connector should be, we can't list the subpart it should be in.
'filename.svg' At line 20
subpart label subpart2 is already defined
There is already a subpart with this label in the svg. I'm not sure this error can actually occur. Inkscape won't allow you to set it (but a text edit would), but it may not get through the xml parser as valid xml if you did (but I haven't tested that so far).
'filename.svg' At line 20
Subpart subpart1 isn't at the top level when it must be Following subpart errors may be invalid until this is fixed
While this may be legal in Fritzing, due to the complexity of checking subparts this script only supports subparts of the form:
<g id='shematic' <g id='subpart1'
where schematic is the top level group with the subpart under it. If you have gotten this message the subpart errors that likely follow are may be invalid due to this error. You need to fix this particular error and then rerun the script to find out if there are actually subpart errors present.
'filename.svg' At line 20
File test.fzp has already been processed (software error)
We have already processed this fzp file and should not be doing so again. This indicates a software error of some kind that has duplicated filenames and should not occur.
'filename'
Isn't a Fritzing file and has been ignored in processing the directory
The listed file name is not a fritzing file and has been ignored in processing the directory.
'filename.fzp' At line 20
Text 'some text' isn't white space and may cause a problem
Text is in an unusal place in this file, that may or may not cause a difficulty later. It is worth checking and perhaps removing the listed text from the file to be safe.
'filename.fzp' At line 20
ModuleId 'moduleid'
Doesn't match filename
'filename'
The moduleId doesn't match the file name. Sometimes this is normal (especially with core parts which have extra parts to the moduleId) and as long as fritzing is happy with the part can be ignored.
'filename.fzp' At line 20
No referenceFile found in fzp file
A reference file wasn't found in the fzp file. This is normally the file name of the fzp file, but it not being there isn't known to hurt anything.
'filename.fzp' At line 20
Multiple referenceFile found in fzp file
More than one reference file was found in the fzp file. There is normally only one which contains the filename of the fzp file. Not known to hurt anything.
'filename.fzp' At line 20
ReferenceFile name 'wrong filename'
Doesn't match fzp filename
'right filename'
The reference file name should match the fzp filename but nothing seems to care if it doesn't.
'filename.fzp' At line 20
No Fritzing version in fzp file
Normally a fzp file has the fritzing version that it was created with. Nothing bad is known to happen if it is missing but adding one is a good idea.
'filename.fzp' At line 20
Multiple fritzingVersion found in fzp file
More than one fritzing version has been found. Not known to cause problems but there should only be one version.
'filename.fzp' At line 20
One or more expected views missing (may be intended)
We have at least one valid view, but one or more of the standard 4 are missing. This may be intended for some parts but it is worth checking that you intended to omit some views.
'filename.fzp' At line 20
Tag spice data is not recognized and assumed to be spice data which is ignored (but it might be a typo, thus this warning)
There is a list of the known spice data that this doesn't fall in to so it would be wise to check and make sure it really is spice data (and add the new spice data to the ignore list in this script if so)
'filename.fzp' At line 20
Type female is not male (it usually should be)
Usually (With some exceptions where pins on for instance an arduino board would short other pins on a breadboard and breadboards) the pin type should be male. Worth checking you intended it to be female.
'filename.fzp' At line 20
Key ssvgId is not recognized
The keyword in this connector line is not one of terminalId svgId layer legId or hybrid and is thus likely a typo.
'filename.fzp' At line 20
Value connector2pin doesn't match Id connector3. (Typo?)
The declared connector number doesn't match the number in the connector statement. This is done (connectors out of order) in some parts in core but it is a bad practice and should be corrected although it is not known to harm anything except making the part hard to understand.
'filename.fzp' At line 20
terminalId missing in schematicView (likely an error)
There isn't a terminalId in the schematic connector definition. This will usually be an error, as you want one but it isn't an error because fritzing will use the center of the svgId position as the position of the terminalId (this is rarely what you want though.)
'filename.fzp' At line 20
Empty bus definition, no id (remove?)
There is a bus definition, but no bus actually defined (just a pair). This may or may not interfere with creating schematic-subparts, and isn't really needed unless you want to add a bus. As a result it could be removed to reduce clutter and size.
'filename.fzp' At line 20
Connector connector1pin has a zero height or width and thus is not selectable in Inkscape
While connectors with 0 height or width work just fine, at least in Inkscape they are not selectable by dragging a box around them and clicking on them. Thus you can't easily move them (you need to change their coordinates in the tool bar after selecting them in xml editor). I prefer to use .01in by .01in rectangles for terminals because they will select and move when selected with a dragged square in the gui. Unfortunatly changing the height and width also changes the x/y position, so automatically correcting this will be more complex than just adding a value, so it is left for you to do at the moment.
'filename.fzp' At line 20
More than one svg tag found
This may be perfectly valid (such as multiple name spaces for some reason), but it is unusual enough to note in case it isn't intended.
'filename.fzp' At line 20
Height attribute missing
This should probably be an error as I don't think it will work, but there is no height attribute in the viewbox definition.
'filename.fzp' At line 20
Height 200px is defined in px in or mm is a better option (px can cause scaling problems!)
While this is perfectly legal, it is unwise (but common!). If defined in px (and either no units or an explicit px is in px) fritzing will make a guess (and sometimes get it wrong) about how many px per inch the drawing used. Older Inkscapes (0.91 and older) used 90px per inch as of 0.92 they use the CSS standard of 96px per inch. Older copies of Illustrator used 72px per inch. If you change this to being inches or millimeters, there is no guess required, and it will scale correctly. To do so in Inkscape do an edit, select all, and set the toolbar to inches or mm. Take the height and width (inches or mm) from the toolbar readout and use XML editor to set those numbers into the height and width in the viewbox setting (with 'in' at the end to indicate this is in inches). When you set them, Inkscape will change the drawing to match the new scale. Note it is possible some part of the drawing may not change correctly, so visually check it. This is usually the cause of a drawing that looks correct in Inkscape but is on the wrong scale (i.e. doesn't match the grid) in fritzing. To correct that, in Inkscape you can recalculate the scaling like this:
heightpx * 72/90/96 = size in inches.
You will need to try the likely values 72, 90 or 96 til the scaling in Fritzing is correct and then set the correct value in inches (or mm if you prefer) as the height and width in the first entry in xml editor.
'filename.fzp' At line 20
copper1 layer should be at the top, not under group copper0
If the second group is copper0 this is normal (or at least harmless) as the order doesn't really matter. However for smd parts the single copper layer needs to be copper1 so it is preferable to be copper1 followed by copper0.
'filename.fzp' At line 20
This appears to be a pcb svg but has no copper or silkscreen layers!
As the message says there is no image data here at all which is likely an error (as the layer is defined in the fzp file).
'filename.fzp' At line 20
Already have a layerId
There is a second (or more) layerId in a view that only allows one layer id. Likely an error.
'filename.fzp' At line 20
Key key_value value '-inkscape-font-specification 'Droid Sans, Normal' is invalid and has been deleted
This is the typical value that I have seen. The lxml parser appears to object to the leading - in the value. This warning is here in case at some point something less ignorable than this gets found here.
'filename.fzp' At line 20
Font family 'ArialMT' is not Droid Sans or OCRA This likely won't render in Fritzing
Fritzing only supports fonts Droid Sans or OCRA so this likely won't be rendered in Fritzging. If you really need this particular font you need to convert it to a path in your svg editor (but that is a pain to anyone trying to modify your part and thus undesirable).
'filename.fzp' At line 20
Silkscreen layer should be above the copper layers for easier selection in pcb view
If silkscreen is below the copper layers then part selection will favor the silkscreen layer making part selection more difficult. Moving the silkscreen layer before the copper layers will fix this.
'filename.fzp' At line 20
Apparant nested tspan which fritzing doesn't support If your text doesn't appear in Fritzing this is probably why
As noted nested tspan don't work in Fritzing at least sometimes, in fact tspan is not supposed to work but usually does.
'filename.fzp' At line 20
Fritzing layerId silkscreen isn't a group which it usually should be
This is a warning because (at least for silkscreen, don't know about the others) Fritzing will accept a path as the silkscreen (although it can only have one element and a group would be a better bet).
'filename.fzp' At line 20
name gnd present more than once (and should be unique)
This id is duplicated in another name or description field. It is a warning in this case because dups here (unlike connectors) are not typically fatal. The part file format document does say they should be unique though.
Modified:
These messages document the changes made by the script to the input files. Note the line numbers refer to the input file (which will be usually in the filename.svg.bak file) as the output file has been prettyprinted which changes the line numbers. As a result you need to look at the input file at the line of the change and then search for that text in the output file to find the area of the change.
'filename.fzp' At line 20
File test.svg has already been processed but will be processed again as part of this fzp file in case of new warnings.
This svg file is likely shared by several parts. One downside of this is that the original of this file won't be in the .bak file as that will be replaced by the version from the last processing output. It is processed again in case there are errors relative to this fzp file that are different than the first processing instance. Because sometimes iconView is copied from breadboard (which would trip this warning) and because we don't actually check anything in icon view icon view processing from the fzp is skipped.
'filename.fzp' At line 20
Removed px from font-size leaving 3.5
Removed the px from font-size="3.5x" because Fritzing objects to the px on the font-size and sets the font-size to 0 when the part is edited.
'filename.fzp' At line 20
Connector connector0terminal had a zero width (or height), set to 10 Check the alignment of this pin in the SVG
As it says, a 0 length height or width was set to 10 which may causee the location of the terminal to change. You need to verify (and move if necessary) the location of this terminal in the svg. You may also need to adjust the size of the terminal to be 10 thou as the size of 10 may not be correct depending on scaling and translates.
'filename.fzp' At line 20
Silkscreen, converted stoke/fill from white or not black to black
Notification that we have changed the color of the silkscreen layer in the svg from white (or not black) to black for both stroke and fill.
'filename.fzp' At line 20
ReferenceFile
'filename.svg'
doesn't match input file
'filename1.svg'
Corrected
Notification that the reference file was updated to be the same as the file name of this svg file. Nothing much appears to care whether this field is correct or not.
'filename.fzp' At line 20
Converted style to inline xml
A style command such as
style="fill:none;stroke:#787878;stroke-width:9.72220039
has been converted to the equivelent xml:
fill="none" stroke="#787878" stroke-width="9.72220039"
(which prettyprinting will then break down to one element per properly indented line changing the output line numbers substantially) because fritzing (specifically bendable legs) does not support the style command syntax even though it is legal xml and Inkscape will convert the inline xml to a style command to be CSS compliant.