Bug 48342 - FILESAVE skewX and skewY values are not matching the ODF 1.2 spec
Summary: FILESAVE skewX and skewY values are not matching the ODF 1.2 spec
Status: NEW
Alias: None
Product: LibreOffice
Classification: Unclassified
Component: Draw (show other bugs)
(earliest affected)
3.4.5 release
Hardware: Other All
: medium normal
Assignee: Not Assigned
Depends on:
Blocks: 88465
  Show dependency treegraph
Reported: 2012-04-05 09:23 UTC by Friedrich
Modified: 2020-09-13 15:43 UTC (History)
3 users (show)

See Also:
Crash report or crash signature:

Screenshot (127.70 KB, image/png)
2015-01-24 05:03 UTC, vvort
ODG test (8.39 KB, application/vnd.oasis.opendocument.graphics)
2015-01-24 05:04 UTC, vvort
SVG test (1.99 KB, image/svg+xml)
2015-01-24 05:05 UTC, vvort

Note You need to log in before you can comment on or make changes to this bug.
Description Friedrich 2012-04-05 09:23:29 UTC
The ODF 1.2 spec, section 19.228 draw:transform, defines the transform elements "skewX" and "skewY" like this:
--- 8< ---
* skewX(<skew-angle>), specifies a skew transformation by
  <rotate-angle> degrees along the x-axis. 
* skewY(<skew-angle>), specifies a skew transformation by
  <rotate-angle> degrees along the y-axis. 
--- 8< ---
(the bad <rotate-angle>s have been reported to odf-comment ml by me). But LibreOffice (Draw) stores for as skewX and skewY values the radian value, not the degree one. Additionally the angle is given clockwise, not counterclock-wise, like known from the same SVG elements.

Cmp. SVG 1.1 spec, section 7.6 The transform attribute:
--- 8< ---
skewX(<skew-angle>), which specifies a skew transformation along the x-axis.
--- 8< ---
and referenced from this, section 7.4 Coordinate system transformations:
--- 8< ---
* A skew transformation along the x-axis is equivalent to [...]
  [1 0 tan(a) 1 0 0], which has the effect of skewing X coordinates
  by angle a.
* A skew transformation along the y-axis is equivalent to [...]
  [1 tan(a) 0 1 0 0], which has the effect of skewing Y coordinates
  by angle a.
--- 8< ---

What to do about this?
a) Fix the loading/storing code and adapt to the spec, and have all ODF consumers check the producer of the file and work around the wrong skewX/Y value format?
b) Or be pragmatic and (try to) adapt the spec, given that LO and OOo have created lots of documents with the wrong value format? No idea if that is possible.

Either way, this needs to be fixed, if we want ODF to be a good document spec, right? :)
Comment 1 Regina Henschel 2012-06-18 14:02:12 UTC
There is an additional problem, that the skewing with a transformation matrix and setting the skew property gives different results.

Please contact Armin Le Grand. He is already working on this (among a lot of other problems) in his aw080-branch. http://wiki.services.openoffice.org/wiki/Aw080_documentation
Comment 2 QA Administrators 2015-01-05 17:52:29 UTC Comment hidden (obsolete)
Comment 3 vvort 2015-01-24 05:03:09 UTC
Created attachment 112758 [details]

I think we first need to fix matrix() processing.
Here is the tests and screenshot of the problem.
Matrices used:
matrix (1000 0 500 1000 1000 500)
matrix (1000 500 0 1000 1000 2500)
Comment 4 vvort 2015-01-24 05:04:37 UTC
Created attachment 112759 [details]
ODG test
Comment 5 vvort 2015-01-24 05:05:14 UTC
Created attachment 112760 [details]
SVG test
Comment 6 QA Administrators 2016-02-21 08:37:58 UTC Comment hidden (obsolete)
Comment 7 Regina Henschel 2016-02-21 10:43:42 UTC
The error is still present in LO 5.2.

A solution needs agreement with the ODF TC.
Comment 8 QA Administrators 2017-03-06 16:05:01 UTC Comment hidden (obsolete)
Comment 9 danders 2018-11-26 10:01:23 UTC
Still with us in
Imho, the Aw080 branch mentioned above is dead, no commit since 2014.

Fixing this will afaics, make it difficult to be backwards compatible.

But (imvho) it should be possible as a first step to fix the matrix loading as I don't think a matrix transform is ever saved?

Then as a second step, one could switch to saving the matrix transform instead of the current scale, rotate etc.

Third step would be to find backward compatible way to save/load the 'old' tranform format.
Comment 10 QA Administrators 2019-11-27 03:45:27 UTC Comment hidden (obsolete)
Comment 11 Regina Henschel 2019-11-27 15:57:02 UTC
The error still exists in Version: (x64)
Build ID: 800b6f095f95ccfb8a7ba9755292332bf97f97ad
CPU threads: 8; OS: Windows 10.0 Build 18362; UI render: default; VCL: win; 
Locale: de-DE (en_US); UI-Language: en-US
Calc: threaded
Comment 12 Regina Henschel 2020-09-13 15:43:15 UTC
Intension is to change the spec to "radians".