translate problem with importing the attached smd file

[GoogleCodeExporter]

a

Original issue reported on code.google.com by daniel.t...@ixds.de on 20 Oct 2010 at 4:54

[GoogleCodeExporter]

no file attached

Original comment by irasc...@gmail.com on 1 Nov 2010 at 8:04

[GoogleCodeExporter]

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.

Original comment by irasc...@gmail.com on 3 Nov 2010 at 11:18

[GoogleCodeExporter]

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.  

Original comment by irasc...@gmail.com on 4 Nov 2010 at 12:39

• Changed state: PartlyDone

[GoogleCodeExporter]

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...

Original comment by irasc...@gmail.com on 4 Nov 2010 at 1:16

[GoogleCodeExporter]

Original comment by irasc...@gmail.com on 4 Nov 2010 at 1:19

• Added labels: Component-Parts

[GoogleCodeExporter]

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.

Original comment by brendan....@gmail.com on 4 Nov 2010 at 4:24

[GoogleCodeExporter]

Original comment by irasc...@gmail.com on 17 Mar 2013 at 8:49

[GoogleCodeExporter]

Issue has moved to new issue tracker at github. Please continue the discussion 
at https://github.com/fritzing/fritzing-app/issues

Original comment by andre.knoerig@gmail.com on 23 Sep 2014 at 3:37

• Changed state: ToGithub