The problem doesn't just affect the parts connections though, it creeps in to bend to bend lines too.
The parts here are code generated - we could get at least those right. For the rest, I would be more than willing to write some python or java code to go through and bulk correct the majority of the parts. and perhaps even strip out unneeded transformations. The code could check the alignment of every connector, and if the connector is by a small enough %age, correct it. Otherwise it would flag a warning. We could include a parts checking function to check for the various other gotchas.
Inside of Fritzing could we have an 'arrange to grid' function, that re-snaps all the parts and bends to the grid?
Going forward, rather than re-inventing the wheel with our own parts editor, I feel a better approach would be for a developer like myself to get some much needed enhancements done to Inkscape. My custom parts are a little over the top, and I like having Inkscape's feature set. What is missing is a) a usable scripting engine / extension architecture in Inkscape (current efforts all fall far short somewhere) b) a plug-in or scripts for Inkscape using that architecture to automate most of what we do for parts in Fritzing. We could automate the whole round trip process - Launch Is from within Fz, create / edit the SVG for the part, then save it straight back in to the part in Fz.
IIRC Inkscape currently has at three attempts at automation -
1. Feature where a script, invoked by the user via the Inkscape menus, written in a-n-other language (you can use almost any), is fed a temporary copy of the SVG (or creates it from scratch) and then feeds the result back to inkscape. Some libraries are available in Python and Perl (I think?) to help munching the SVG, but none of Inkscape's functionality is available in the scripts, not even a notion of which shapes are selected. You are pretty much on your own.
2. DBUS based architecture allowing an external program to interact with Inkscape. Very much limited largely to Linux and I think a WIP.
3. Command line shell. This is two sides to the same feature. Firstly Inkscape has a long list of command line options including access to many of the editing 'verbs' (see 2) available within the program. The secondly you can start Inkscape in 'shell mode', feed it the equivalent of the command line commands via stdin, interpret the responses via stdout and feed it more commands. In theory, this has the beginnings of half of what we need. Unfortunately 1) it's full of bugs 2) the biggest bug prevents it entering GUI mode while being driven from the shell, making it non-interactive and making most of the verbs unavailable 3) the design is one pass at a file currently, i.e. the file does not persist from one command to the next (but the bugs do) 4) we would still need generator scripts within the program, which suffer the current limitations.
I would be more than willing to help push some improvements here, including the coding. It will not be easy; unlike you guys, the Inkscape team are not open to outsiders, even those who have something to offer. In fact, they are damn right rude. Which is a real shame; it is one of my favourite products.