Fritzing-Schematic an Inkscape extension - released

Hi all!

I have been working on an extension for Inkscape to create rectangular schematic symbol .svg files for use in Fritzing. I think I created a useful tool to speed up creation of schematic symbols, and now I want to share it with the community.

It’s available on github:

To install:
In Inkscape, the edit menu → user preferences → system will have an option for ‘User extensions’ - allowing you to open the folder to store user extensions in for Inkscape. Simply copy fritzing-schematic.inx and to this directory.

To use:
Start the extension via Inkscape’s Extensions menu option under → Fritzing → Fritzing_Schematic… option. This will open a new window in Inkscape for user input with 2 tabs.

The Schematic Symbol tab is for defining the size of the symbol and the label:

The Schematic Connectors tab is for defining the number of connectors per side of the symbol, pin number/label options and terminalId creation.

Once the settings have been entered, clicking the ‘Apply’ button starts the extension.

If any User Defined option is checked, additional windows will pop open for user input. Once the data is entered, the schematic symbol will be generated.

Thanks to @vanepp for testing a giving feedback during development

Please post questions/problems/feedback here and I will respond.



Works well. I made the schematics for the Dy-sv8f/sv5w/sv17f parts I made a few days ago (using an earlier version of the code.) It has some limitations and I sometimes still use the template files, but it an easy way to get a correct schematic svg.


1 Like

Hey there - I had considered tackling this exact problem using a plugin a couple months ago. Super happy to see you did this. Is it correct to say that it only does schematic view and does not do PCB? Any thoughts on adding PCB support? I think the design pattern there is that 90+% of the parts are a linear line of 0.1" spaced 38mil holes with a 20mil ring and they are either a single line of ‘n’ holes or a dual line (DIP) spaced at 100-400 mils apart at least for through-hole parts. SMT throws a bit of a wrench in there to add that.

I got around to using this a moment ago. Very cool. A couple things:

  • What does ‘terminalIDs’ being enabled do?
  • I think it’s often pretty important to be able to link a pin name and a pin number together. The way this is done, I can tell you how many pins I want on each side but you choose the pin number. I think it would be super valuable to change the dialog to ‘default’ a pin numbering scheme like you did but allow the pin number to be user input. I know this raises issues of pin number collisions and making sure all pin numbers 1-n are used, but I think it’s pretty important.

Last thought on the pin numbers … you could change things up and only ask how many pins total. Then bring up a dialog which has pin numbers 1-n down the left side, in the center you can pick Top/Bottom/Left/Right for the pin and in a 3rd column you input the pin name. Now you always have a proper pin list and the number of pins on each side come from this dialog.


While I’m not Randy I’ll answer anyway. As the name implies, it adds the terminalIds so the wire connects on the end of the pin not in the middle (by the way it should be defaulting to “on” and you should enable it or your svg will be incorrect and FritzingCheckPart will complain about it!)

No. To avoid that you need to select “Pin Numbering User Defined” instead of the default Sequential in the Schematic Connectors pane. The pin numbers need to be in sequential order however so the default Sequential is preferred (and thus the default.) Inkscape will deal with duplicate pin numbers (unfortunately by reverting the previous definition to linexx from connectorxx thus undefining the previous pin, but there won’t be a dup!) There are limitations on what Inkscape will do. There needs to be sufficient space in the initial rectangle for all the pins, or an error message will come up when you define try and define the pins, and that can’t be changed due to an Inkscape limitation (as I understand it, it defines the rectangle and then calls the pin creation code with the rectangle predefined.) I already asked about this when I was testing the plug in for him. PCB and breadboard could be done (and I guess may get done) but they are much more difficult than schematic which is more structured than the other two. For complex schematics I still tend to use my template files and manually edit the svg (but I cheat and have unreleased python scripts that will define the connector boiler plate too), but for the simple ones I use this, as it is easier. For instance the schematic of the CubeCell part I made this morning was done with this extension.


Well, it appears I can’t edit my original post, so I will have to add more information here:

Once the settings have been entered, clicking the ‘Apply’ button starts the extension.

The extension starts at the top most pin on the left side of the symbol, and progresses in a counter-clockwise fashion creating pins. If any User Defined option is checked, additional windows will pop open for user input. Once the data is entered, the schematic symbol will be generated.

Let’s say you want to create a symbol for a SPST relay with 2 connectors on each the left and right sides with user defined Pin Numbering and Pin Labels. After entering that data in the initial dialog and clicking the ‘Apply’ button, additional windows will open to allow entering the pin numbers & labels, like so:

Once finished, the generated symbol on the left side will have 2 pins, the top most pin will have the number ‘5’ and have a label of ‘coil 1’. The 2nd pin will be numbered ‘7’ and labeled ‘coil 2’. The key here is to remember it works counter-clockwise, so when it comes to the right side, you will be prompted to enter numbers and labels for pin#3, which is the bottom most pin on the right side.

One other note:
Every time you hit the ‘Apply’ button, a new schematic symbol is created, but any previously created symbols will not be erased. Only the first created symbol will have a group id = schematic, the other symbols will have a generic group id. I thought about fixing this ‘problem’, but every Inkscape extension the generates a .svg that I looked at behave the same way.

Onto specifics:

Check the latest on github, if you haven’t, I tidied up the code a bit since the last version I sent you. It now checks for sufficient space on all four sides at startup and stops on that error. This way you don’t waste time entering data and then discovering a stupid mistake. Also improved some of the error messages, and I don’t know what else I might have fixed.

Yea, I kinda thought about it, but don’t hold your breathe…


One change that would be useful if possible is to default the Connector terminalIds to always enabled by default. At present is seems to remember the last value set. Here I unticked Create TerminalIds then hit close and closed Inkscape. When I restarted Inkscape and entered the extension again, it remembered that had disabled Create terminalId and has the box unticked. With pins as lines we are normally going to want terminalIds. If it can’t be fixed, then we just need to remember to check the setting!


This is the way it is with Inkscape, it always remembers the last settings made, but this shouldn’t be a problem. If you always want terminalIds, check the box once and never touch it again. I could remove it as an option and just automatically create the terminalIds.

I have also just noticed another problem that is pretty much out of my control and I don’t think I can really fix it. (still thinking it over)

The problem is when you create a symbol and then further edit the text of the symbol. If you change/edit text (like say the symbol label), then move the text around, everything is fine. If you just move the text around (like say a pin number or label) without editing the text, Inkscape slips in a ‘px’ on the font size. This, of course, causes display problems (the font is super-sized) in Fritzing. So for now, any text that is changed or moved, the font size needs to be checked and remove any ‘px’ characters from the font size. This can be done in Inkscape, in the XML Editor, under the Attributes panel.

Two other options exist to fix this problem. First would be to edit the .svg file with a text editor and remove the ‘px’ that way, (think search for “px” and replace with “” ). Second way is to use vanepp’s FritzingCheckPart python script that can be found here:

I will update if I have anything new on this issue!

I agree with Peter that the default should be enabled for terminal IDs and I’m not sure why you’d want to allow it to be turned off. Is there an advantage somehow?

I’m still struggling with the pin ID / terminal assignment gig though. But given that Peter hasn’t complained about it, maybe I’m off base (he’s the pro) …

In this example, pin 2 is on the left but because of the order of the UX, this pin winds up being connector1pin and my gut says that this will make it confusing at least - when the user imports the .svg file for the schematic, they’ll need to do the terminal assignments game in the upper right of the screen and the fact that the connector*pin numbering is different than the pin numbers. Am I wrong, Peter?

I think this is probably the way to go. With lines as the pins we always want terminalds (otherwise the X access will be offset from the grid by 0.05in.) The only case where we may not want terminalIds is if the pin is symmetrical and even then a terminalId won’t hurt.

I think the best option here is to use Inkscape wants to add the px because CSS requires it, and is likely to be hard to suppress in Inkscape. As a bonus the breadboard, pcb and fzp files get checked for correctness as well by CheckPart.

With the warning that I don’t usually use parts editor, I don’t think you will need to do the terminalId assignment, it is already done in the svg and Fritzing will be happy with that. Pin2 is always connector1 because Fritzing starts connectors at 0, and real parts typically start at pin1, so it is normal for the pin number to be one less that the Fritzinz connectorId. Parts editor has a bug that it sometimes skips pin numbers getting them out of sequence but I don’t think that is what is happening here. I assume you must have done user selected pin numbers in this image because when I do it with sequential set for pin numbering it works as expected (starts with pin 1 on the right side and increases around the square to match standard DIP IC numbering.) The connectors start from 0 and go to 3 (as opposed to the pin labels which go from 1 to 4.) Here the pin labeled one is to Fritzing connector0:


Well I guess I didn’t test it enough prior! I had forgotten about the zero-referenced terminal/pin gig. But anyway I tested it again and it worked without issue. The issue I prior described about things being out of order or mis-matched was unfounded. Well done - this is really slick.

The advantage is that it is an option. You have a choice, create terminalIds or don’t, and having choices is a good thing. But really, this comes down to a workflow sort of thing. Of all the schematic symbols I’ve created in Inkscape, I never once created terminalIds. It’s too much work in Inkscape to add them, when it can be done in the parts editor with a couple of mouse clicks. Originally, I wasn’t even going to add the creation of terminalIds, but it wasn’t much work to add them in and made the tool more robust.

I think Peter explained this well, but just let me say that this is the way of Fritzing. In Fritzing, grab a Generic IC and drag it into the schematic view, or any view, doesn’t really matter. Edit the part in the parts editor, and choose the Connectors tab. You should see something like this:

Notice how pin1 has an id of connector0. connector0 is the connector0pin in the .svg

Anyhow, I’ll update some info here soon!

1 Like

An update:

Thanks to @vanepp for discovering a small bug in my extension! Basically, if the symbol size is too small and you try to create too many connectors for the bottom, right, or top side of the symbol, the extension will fail. The code has been updated on github.

So head over here: (same link as first post) and grab the latest update.


1 Like