Poor state of part SVGs

Not sure where to put this - I have placed it under parts help, but other categories would be appropriate.
Basically, having spent a lot of time making / adapting Fritzing part SVGs, I have noticed that we seem to have a number of endemic problems in the parts database. This is about get a lot worse - The latest version of Inkscape is now CSS compliant, i.e. they have changed from a base resolution of 90 dpi to 96 dpi - and that could mean a lot more swearing at SVGs that don’t adhere to the expected dimensions. Our problems to my knowledge fall in to the following categories:

  1. SVGs created with px as base unit (thanks to illustrator)
  2. Part pins and terminals not correctly aligned to breadboard or schematic grid or each other.
  3. Zero sized part terminals (invisible, don’t work).
  4. Group type terminals (even more invisible).
  5. Parts that are wildly inaccurate (mostly thanks to brd2svg being broken).
  6. SVGs with ludicrously nested groups include multiple transforms (thanks Inkscape and Illustrator).
    I am proposing / offering:
  7. to create a set of scripts to detect / fix some of these automatically.
  8. as part of (1), a set of quality control scripts - can be run by a user to check their own scripts and by el-j prior to merging in GIT. Could enforce most of the graphic standards.
  9. we add metadata to indicate whether the part concerned has been checked and/or corrected.
  10. Once Inkscape 0.92 is widespread Insist on 96ppi for new parts to ensure max compatibility.
    I think it may be expedient to convert all existing parts to 96ppi, but that could be a mammoth task.
    I cannot fix 5 - brd2svg is just huge and needs a lot of attention. To illustrate, I converted the Arduino Mega2560 ref design recently - it did not come out at 0.1 pitch or even close, components were out of line, upside down etc. This was using Adafruit’s best fixed build.
    Any thoughts everyone? Anybody know of other widespread issues my scripts should look for?

I’ve started a less ambitious version of this :slight_smile: . My goal is to remove the px from font-size commands, convert silkscreen from white to black, and to convert style commands in parts with bendable leads to inline xml (Fritzing doesn’t accept style in bendable leads). The script is in perl and uses the xml::libxml module (I expect there is a similar one in python but I know perl better) to parse svg files (I confirmed that svg files aren’t regular enough for regular experssions to be enough :slight_smile: ). I started with converting the silkscreen colors from white to black as being simplest to start with (and to learn how to use the libxml module which is almost as poorly documented as Fritzing parts creation :slight_smile: .) What I have discovered so far is that there are three or four parts in core that have invalid xml in them (the libxml parser errors out, but neither Fritzing or Inkscape do, but the xml is obviously invalid on inspection). At present the script can (sloooowly :slight_smile: around 5 hours!) convert the silkscreens from white to black in core pcb svgs and I’m working on the px removal (should be easy) and the style conversion (somewhat more difficult because duplicate attributes such as a font-size inline and in the style break Fritzing if just converted to 2 font-sizes). I’d really like to remove the transforms from at least pcb so that the x y coords are in thou but I have no idea how transforms actually work (other than they change the coordinate system locally) to do that. I’m thinking that a check of the viewbox coords to pin coords (to make sure they are on .1 boundaries would be good addition but again the transforms come in to play and make that difficult (and there may be parts that don’t want to be on a .1 boundary but it could be only a warning message). So I’d suggest that changing the silkscreen color from white to black and changing the style commands to inline xml for at least bendable leads should be added to your list. A check for groups copper0 and copper1 in pcb would probably be a good bet too. I completely agree that a script that at least points out variations from the standards would be very valuable to all of us.

Yeah I know.

1 - Is the 90 dpi to 96 that important. I make everything with inch or mm, and if you look in the svg it is in those units. Does the vector program convert everything back to px. I know it does in INK for text, because that is the standard svgs have to have for the other stuff it was designed for.
2 - Fz snaps to weird stuff at times. The Zener snaps on the middle of the pin, but if you remove the number next to the pin it snaps on the 0.100". It somehow snaps to the number.
3 - Some of those faults are features. A zero stroke node on the end of a pin auto assigns the end of the pin if it’s labeled pin in the svg. Saves time in FZ not having to click a pin, select graphic, and the N,S,E,W or Centre. Look at the Pololu A4988 and it’s red tips in SCH.
4 - BB and SCH are not that important so long as they snap to a 0.100" grid. PCB has to be accurate so things fit, and I’ve seen pins out, but that looks like there person making it didn’t know how important it is.
5 - FZ adds those groups when you export a part, and if you export and import the same image it gets buried in groups.

It’s going to be a lot of work, and I’ve seen these problems in Kicad because parts can be made by anyone, and now that the creators have stepped back, is there any future for FZ. If you ask me the part creation using a complex external graphics editor that isn’t 100% compatible is going to kill FZ in the end.

To give you an example. I’m trying to make a tutorial to standardise part creation, but the first svg that I made won’t mate with the CORE IC perfectly. It works fine using another part, and I have made svg from scratch, but not the CORE part I made it from. I’ve basically spent a whole day to film and edit it and now has a problem, so I’m basically teaching people the wrong way to do it because it only works 90% of the time.

For me Fritzing is the only thing I know of that does what I want (and it does most of what I need now if sometimes with too many steps :slight_smile: ) which is mostly breadboard for documentation of one off projects on perfboard or with arduino or other sbc modules. Even if the development has slowed (or as it appears, stopped) the source is available and we can maybe figure out how to fix some of the problems with enough work. To me that makes it worth continuing to poke at to make it better. I don’t know if we will succeed but we (or I) can at least try.

If you see my videos I only use graphical tools because I don’t have any idea how to code, so it will have to be up to you brainy types.

You can tell what the creators envisioned with FZ, ie help young beginners by providing BB view, because it errors with a single copper1 group because they never thought people would be pushing it to SMD and beyond like we want it to.

It’s encouraging to get so much feedback.
Is the project dead / dying? We have some strong supporters out there, particularly in the Arduino community. We have had a trickle of releases - much better than none. The parts library keeps growing, which is why I think it’s crucial to get these parts scripts, tutorials and standards straight so that the effort snowballs rather than millstones, if you follow.
One small design point I disagree on: accuracy on breadboard can be important. I am working on a robot design with a perfboard base. The parts have to line up correctly and fit together - to do that I have had to redesign the Arduino Mega 2560 board (soon to arrive on Github!).
@vanepp: I am confused regarding silkscreen - I thought the Fritzing standard was black traces on white now?
@Old_Grey : I’ll look at the Pololu part, but I think this is different: e.g. Sparkfun dual op-amp has a number of 0 height by 0 width groups used as terminals; Fritizing just ignores them and connects from pin midpoint instead. Others in the same part are 0.001 x 0.001 and they work.

The silkscreen was white because the dark background in Illustrator made it easier to see. Now that ILL is not free we switched to INK, unfortunately there are a lot of old parts still with white silkscreen still in FZ. The upside of changing it to black is that you can now see what the part looks like in the PCB icon in Inspector, rather than just a number of contacts.

I think those zero nodes might be a Eagle conversion - Eagle adds tons of junk -.

Ardiuno don’t run a 0.100" pin spacing on all pins, so it won’t fit prefboard

So I was correct; the silkscreen should now be black lines on white background?
The sparkfun part came via illustrator, so double junk really. The fact that they are in the correct position for terminal nodes and marked with the correct ids (connector1terminal) surely would suggest they were added for use in Fritzing though? or does EAGLE use a similar means?
The Arduino sits on stand-offs above the perfboard. The Arduino pins fixing holes are aligned to 0.05 - some fixing points therefore have to be drilled exactly mid between holes or between tracks on perf board, but that’s bearable. The pain was that the pins on both ICSPs were completely off, as were the USB and power connector. This might explain why there was no ‘with icsp’ variant of the part, which I needed for mating with the shields I am making parts for. The power and USB and overall footprint have to be accurate because space on the perf board is limited - I need to know everything will fit.
I corrected by going back to the original .brd, converting and exporting / importing just the key holes via DXF. Once I’ve finished the schematic view I’ll buzz the results up here.

Yes that is the current standard. As noted many of the parts in core still have white silkscreen (in fact generic IC still has white silkscreen!). In Inkscape with the white background you don’t see the silkscreen.

I don’t know, it looks dead to me for various reasons (no reply from developers to offers to translate to different languages, no apparent code checkins) which may not mean anything it may just be taking time. As noted, even if the developers have other priorities we have the source and can if we choose carry on. I for one am interested in doing so (and agree accuracy on breadboard is valuable to me as well as I rarely make boards).