Description: FritzingCheckPart.py is a python script which checks parts files for use by the Fritzing EDA program (fritzing.org). It started out 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 in to 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 postprocessed fritzing svg files, because it understands their format and has modified the xml (mostly moving CSS style commands in to inline xml which as a side effect makes prettyprinting easier), to better suit fritzing. A standalone script PP.py, is included which will prettyprint a xml document without doing any of the fritzing related conversions. Installation: The script uses python3 and the lxml library extensions to python. Since Fritzing runs on Windows, linux and MacOS X the script should run on those platforms too, and it may. I don't have MacOS X so I don't know that it will run there (although there is no reason that it shouldn't, I just haven't done it.) On Windows: 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 (cygwin.org) using 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 On Linux (Ubuntu 16.04 LTS): copy the py scripts to /usr/local/bin via sudo: sudo cp FritzingCheckPart.py /usr/local/bin sudo cp FritzingTools.py /usr/local/bin sudo cp PP.py /usr/local/bin sudo cp PPTools.py /usr/local/bin chmod ugo+x /usr/local/bin/*.py The Ubuntu install appears to have lxml and python 3 already installed Note the script has problems with unicode under python 2.7 and probably won't run there without modification (which I don't know how to make). Testing: 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) ... Normal use: PrettyPrinting: 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 in lines such as attribute="value" attribute="value" in to attribute="value" attribute="value" with appropriate indenting. Since this is meant for post processed Fritzing svg file 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. FritzingCheckPart.py There are several modes (selected internally by the number and type of the arguments to the script.): 1) 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. 2) 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. 3) 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. 4) 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;attirbute:value) commands to the equivelent inline xml attirbute="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 succcessfully) 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 that have a zero height or width. These are not selectable by Inkscape making them difficult to move in the svg. Unfortunatly you need to manually change the size (which changes the position) and then move the teriminal 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 modifiying a 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). Configuration: There are four internal configuration settings (you need to edit the listed .py file and change these with a text editor): 1) 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. 2) 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 modifed 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 tool bar which I find 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: Modified 2: File '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 made a change that is going to have moved the x/y position of the connector (and depending on what the scaling in the svg is set to, perhaps made the height/width incorrect, as 10 isn't an appropiate value 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. 3) in file FritzingCheckPart.py IssueNameDupWarning = 'y' This value (enabled by default) if set to 'n' will supress the Warning 28: message which indictes 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'. 4) in file FritzingCheckPart.py Debug = 0 This value enables debug 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 detailied but very verbose debug messages). It is used for debugging the script itself so you will normally leave it at 0 for normal operation. Likely bugs: 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. Known bugs: 1) Makeing a square pad in pcb via a path with a hole in it usually (but apparantly not always) works in Fritzing. This script however will toss Error 74: File '/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 <module> 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 detectd. 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 and you should fix it there and then remove the .bak extension and re run 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 explaination of the errror (with the move of the Usage messages above, some numbers are now missing though.) Error 1: Can not rename filename os_error_message (os_error_number) The os routines returned an exception when the input file was renamed. Hopefully the cause is obvious from the os messages. Error 2: Can not open filename os_error_message (os_error_number) The os routines returned an exception when the input file was opened. Hopefully the cause is obvious from the os messages. Error 3: Can not write filename os_error_message (os_error_number) The os routines returned an exception when the input file was written. Hopefully the cause is obvious from the os messages. Error 4: Can not close filename os_error_message (os_error_number) The os routines returned an exception when the input file was closed. Hopefully the cause is obvious from the os messages. Error 5: ParseFile can't read file filename The xml parser got an I/O error trying to parse the named file. Error 6: ParseFile error parsing the input xml file filename The xml parser found illegal xml at the line and column listed after this. Note the lxml parser is more strict 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. Error 8: filename isn't a file: ignored The file name provided either isn't a file or isn't readable and has been ignored. Error 10: There must be a directory that is not '.' or '..' in the input name 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. Error 13: dst dir 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. Error 14: Creating dir 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. Error 15: Can not rename '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. Error 16: File 'filename' At line 20 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) Error 17: File 'filename' No connectors found for view viewname. This is one of those messages without a line number as after all the connectors have been processed, no connectors were found. Error 18: File '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. Error 19: File '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. Error 20: File '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. Error 21: Svg file '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. Error 22: File '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). Error 23: File '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 busess and schematic parts. Error 24: File '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. Error 25: File '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) Error 26: File '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. Error 27: File 'filename.fzp' At line 20 View name missing We have no viewname (iconView breadboardView schematicView pcbView) which should be present. Error 28: File '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. Error 29: File 'filename.fzp' At line 20 View tag scchematicView not recognized (typo?) View tag isn't one of (iconView breadboardView schematicView pcbView) which it should be. Error 30: File 'filename.fzp' At line 20 No image name present The file name for the svg file is missing in the fzp file. Error 31: 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. Error 32: File 'filename.fzp' At line 20 No layerId value present There is a layerId attribute present, but it has no value (and it needs one). Error 33: File 'filename.fzp' At line 20 View viewname already has layerId layername, layername1 ignored The layerId isn't unique and it must be. Error 34: File '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. Error 35: File 'filename.fzp' Unknown view viewname found. (Typo?) Found a view name that isn't one of iconView breadboardView schematicView or pcbView (probably a typo) Error 36: File 'filename.fzp' No valid views found. Didn't find any of iconView breadboardView schematicView or pcbView in the list of view names. Error 37: File '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. Error 38: File '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. Error 39: File 'filename.fzp' At line 20 Connector has no id A connector has no id associated with it and it must have one. Error 40: File 'filename.fzp' At line 20 Connector has no Name A connector has no Name associated with it and it must have one. Error 41: File 'filename.fzp' At line 20 Connector connector3 has no Type A connector has to have type male or female and has neither. Error 42: File '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. Error 43: File 'filename.fzp' At line 20 Connector connector3 missing view name The connector doesn't have a view name. Error 44: File 'filename.fzp' At line 20 Viewname bbreadboardView invalid (typo?) The viewname isn't one of breadboardView schematicView pcbView and it should be. Error 45: File 'filename.fzp' At line 20 Layer missing The layer attribute is missing in the fzp file. Error 46: File 'filename.fzp' At line 20 No layerId for View SchematicView A layerId wasn't specified for this view earlier in the fzp file. Error 47: 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.) Error 48: File '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. Error 49: File '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). Error 50: File 'filename.fzp' At line 20 Tag svgId is present but has no value The listed tag is present but has no value set. Error 51: File 'filename.fzp' At line 20 svgId missing There is no svgId present for this connector and one is required. Error 52: File 'filename.fzp' At line 20 Bus bus2 already defined There is aready a bus with this id and ids must be unique. Error 53: File 'filename.fzp' At line 20 Bus nodeMember connector2 does't exist The nodeMember specified doesn't exist and it must. Error 54: File '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. Error 55: File 'filename.fzp' At line 20 Subpart has no id The subpart is missing the id field (required) Error 56: File '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. Error 57: File 'filename.fzp' At line 20 Subpart has no label The subpart has not label and it needs one. Error 58: File 'filename.fzp' At line 20 Subpart subpartid already defined (duplicate?) The subpart has already been defined and must be unique. Error 59: File 'filename.fzp' At line 20 Connector id missing, ignored The subpart definition is missing the id field. Error 60: File '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. Error 61: File '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. Error 62: File '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. Error 63: File 'filename.fzp' Connector0 doesn't exist (connectors should start at 0) There isn't a connector0 and there should be. Error 64: File '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). Error 65: File '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). Error 66: File '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. Error 67: File '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. Error 68: File '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. Error 69: File '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. Error 70: File '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. Error 71: File '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. Error 72: File '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. Error 73: File '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. Error 74: File '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. Error 75: File '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. Error 76: File '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). Error 77: File '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. Error 78: Svg File '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. Error 79: Svg File '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). Error 80: File '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. Error 81: File '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 ...) Error 82: File '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. Error 83: File '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). Error 84: File '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. Error 85: File '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). Error 86: File '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. Error 87: File '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. Warnings: Warning 1: File '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. Warning 2: File '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. Warning 3: File '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. Warning 4: File '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. Warning 5: File '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. Warning 6: File '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. Warning 7: File '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. Warning 8: File '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. Warning 9: File '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. Warning 10: File '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) Warning 11: File '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. Warning 12: File '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. Warning 13: File '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. Warning 14: File '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.) Warning 15: File 'filename.fzp' At line 20 Empty bus definition, no id (remove?) There is a bus definition, but no bus actually defined (just a <buses> </buses> 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. Warning 16: File '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. Warning 17: File '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. Warning 18: File '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. Warning 19: File '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 a edit select all and set the tool bar to in or mm. Take the height and width (inches or mm) from the tool bar read out and use xml editor to set those numbers in to the height and width in the viewbox setting (with the 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 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. Warning 20: File '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. Warning 21: File '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). Warning 22: 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. Warning 23: File '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. Warning 24: File '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). Warning 25: File '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. Warning 26: File '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. Warning 27: File '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). Warning 28: File '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. Warning 29: File '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. Modified 1: File '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. Modified 2: File '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. Modified 3: File '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. Modified 4: File '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. Modified 5: File '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 complient.