translate problem with importing the attached smd file

[davidperrenoud]

From daniel.t...@ixds.de on October 20, 2010 12:54:20

a

Original issue: http://code.google.com/p/fritzing/issues/detail?id=1274

[davidperrenoud]

From irasc...@gmail.com on November 01, 2010 01:04:19

no file attached

[davidperrenoud]

From irasc...@gmail.com on November 03, 2010 16:18:54

The problem is that the connector rects are lined up incorrectly when the SVG is placed on a one-sided board. The connector rects are correct when the board is two-sided. So the problem is with the function that does the SVG flip. Any of the Electrolytic SMD Capacitors currently exhibit the behavior.

[davidperrenoud]

From irasc...@gmail.com on November 04, 2010 05:39:19

This turned out to be quite complicated and there were a couple of bugs (now fixed) and two deeper problems.

The first deeper problem is that a transform that applied to a given layer was placed outside the layer, for example:

<svg ...>
  <g transform="translate(6.3779525,-1015.866)"  id="g3651">
    <g id="copper1">
...
</svg>

The SvgSplitter should handle this eventually, but for now, the fix was simply to move the tranform:

<svg ...>
  <g id="g3651">
    <g transform="translate(6.3779525,-1015.866)" id="copper1">
...
</svg>

The two affected files were SMD_elko_0807.svg and SMD_elko_1010.svg.

The second deeper problem may be a bug in Qt. The way you apply a transform (like a flip) to an object is you apply the transform to the center of the object. We find the center of the object by using QSvgRenderer::boundsOnElement. In those same two files, an internal transform had moved the bounds to a negative offset, but boundsOnElement returned an offset of zero (ish). By contrast, a positive internal transform seems to result in the bounds starting with a positive offset. Further investigation is needed to determine whether this is indeed a bug or not.

So at that point, I gave up and removed the negative translation by hand from the xml.

The conclusion that I continually come to is that it is only possible to use Inkscape for producing parts in a very controlled way, and that subsequent xml hand-editing is almost always required. In the long run we either need to provide our own SVG editor, or become contributors to the inkscape project and add in a "Save as Fritzing SVG" option, which will be a combination of removing all the inkscape/sodipodi metadata (as in the current "Save as plain SVG" option) but which would also flatten all the transforms (not so easy); and appropriately set up the svg's width, height, and viewbox.

Status: PartlyDone
Owner: irascibl
Cc: -irascibl daniel.t...@ixds.de

[davidperrenoud]

From irasc...@gmail.com on November 04, 2010 06:16:57

It would be possible to roll our own version of boundsOnElement, and if I thought that was the last point of misunderstanding between inkscape and fritzing, then maybe rolling our own svg editor would be unnecessary. But I suspect there will be other problems...

[davidperrenoud]

From irasc...@gmail.com on November 04, 2010 06:19:26

Labels: Component-Parts

[davidperrenoud]

From brendan....@gmail.com on November 04, 2010 09:24:56

A bunch of this functionality for undoing tranlates, rotates and matrices is already in src/svg/svgflatterner.cpp. I had to work through that mess to get Gerber export to work since gerber only has a primitive notion of transforms. I have not looked deeply enough to see if that would work. I know there were some cases that were not implemented. Might be one cheap way to clean up some of the inkscape mess.

[davidperrenoud]

From irasc...@gmail.com on March 17, 2013 01:49:10

Cc: -andre.knoerig@gmail.com -daniel.t...@ixds.de

[failiz]

This may still be relevant and probably not addressed yet. "The second deeper problem may be a bug in Qt. The way you apply a transform (like a flip) to an object is you apply the transform to the center of the object. We find the center of the object by using QSvgRenderer::boundsOnElement. In those same two files, an internal transform had moved the bounds to a negative offset, but boundsOnElement returned an offset of zero (ish). By contrast, a positive internal transform seems to result in the bounds starting with a positive offset. Further investigation is needed to determine whether this is indeed a bug or not." Change the title of the issue?

[KjellMorgenstern]

We have perpared several improvements for the svg handling, one that collects transforms along the tree, and one which correctly calculates matrix transforms for combinations of translate, rotate, scale and mirror. Since this issue does not provide means to confirm or falsify, I just assume that those improvements will also cover this issue.