Add option to preserve scale/rotate/translate instead of converting to matrix()

[Bryce Harrington]

I'm drawing SVG manually, but I'm using Inkscape for the job since it shows me how the outcome is immediately. However, I have one problem. When modifying/creating a "transform" attribute, and entering something like "scale(-1,1) translate(-100,-100)" into it, it is automatically converted into "matrix(-1,0,0,1,100,-100)". This is probably done because it is more economical, but it bugs me, because I, as a human, find it a lot easier to see transformations as steps (i.e. scale like this, then translate like that) instead of a matrix transformation.

Please tell me there is a way to stop Inkscape from doing this. I want to keep my transformations just like I enter them.

In Inkscape Preferences under Transforms, there is an option to store transformation as Optimized or Preserved. If Preserved is selected, Inkscape will retain the original x,y etc. values and store translation/scale/rotation changes into a matrix. However, this is not as helpful as it could be, since if one wishes to manually edit the SVG later, you have to decipher the matrix values. Instead, if Preserved is selected, Inkscape ought to always output the transform matrix broken down into scale(), translate(), and rotate().

[Bryce Harrington (bryce)]

This was originally Question 20632 (https://answers.launchpad.net/inkscape/+question/20632) by Alexander Krivács Schrøder.

[Alexander Krivács Schrøder (alexschrod)]

It's not always enough to convert the matrix back into scale/translate/rotate, as there may be more than one of each on any given transformation.

As an example, you might want to move, scale, then move some more. That will leave you with two translates, but when "matrixed" and then converted back, you'll only have one. It'll do the same thing, sure enough, but it will have lost information.

My suggestion, seeing how SVG is XML and you already have your "inkscape" namespace in there, is to leave the "transform" attribute alone as it is, and create, say, an inkscape:transformMatrix attribute that you can store your internal matrix representation in. That way, one gets to keep ones separate transformations, and Inkscape gets its (I suspect) quicker parsing and calculation advantages.

Of course, since SVGs could be edited out of Inkscape, you'd have to recalculate those inkscape:transformMatrix attributes whenever a document is loaded, but I think that's what you do when you load a document anyway, except that you replace the original transforms instead of storing the calculation elsewhere.

[pareshchaudhary (chaudharyparesh1986)]

How to generate new coordinate using transform(a,b,c,d,e,f) parameter with old coordinate.

Anybody have any Equation.

[Magnes (magnesus2)]

This matrix thing is really problematic when parsing SVG generated by Inkscape - it's hard to get x, y, angle from matrix and position of the element...

[George Chriss (gschriss)]

Anybody find a convenient way to find 'x0, y0 ,x1, y1, angle' as per comment #4? If so, Inkscape would become a really helpful tool in providing hOCR data based on manually-entered text w/ original-document overlay/underlay (e.g., "OCRing" historical documents where automatic methods would perform poorly).

See also:

The hOCR Embedded OCR Workflow and Output Format / Thomas Breuel (editor)

http://docs.google.com/View?docid=dfxcv4vc_67g844kf

[Patrik Wenger (paddor)]

Please provide a way (like an option on the document) to decompose `rotate(a,x,y)` into `translate(x,y) rotate(a)`. We use SVGs as a way to position icons on larger SVG documents and later parse those positions out to display those icons dynamically on a web application. When some icons need to be rotated as well, this method breaks down completely because Inkscape doesn't encode these transformations in a straightforward way.