Bug 103092 - FILESAVE: Calc: wrong position for rotated pictures to 270 degree after save
Summary: FILESAVE: Calc: wrong position for rotated pictures to 270 degree after save
Status: RESOLVED FIXED
Alias: None
Product: LibreOffice
Classification: Unclassified
Component: Calc (show other bugs)
Version:
(earliest affected)
5.1.4.2 release
Hardware: x86-64 (AMD64) Linux (All)
: medium normal
Assignee: Regina Henschel
URL:
Whiteboard: target:6.5.0 target:6.4.0.1 target:6.3.4
Keywords: bibisectRequest, regression
Depends on:
Blocks: Calc-Images
  Show dependency treegraph
 
Reported: 2016-10-10 14:44 UTC by dirk
Modified: 2019-11-21 19:28 UTC (History)
2 users (show)

See Also:
Crash report or crash signature:


Attachments
Test file (65.36 KB, application/vnd.oasis.opendocument.spreadsheet)
2016-10-12 16:48 UTC, m.a.riosv
Details
addition attachment to comment 2 (67.52 KB, application/vnd.oasis.opendocument.spreadsheet)
2016-10-13 06:58 UTC, dirk
Details
tar zipped file (337.56 KB, application/gzip)
2016-10-13 07:05 UTC, dirk
Details

Note You need to log in before you can comment on or make changes to this bug.
Description dirk 2016-10-10 14:44:11 UTC
1. Open a new spreadsheet and insert a picture at cell C3, anchor at cell 
 2. edit the rotation of that picture to 270 degrees
 3. move that picture/anchor to cell C3
 4. write protect the pictures position and size
 5. safe the spreadsheet to xxxx.ods
 6. open that spreadsheet again an the picture was shifted to the left hand side, also the anchor was shifted too!

Build-ID: 1:5.1.4-0ubuntu1 and using the german package.

Here the content.xml file without rotated picture.
<draw:frame table:end-cell-address="Tabelle1.C43" table:end-x="126.57mm" table:end-y="2.98mm" draw:z-index="0" draw:name="Bild 1" draw:style-name="gr1" draw:text-style-name="P1" svg:width="125mm" svg:height="176.73mm" svg:x="1.59mm" svg:y="2.36mm"><draw:image xlink:href="Pictures/10000201000002E80000041C5A7B6FEDA0C5356C.png" xlink:type="simple" xlink:show="embed" xlink:actuate="onLoad">

Here the content.xml file after rotated picture.
<draw:frame table:end-cell-address="Tabelle1.C42" table:end-x="142.89mm" table:end-y="0.93mm" draw:z-index="0" draw:name="Bild 1" draw:style-name="gr1" draw:text-style-name="P1" svg:width="125mm" svg:height="176.73mm" draw:transform="rotate (-1.5707963267949) translate (178.9 3)"><draw:image xlink:href="Pictures/10000201000002E80000041C5A7B6FEDA0C5356C.png" xlink:type="simple" xlink:show="embed" xlink:actuate="onLoad">

I'm not sure, but it seems to me, the decimal point is not correct in the line "rotate (-1.5....) translate (178.0 3)">.....

For further information please contact me by email.
Comment 1 m.a.riosv 2016-10-12 12:07:11 UTC
Please attach a test file.
Comment 2 m.a.riosv 2016-10-12 16:48:18 UTC
Created attachment 127976 [details]
Test file

Hi dirk, pasted you answer here, please for future comments add them here.

---------------------------------------------------------------------------
Hello,

thank you very much for your response.
The test_pic.ods is the file who the picture is inserted as zero (0) degrees. See the screen shot test_pic.png.
Then the picture was rotate to 270 degrees and moved to cell C3. Then saved as test_pic_rotated.ods. Screen shot test_pic_rotate_save.png. File closed.
After reopen the file test_pic_rotated.ods I have got the screen shot test_pic_rotate_open.png.
If you're open the file test_pic_rotated.ods you should get the same result as shown in screen shot test_pic_rotate_open.png.

Hopefully the bug is comprehensible.

Best regards,
Dirk Barty

PS:System: Linux 4.4.0-42-generic #62-Ubuntu SMP Fri Oct 7 23:10:22 UTC 2016 i686 i686 i686 GNU/Linux
    Ubuntu 16.04LTS, Intel® Core™2 Quad CPU Q8400 @ 2.66GHz × 4,

Am 12.10.2016 um 14:07 schrieb bugzilla-daemon@bugs.documentfoundation.org:
> m.a.riosv changed bug 103092
----------------------------------------------------------------------------

Reproducible.
Win10x64
Version: 5.2.2.2 (x64)
Build ID: 8f96e87c890bf8fa77463cd4b640a2312823f3ad
CPU Threads: 4; OS Version: Windows 6.19; UI Render: GL; 
Locale: es-ES (es_ES); Calc: CL
Comment 3 dirk 2016-10-13 06:58:19 UTC
Created attachment 127982 [details]
addition attachment to comment 2

addition attachment to comment 2
test_pic_rotate.ods
Comment 4 dirk 2016-10-13 07:05:22 UTC
Created attachment 127983 [details]
tar zipped file

tar.gz zipped file including:
  test_pic.png
  test_pic_rotate_save.png
  test_pic_rotate_open.png
Comment 5 dirk 2017-04-06 10:30:42 UTC
Considering that the 270 degrees rotated pictures moves her position it could be the reason for this may be the fact of incorrect settings in the metric system of measurement.

A potential source of errors is the value of millimeters:
Under Tools/Options/LibreOffice Calc/General/Metrics/Measurement unit: Millimeter will be move all 270 degrees rotated pictures in an Calc-Document after safe and reopen.

And this is how it worked:
Change the value from milimeters to centimeters!
Under Tools/Options/LibreOffice Calc/General/Metrics/Measurement unit: Centimeter the 270 degrees rotated pictures will not be move after safe and reopen.
Comment 6 QA Administrators 2018-04-07 02:39:20 UTC Comment hidden (obsolete)
Comment 7 dirk 2018-04-09 13:42:53 UTC
Now I have tested the rotation bug with the latest Libreoffice Version: 6.0.3.2 and the bug is still present!

Under spreadsheet/tools/options/libreoffice calc/general/metrics changed the measurement unit: from centimeter to millimeter. After opening a spreadsheet with rotated pictures they are no more on her defined cell position.  Mostly it has been moved left.

Please check Comment 5!
Comment 8 QA Administrators 2019-04-10 02:58:55 UTC Comment hidden (obsolete)
Comment 9 dirk 2019-04-18 12:18:28 UTC
Dear QA Team,

Today, I have tested the rotation bug with the latest LibreOffice_6.2.2.2 (LibreOffice_6.2.2_Linux_x86-64_deb.tar.gz) and the bug is still present! 

Although the issue has become a little less dramatic.
 
Because, after changing from centimeter to millimeter the picture moved not so far as usually. The anchor of the picture has still moved inside the cell to the start point of the cell. And not as before, where the picture left the valid cell.

In this way, we may already be able to pinpoint the bug by changing of general metrics.(spreadsheet/tools/options/libreoffice calc/general/metrics)
Comment 10 Regina Henschel 2019-11-08 00:19:56 UTC
I have tested the problem with setting Calc to use Millimeter as unit.
There error happens on file save. In case of a rotation, the position is not written directly as svg:x and svg:y but it is put into a translation(x y).
The parameters x and y of the translation should have a unit. But LibreOffice does not write a unit. In case a unit is missing LO interprets the values as 1/100mm on opening. But it has written the values as 1/10mm.

In case Calc is set to use Centimeter, the unit mm is written to the parameters a and y and the shape is at the correct position after opening. Tested in Version: 6.4.0.0.alpha1+ (x64)
Build ID: 7c6226bee72805db7f0e567ca9f06c786a7d0da2
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

So I would say, your initial observation "the decimal point is not correct" is right.

It is an old error.
OK in Version 4.0.1.2 (Build ID: 84102822e3d61eb989ddd325abf1ac077904985)
but already broken in Version: 5.1.0.1.0+
Build-ID: 928a7a3e92e085a880ecf0d3ad5e40d41b7779bf
CPU Threads: 8; OS Version: Windows 6.2; UI Render: default; 
TinderBox: Win-x86@62-merge-TDF, Branch:libreoffice-5-1, Time: 2016-01-13_00:08:26
Gebietsschema: de-DE (en_US)
Comment 11 Regina Henschel 2019-11-12 01:55:30 UTC
I will have a look at it.
Comment 12 Commit Notification 2019-11-18 13:23:15 UTC
Regina Henschel committed a patch related to this issue.
It has been pushed to "master":

https://git.libreoffice.org/core/commit/58ee73068fa881950e42cca22ed17cf5829b8d14

tdf#103092 export uses MeasureUnit not FieldUnit

It will be available in 6.5.0.

The patch should be included in the daily builds available at
https://dev-builds.libreoffice.org/daily/ in the next 24-48 hours. More
information about daily builds can be found at:
https://wiki.documentfoundation.org/Testing_Daily_Builds

Affected users are encouraged to test the fix and report feedback.
Comment 13 Commit Notification 2019-11-18 20:33:28 UTC
Regina Henschel committed a patch related to this issue.
It has been pushed to "libreoffice-6-4":

https://git.libreoffice.org/core/commit/bbfcada38c71ca8f0adf779e9fb66d577683ad71

tdf#103092 export uses MeasureUnit not FieldUnit

It will be available in 6.4.0.1.

The patch should be included in the daily builds available at
https://dev-builds.libreoffice.org/daily/ in the next 24-48 hours. More
information about daily builds can be found at:
https://wiki.documentfoundation.org/Testing_Daily_Builds

Affected users are encouraged to test the fix and report feedback.
Comment 14 Regina Henschel 2019-11-21 14:01:02 UTC
Fixed 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 15 Commit Notification 2019-11-21 19:28:51 UTC
Regina Henschel committed a patch related to this issue.
It has been pushed to "libreoffice-6-3":

https://git.libreoffice.org/core/commit/e8997a95f8f06a32d32124c55897138ac0fe840d

tdf#103092 export uses MeasureUnit not FieldUnit

It will be available in 6.3.4.

The patch should be included in the daily builds available at
https://dev-builds.libreoffice.org/daily/ in the next 24-48 hours. More
information about daily builds can be found at:
https://wiki.documentfoundation.org/Testing_Daily_Builds

Affected users are encouraged to test the fix and report feedback.