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.
Please attach a test file.
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
Created attachment 127982 [details] addition attachment to comment 2 addition attachment to comment 2 test_pic_rotate.ods
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
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.
** Please read this message in its entirety before responding ** To make sure we're focusing on the bugs that affect our users today, LibreOffice QA is asking bug reporters and confirmers to retest open, confirmed bugs which have not been touched for over a year. There have been thousands of bug fixes and commits since anyone checked on this bug report. During that time, it's possible that the bug has been fixed, or the details of the problem have changed. We'd really appreciate your help in getting confirmation that the bug is still present. If you have time, please do the following: Test to see if the bug is still present with the latest version of LibreOffice from https://www.libreoffice.org/download/ If the bug is present, please leave a comment that includes the information from Help - About LibreOffice. If the bug is NOT present, please set the bug's Status field to RESOLVED-WORKSFORME and leave a comment that includes the information from Help - About LibreOffice. Please DO NOT Update the version field Reply via email (please reply directly on the bug tracker) Set the bug's Status field to RESOLVED - FIXED (this status has a particular meaning that is not appropriate in this case) If you want to do more to help you can test to see if your issue is a REGRESSION. To do so: 1. Download and install oldest version of LibreOffice (usually 3.3 unless your bug pertains to a feature added after 3.3) from http://downloadarchive.documentfoundation.org/libreoffice/old/ 2. Test your bug 3. Leave a comment with your results. 4a. If the bug was present with 3.3 - set version to 'inherited from OOo'; 4b. If the bug was not present in 3.3 - add 'regression' to keyword Feel free to come ask questions or to say hello in our QA chat: https://kiwiirc.com/nextclient/irc.freenode.net/#libreoffice-qa Thank you for helping us make LibreOffice even better for everyone! Warm Regards, QA Team MassPing-UntouchedBug
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!
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)
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)
I will have a look at it.
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.
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.
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
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.
Dear Mr. Henschel, thak you very much for fixing the bug. In the meanwhile I could tested in Version: 6.1.5.2, Build-ID: 1:6.1.5-3+deb10u5 the rotation of the picture. Congratulate, the problem is now solved. Best regards, Dirk