Apache OpenOffice (AOO) Bugzilla – Issue 120530
in draw:transform value rotate the angles are treated as rad but ODF specifies deg
Last modified: 2012-08-13 14:53:16 UTC
Created attachment 78903 [details] A draw:transform of rotate(0.5) is set The ODF 1.2 section 19.228 draw:transform specifies "rotate(<rotate-angle>), specifies a rotation by <rotate-angle> degrees about the origin of the shapes coordinate system." AOO uses the value as having unit "rad". The problem is, that the setting in the standard is reasonable and I doubt, that a change can be achieved. On the other hand there are a lot of documents out, which use the angle in rad.
ALG: The description is wrong, indeed rad is used (0 .. 2pi) which is related closest to draw:transform in it's sense as a transformation matrix. the 'rotate(..)' statement is used for better readability, only. More bad: Just checked, rect with 45deg in UI (thus, rotated left) saved, gives 'rotate (0.7853981633973)'. When decomposing the matrix (which is not written) you would get -0.78 which would be mathematically positive in the screen coordinate system. In short: the API and ODF error is by purpose used here, too, see xmloff/source/draw/xexptra.cxx lines 664 ff (#i78696#). Probably for consistency (can't remember completely) to be able to use the API object rotation directly. See xmloff/source/draw/shapeexport2.cxx ln 196 where the value coming from a matrix decmopose (and being correct, mathematically positive) is mirrored before export. Thus, 'rotate(..)' from draw:transform of 19.228 is: - in rad - negative oriented Where the angle contained evtl. in 'matrix(..)' from draw:transform of 19.228 is: - in the units you get when decomposing it - positive oriented
Unfortunately it is not a simple description but an approved standard and we are not the only application that produces ODF format. So we cannot leave it as that, but need a solution with the OASIS TC or a solution in the code. Suggestion?
ALG: Correct ODF1.2 where needed, describe what the values really are and how they are used currently (practise dictates here). Add better, overruling definitions for ODF1.3, as far close to svg as possible.