Environment:
Fedora 24
x86_64
Fritzing Version 0.9.2 (b8d2d5970658f0bed09c661c9
I have not upgraded to 0.9.3, since trying to stay with what is provided in the Fedora repos.
It appears that the svg export does not handle connector terminal rectangles that are part (children) of the view (breadboard in this case) layer. During export, the “rect” element is replaced by “g” element with the same attributes, with values adjusted for scaling. For example, with a breadboard svg file containing
<!-- origin is the bottom row of pins on 0.1 inch grid -->
<rect width="2.7" x="0" y="0" height="2.7" id="connector0terminal"/>
The exported breadboard view svg file contained
<!-- origin is the bottom row of pins on 0.1 inch grid -->
<g width="2.16" x="0" y="0" id="connector0terminal" height="2.16"/>
Removing id=“connector0terminal” from the rect element (and putting it elsewhere) worked correctly, exporting
<!-- origin is the bottom row of pins on 0.1 inch grid -->
<rect width="2.16" x="0" y="0" height="2.16"/>
Either of the versions look and work correctly in the Fritzing view. It is just the export as SVG that gets messed up.
While I haven’t used 9.2 (newby using 9.3) the usual reason for this in 9.3 is the lack of a breadboard group in the svg. The svg export function is the only thing I know of that this affects. You might try (in an svg editor such as Inkscape) edit->select all (to select the whole drawing) then object->group to make a new group and change the group id to breadboard (which will at least in Inkscape rename the current breadboard id if it exists) and try that and see if it fixes it.
Both versions of the svg file have the id=“breadboard” group, the fzp file specifies that for the layer, and the element in question is a child of the breadboard group. It is just that single element that does not make it out to the view svg export file. The rest of the graphics (also child elements of the breadboard group) export fine. There is some interaction specifically with the connector0terminal id attribute.
Guessing that Fritzing is using elements linked to the fzp terminalId attributes internally, and something in that is messing it up for the export.
Yep 9.3 shows the same problem (the pin 1 tip is missing in the exported svg). From Inkscape it appears to me that the connectors are not in group breadboard, so I ungrouped everything (which also removes the translates which I dislike) and regrouped it in to a overall breadboard group. That exports as a blank screen so I’m not as smart as I think I am. I’ll poke at it some more but it looks like an upgrade to 9.3 isn’t an easy fix (which I hoped it may be).
I’ve been doing some exploring on parts creation, and are far as I can tell, the elements referenced by svgId and terminalID attributes in the fxp file do not need to be in the same group / on the same layer as specified for the layer attribute. Fritzing finds them regardless, when working in the Fritzing views. If they are not child elements of the layer element, then they will not export to the view SVG. Which is no problem when they are invisible anyway. However, I think that it should be valid to have them in the layer, and they should then also export and display. In this case that is not true. I do not have a sample handy, but I think had it working for the svgId elements. They export correctly as long as they are child elements of the layer element. But this test says that the terminalId elements do not. At least in the breadboard view.
I have some suspicion you are correct, but figured I’d try it and see if it fixed it (the breadboard layer missing entirely is the fault I know of and that isn’t the case here). Your fpz file has a full 14 pins defined (I think) which are not in the svgs which usually causes problems and schematic (which I hadn’t looked at before) is odd (it has an oddly named active pin on the top left labeled 0.11 in in a square and is missing the relay contacts although the pins for them are present and appear active). I’ll continue poking and see if I can do anything. Perhaps some of our better parts makers will have some suggestions as well.
I’m only defining 8 pins, but there are gaps in the numbering, so that the numbers actually used match the pin numbers for the same location on a 14 pin DIP.
That square is from a template file. It is intended to be a 0.1 inch square reference object while editing, then should be deleted. I have not got that far with this part yet. What I think you saw was the labelling for the square on top of the actual “1”.
OK, I don’t know what the original problem is (I suspect you deleted something on pin 1 you shouldn’t have). I started again from a generic 14 pin IC and deleted the unused pins (you were correct I was looking at the pin numbers in the fpz not the actual count of pins) and this one (from 9.3 though) appears to export all the pins correctly to an svg from breadboard. Because I used the pin label field, the label from the fpz file is being used on the part (its possible that is part of the problem too) so you would need to change the label field in the fpz if you don’t want the trailing relay on the IC body (or remove the label id from the text and see what happens ). Note if you are using Inkscape (as I am) that you need to edit the svg after saving it in Inkscape and use a text editor to delete all the px s from the svg file. Fritzing will set the font size to 0 after a parts edit if there is a px on the font size (and Inkscape loves them).
Your version is not really exporting connector0terminal correctly. It looks right, but that is only because your connector0pin rect element is the same color, and completely overlaps the connector0terminal element. Here is an extract from the exported svg file. Delete/move/hide the connector0pin element, and the foot is gone again. Or change the fill color of the connector0terminal. It does not show up.
I am doing my editing with an xml aware text editor. Which is the reason I like (and manually created) the transform attributes. It allows me to position a group with transform, then have nice clean multiples of 0.1 inch for all of the element coordinates. And for repeating patterns, I can simply copy/paste, then add a group wrapper around the second copy with an appropriate transform offset. Typically also with multiples of 0.1 inch offsets.
For the rest, the part is a work in progress. Other things are still expected to change. Reported the problem at the stage it was discovered in. I’m working around the problem by keeping the connector«n»terminal graphics separate from the element that controls the snap coordinates used by Fritzing. My working version has the connector«n»terminal elements set to invisible, and outside of the breadboard element. I was trying to collapse them into a single visible element. Which failed.
Then there is a good chance you have uncovered a bug that hasn’t been noticed because the standard part essentially masks it. As long as Fritzing likes your transforms (it appears to have ceased to understand current Illustrator transforms and corrupts alignment on svg made with illustrator) you should be fine.
). Note if you are using Inkscape (as I am) that you need to edit the svg after saving it in Inkscape and use a text editor to delete all the px s from the svg file. Fritzing will set the font size to 0 after a parts edit if there is a px on the font size (and Inkscape loves them).