SCH DC Power: wires from the center of the connectors

[failiz]

The wire should connect at the end of the connector, not at the center

[mMerlin]

Curious. I confirm the symptom (both plus and minus connectors), but when I check dcpower2.fzp and dcpower.svg, I find that the terminalIds are defined in the correct locations. They are the old zero width and height, but that just causes issues when trying to edit the svg with Inkscape. It SHOULD still work.

[vanepp]

There are a couple of issues here. The power svg has both height and width set to 0 which never worked. However as of 0.9.6 height or width of 0 no longer works. I modified a 6pin dip so connector0terminal is h0 w0 connector1terminal is h10 w0 and connector2terminal is h10 w10. This is that part on 0.9.9 (0.9.6 is the same!)

and the 3 pins in Inkscape

then the part in 0.9.3b where connector0 still doesn't work, but connector1 and 2 do.

I expect the best solution here is to fix up parts factory to set both height and width on all drawing elements which will fix this (although the dcpower svg will need a manual update.

[failiz]

There are several parts with terminalIDs with height or width set to 0.
For example, this command finds several of the:
grep -ri " width=\"0\"" |grep "terminal"
Just a few examples:
Some examples:
SparkFun_Stepoko_schematic.svg
sim928A_sim928A_schematic.svg
sx1509-breakout_schematic.svg
TB6612FNG Breakout v11.svg
xlr_neutrik_nc3maah_schematic.svg
SparkFun_CAN-Bus_Shield_schematic.svg
sparkfun-sensors_camera_sfv24r-2st_schematic.svg
sparkfun-connectors_50-pin-centronics_schematic.svg
sodaq_mbili_rev4 (4)_schematic.svg
IC40.svg
Arduino-BLE-LowPower-RevB-final_5_schematic.svg
pinoccio-proto_schematic.svg

We could fix all these parts (with a script) or we could make a change in Fritzing´s code to be able to handle them correctly. Any preferences?

[vanepp]

"We could fix all these parts (with a script) or we could make a change in Fritzing´s code to be able to handle them correctly. Any preferences?"

I'd rather fix the parts (unfortunately we need to check the terminal alignment after the fix because the center can move!) as they won't select if they are 0 height or width in Inkscape which is annoying. Making the code work won't fix the issue in Inkscape.

[failiz]

Could we use a script? I guess that the connectors will move in a predictable way. E.g., I guess that if change the height from 0 to 10, we will need to subtract 5 to the y position to keep the terminal in place.

Should we always use 10 as height or width or do we have to use a different number for different parts?

[KjellMorgenstern]

I'll have a look today if this can be fixed on Fritzing App side, by allowing zero sized boxes as terminals.
For Inkscape, it think that is a bit "you ain't going to need it"... I mean, as long as we don't generate more parts with zero sized boxes, it is unlikely that the already existing svgs are going to be edited in Inkscape that much.

Or is there a source that produces such zero area boxes?

[vanepp]

"Could we use a script? I guess that the connectors will move in a predictable way. E.g., I guess that if change the height from 0 to 10, we will need to subtract 5 to the y position to keep the terminal in place."

We can but there are issues with the viewbox. Here is a generic IC from 0.9.9, things have improved, the width (underlined in green) used (in 0.9.3b for instance) used to be 0, but is now 0.1 so it will select. However if it was 0 and we used a script to resize the terminal to 10 and center it (the box outlined in green) , the start of the terminal would be outside the view box (the vertical red line) and thus be partly truncated when rendered (and sometimes pins or terminals are visible in the part, although they are not in this case!) Trying to readjust the view box may cause positioning issues in Fritzing so it is complicated!

This image is a generic IC from 0.9.9 displayed in Inkscape:

This is a generic IC from 0.9.3b displayed in Inkscape.

Note it won't select in the canvass, and it's width is 0 (which is why the no select) so Kjell looks to be correct this is less of a problem going forward (although I would still like to see core parts cleaned up to not have 0 width pins or terminals!) The mystery part also sets a width of 0.1 in 0.9.9 so it looks like maybe everything in parts factory was corrected when the fix was made.

[mMerlin]

We can but there are issues with the viewbox. Here is a generic IC from 0.9.9, things have improved, the width (underlined in green) used (in 0.9.3b for instance) used to be 0, but is now 0.1 so it will select. However if it was 0 and we used a script to resize the terminal to 10 and center it (the box outlined in green) , the start of the terminal would be outside the view box (the vertical red line) and thus be partly truncated when rendered (and sometimes pins or terminals are visible in the part, although they are not in this case!) Trying to readjust the view box may cause positioning issues in Fritzing so it is complicated!

How often is a terminalId element visible? From what I know, the graphic for the terminalid is normally marked as fill="none" stroke="none". So, as long as Fritzing can find it, it does not matter if it extends beyond the viewbox extents. That is actually a requirement for bendable legs in breadboard view.

it is unlikely that the already existing svgs are going to be edited in Inkscape that much.

Not sure that is true. The current documentation for creating custom parts recommends starting from an existing part that is close. That could easily pickup bad svg files from core parts.