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)
Version:
(earliest affected)
3.4.5 release
Hardware: Other All
: medium normal
Assignee: Not Assigned
URL: https://issues.oasis-open.org/browse/...
Whiteboard:
Keywords:
Depends on:
Blocks: 88465
  Show dependency tree / graph
 
Reported: 2012-04-05 09:23 UTC by Friedrich
Modified: 2022-09-14 11:55 UTC (History)
3 users (show)

See Also:
Crash report or crash signature:

Attachments
Screenshot (127.70 KB, image/png)
2015-01-24 05:03 UTC, vvort 		Details
ODG test (8.39 KB, application/vnd.oasis.opendocument.graphics)
2015-01-24 05:04 UTC, vvort 		Details
SVG test (1.99 KB, image/svg+xml)
2015-01-24 05:05 UTC, vvort 		Details
View All Add an attachment (proposed patch, testcase, etc.)

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]
Screenshot

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 6.0.6.2
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: 6.5.0.0.alpha0+ (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".
https://issues.oasis-open.org/browse/OFFICE-3750
Comment 13 QA Administrators 2022-09-14 03:38:30 UTC Comment hidden (obsolete)
Comment 14 Regina Henschel 2022-09-14 11:55:50 UTC 
There is no progress yet in regard to OFFICE-3750. The problem still exists in LO 7.5, however can only be solved together with the ODF TC.