Bug 98565 - FILEOPEN draw:transform="scale()" acts wrongly on line, polyline and path
Summary: FILEOPEN draw:transform="scale()" acts wrongly on line, polyline and path
Status: RESOLVED FIXED
Alias: None
Product: LibreOffice
Classification: Unclassified
Component: Impress (show other bugs)
Version:
(earliest affected)
Inherited From OOo
Hardware: All All
: medium normal
Assignee: Regina Henschel
URL:
Whiteboard: target:7.0.0
Keywords:
Depends on:
Blocks:
 
Reported: 2016-03-09 19:37 UTC by Regina Henschel
Modified: 2020-01-21 00:11 UTC (History)
2 users (show)

See Also:
Crash report or crash signature:


Attachments
package with three test documents (31.80 KB, application/x-zip-compressed)
2016-03-09 19:37 UTC, Regina Henschel
Details
package with screenshots of correct rendering (37.76 KB, application/x-zip-compressed)
2016-03-13 22:02 UTC, Regina Henschel
Details

Note You need to log in before you can comment on or make changes to this bug.
Description Regina Henschel 2016-03-09 19:37:48 UTC
Created attachment 123444 [details]
package with three test documents

The attached package contains three file, one for draw:line, one for draw:polyline and one for draw:path.

The document has an object draw:rectangle in light blue and second object draw:rectangle in dark blue with the same attributes as the light one and an additional attribute draw:transform=scale(3,1).

The document has a line in black and second line in yellow. Here too the objects have the same attributs and the yellow on has an additional attribute draw:transform=scale(3,1).

The lines are defined in a way, that their corners lay on the corners of the rectangle.

Expected behavior: The objects are scaled in x-direction in the same way, so that after applying the scale transformation, the corners of the scaled line still lays on the corner of scaled rectangle.

Observed behavior: The rectangle is scaled as expected, but the line is not scaled, but only shifted.

Scaling is always done with the origin as fix point, therefore the rectangle not only becomes 3 times wider, but the distance to the y-axis is 3 times larger too.
Comment 1 Regina Henschel 2016-03-09 19:46:25 UTC
It is correct in AOO CWS aw080 (owner Armin.Le.Grand@me.com)
Comment 2 Cor Nouws 2016-03-09 20:23:10 UTC
also see issue 94319 ?
Comment 3 Regina Henschel 2016-03-09 20:49:10 UTC
I think bug 94319 is different. 
(1)
The problem does not occur, when LO produces content. LO does not write scaling to file format. Besides when opening such file, you will see similar problems, when working directly with macros and matrices on the objects.
(2)
The copy&paste failure is a regression, but the draw:transform problems are very old. I have corrected the version field.
Comment 4 Buovjaga 2016-03-13 19:17:16 UTC
So to test, we don't have to do anything, but just observe how the files look?

Would be nice to get screenshots of an incorrect result in LibO and correct result in AOO.
Comment 5 Regina Henschel 2016-03-13 22:02:49 UTC
Created attachment 123546 [details]
package with screenshots of correct rendering
Comment 6 Buovjaga 2016-03-14 07:19:32 UTC
Confirmed the wrongness inside the Blue 2 rectangles.

Win 7 Pro 64-bit Version: 5.2.0.0.alpha0+
Build ID: b89feb8018bf3610faf01e73995d576f6566e20b
CPU Threads: 4; OS Version: Windows 6.1; UI Render: default; 
TinderBox: Win-x86@39, Branch:master, Time: 2016-03-07_03:36:17
Locale: fi-FI (fi_FI)
Comment 7 QA Administrators 2017-05-22 13:19:36 UTC Comment hidden (obsolete)
Comment 8 Regina Henschel 2017-05-22 17:40:00 UTC
The error still exists in Version: 5.4.0.0.alpha1+
Build ID: 965494c544dd8f35ae83b7cf38549009da06c367
CPU threads: 4; OS: Windows 6.1; UI render: default; 
TinderBox: Win-x86@62-TDF, Branch:MASTER, Time: 2017-05-10_23:06:27
Locale: de-DE (de_DE); Calc: group
Comment 9 QA Administrators 2018-05-23 02:36:45 UTC Comment hidden (obsolete)
Comment 10 Regina Henschel 2018-05-23 21:09:56 UTC
The error still exists in Version: 6.1.0.0.alpha1+ (x64)
Build ID: 88051c660fc6759346a01bc559818d3e23f8f55c
CPU threads: 8; OS: Windows 10.0; UI render: default; 
Locale: de-DE (de_DE); Calc: CL
Comment 11 QA Administrators 2019-05-24 02:56:28 UTC Comment hidden (obsolete)
Comment 12 Regina Henschel 2019-05-24 11:17:43 UTC
The error still exists in Version: 6.3.0.0.alpha1+ (x64)
Build ID: 115ab48f86d4e3c6eede49767df1ee5a82b4ab22
CPU threads: 8; OS: Windows 10.0; UI render: default; VCL: win; 
TinderBox: Win-x86_64@62-TDF, Branch:master, Time: 2019-05-20_17:50:30
Locale: en-US (en_US); UI-Language: en-US
Calc: threaded
Comment 13 Regina Henschel 2020-01-04 23:49:25 UTC
Not duplicate, but needs to be fixed together with bug 98584.

The error here is, that width and height of a polygon-shape is only based on svg:width and svg:height. Additional scaling in a draw:transform attribute is ignored.

The problem becomes visible, when import of draw:transform value skewY is fixed (bug 98584). A vertical shearing is replaced by using a suitable rectangle, shear it horizontal and then rotate it. This rectangle is different from the original rectangle given by svg:width and svg:height and therefore produces an additional scaling in the transformation matrix.