transform attribute created by Union not removed by Optimize

[Brynn]

Hi Friends,
This is first reported in Inkscape Community forum: https://forum.inkscapecommunity.com/index.php?topic=754.0

When performing a Union, a transform attribute is created. When the units are mm, the value is scale(0.26458333).

For the user, this results in dimensions with many decimal places. The many decimal places cause the gcode to be massively larger amount of code. (Please read the thread for details which I don't completely understand. Also additional screenshots.)

When the units are pixels, the transform attribute value is translate(0,352.36218). This is all over my head, as to why mm gives a scale value and px gives a translate value. But with px, I don't see the large amount of decimal places (in fact zero decimal places). (Unfortunately, the user is restricted to using mm.)

Another intersting note. (Well, interesting to me....) As soon as the unioned object is moved, even by 0.001, the transform attribute disappears. That happens with both px and mm.

Attaching the test file provided by the user. I've reproduce on Windows 7 Pro, 64-bit, Inkscape 0.92.2 stable, 7z package. The user reports Windows 10 and Inkscape 0.92.2

Let me know if you need any additional info.

Thanks :-)

[TylerDurden (8thrule)]

The transform is applied to accommodate the scale of 1uu/mm. The transform would not be applied if the scale were set to 3.77953/uu (=96dpi). (See bug https://bugs.launchpad.net/inkscape/+bug/1670913)

Gif demonstration here: https://dl.dropbox.com/s/7eno6jty00zr5au/2017-09-11_10-28-24.gif

The transform is retained because Inkscape will not change xml that is not "touched" with an edit. Nudging the transformed object up and back removes the transform and optimizes the path nodes in the xml.

I'd say the bug is that the transform is not removed/optimized after the boolean operation, nor is it removed when the document is saved.

WRT the user's gcode, this is likely a bug in the user's CAM application. Testing variations with and without transforms; with scale = 1uu/mm and scale = 3.77953uu/mm using SheetCam shows no variation in gcode.

Image of gcode comparison (generated with Sheetcam):
https://dl.dropbox.com/s/vo39lpzhog7gdj0/TextPad_2017-09-11_11-02-22.png

[opinion]
Starting with scale=1uu/mm as the default.svg has revealed the issue, but continues to create user confusion. Suggest default.svg be packaged with 1uu/px for releases and let users change display units to other (mm, in, etc) if desired.
[/opinion]

TD

[Brynn (brynn4inks-deactivatedaccount)]

Yes, I've made the suggestion to the user to try a diffrent gcode tool, because that behavior seems odd to me as well.

I agree about the user confusion. Speaking for myself only (although I suspect others are in the same boal) I'm having a hard time helping other users because I don't understand the Scale setting. I suspect it's something that I could understand, if it were presented more clearly. It could be just a different name for that option would help. Is it possible that "Scale" means "DPI"? Or Scale changes the DPI? (I mean, what the heck is a "user unit"? Couldn't we just have "units"?)

So TD, are you saying that if the user changed the scale, the transform attribute would not be created? I posted a link to this report earlier, but I'll post a hint to read it again.

Thanks :-)

[TylerDurden (8thrule)]

The user would likely benefit from setting the default.svg document properties such that display units = mm and scale = 3.77953. For new documents, this should prevent the transform attribute from occurring (which seems to be a source of confusion and could possibly interfere with the user's particular CAM application).

There is no simple way to explain the way Inkscape handles the 90/96 changes and the subsequent effects, so that discussion should take place elsewhere.

I will mark this as bug confirmed, specifically with regard to the transform attribute remaining despite the preferences set to optimized.

TD