Rules for parts svg


#1

Mostly for @vanepp, but also anyone else who has experience:
Peter: you are the man with the svg versus qt versus Fritzing experience. Can you please give me up-to-date details you are aware of, where the SVG from the latest Inkscape can be bad for Fritzing and / or export to fab please? We talked about this a long time ago. What I want to do is write a Fritzing specific SVG filter for inkscape so one can load pretty much any SVG and it can then just be saved in the right format, including collapsing group transforms where possible and converting to 96dpi etc. Any checking / conversion scripts you have written would also be useful.
I am then going to try and create a front-end to inkscape that manages the part e.g. creates the fpz file. The idea is to create an advanced Fritzing editing tool without re-inventing the wheel.


#2

Good timing :slight_smile: I’m just about to start that very discussion with the feetzing folks (you may want to join the slack discussion group just to keep up with what is going on) so this will be good practice for me.

Most all of this is encoded in the parts check script at

so feel free to swipe anything useful from there (as I believe Inkscape is written in python and uses lxml so the stuff should port).

That said it is hard to read so here are the ones I remember:

  1. px in font-size. CSS requires it Fritzing screws up and sets the font size to 0 when edited, so remove the px from font size.

  2. Document height / Width in px. Fritzing guesses which of the many standards are in use (72dpi for early illustrator, 90 dpi for inkscape < 0.9.2 I think, 96 dpi for Inkscape >=0.9.2) so height/width in inches or mm is preferred (the script bitches about this but doesn’t change it) because Fritzing often guess wrong and screws up the scaling.

  3. Inline style commands. Bendable legs can’t deal with style commands, so the style statements need to be inlined. (script automatically does this)

  4. the gerber generation code doesn’t do inheritance, so the script “inherits” stroke-width (the only one that has bitten me so far) in pcb view to keep gerber happy. That only matters if you optimise the xml in Inkscape, but for performance reasons (less text == better performance) that is desirable.

  5. transforms are evil in general, (performance issue), but deadly in copper1/copper0 as changing sides of the board will change rendering in the gerber in incorrect ways. Again the script currently only warns about this as I don’t yet know how to remove transforms (it is on my todo list though).

  6. in pcb view pads that are ellipses are bad, they will not generate a hole in the gerbers. The script also complains about paths (which is sometimes a false positive, because a path with an appropriate circle will work, I just haven’t fixed up the script to deal with it yet). Rescaling is a common cause of this.

  7. tspans are potentially fatal (and of no use I’ve seen , but that’s just me :slight_smile: ). The latest Qt asserts on tspans maybe only in subpart parts. This is why I did the update to your 40x parts, the tspan was blocking a working compile of the Fritzing code. The update went through a few days ago but I haven’t had time to test yet.

  8. This one the script (other than my development version) doesn’t bitch about yet: Scaling. The parts format document calls for a scale (in Inkscape 0.9.2.4) of 10.41667 (I expect an artifact of the 96dpi) which gives drawing units of 1000 of an inch. A consistent scale makes automatic part checking significantly easier and I think is worth enforcing. Current parts are all over the map. I convert any that I work on and would like to do all of core at some point.

  9. Just about forgot, although it is a data issue rather than strictly xml, pin numbers should start at 0 and be contiguous. If they aren’t contiguous (which most of the arduino parts aren’t and thus many others as well) the hover over a pin and the description comes up function sometimes breaks. It appears to do a lookahead and predict the next pin, and if it is wrong provides wrong data. This is actually a code bug I think. The script complains if pin numbers are not contiguous. Probably not something for the plugin though. On my todo list is allow the script to renumber the pins, although that has implications for current sketches that need to be worked out.

I think that may be all the fatal ones (I may have missed a few though). Nice to have (and things I’m working on adding to the script):

  1. reduce the precision of the numbers. This is mostly a performance issue in terms of storage space and processing. Longer numbers take disk space and I/O bandwidth which in large scale (such as the proposed cloud version of Fritzing) are important. There is no practical difference to Fritzing between 5 and 4.9999978 which python fp rounding likes to produce. Truncating to 3 significant digits shouldn’t hurt (note the weasel words :slight_smile: ). This may make no practical difference, as I don’t have measurements yet.

  2. as noted remove transforms. I believe that a transform implies a matrix multiplication at render time. Removing the transforms at svg save time essentially pre compiling the transform is the same as removing a fixed variable from the body of a loop which can have huge performance gains. I’m actually suprised this isn’t done by default by all editors so there may be something I’m missing here.

  3. convert paths to simpler shapes, i.e. change a line rendered as a path in to a line. I expect a line is easier to render than a path, and easier improves performance (as with all of this, measurement needs to be done to see if there is really a saving and how large compared to the effort to do it). Again this is a pre process at compile time rather than run time type issue. The theory being you compile much less than you run.

With all this said, I’m not sure the Inkscape plugin is needed yet. The Freetzing folks look to be leaning towards first redoing parts editor in javascript. I’ve only just joined the groubrp because I know nothing about javascript and couldn’t make heads nor tails out of the initial release of their code, so decided I was more of a burden than a help. I have been convinced to help out with the parts definition side of things as I do have useful knowledge there. If this project succeeds even if it is only as far as parts editor, that may make the Inkscape plug in not needed, as the checks can be done in the new parts editor for all svg editors or if I can get development running again (which is looking more hopeful lately), we can fix the problems in the Fritzing code again for all editors not just Inkscape. The discussion going on on github is useful because it is turning up a few former developers which if we can keep the contact up, will be invaluable. My main problem is not knowing anything about the code assumptions, I have to trace using gdb to try and figure out what is happening, and there is currently no one to ask.

Peter