Created attachment 44000 [details] rotations.odp Downstream bug may be found at: https://bugs.launchpad.net/ubuntu/+source/libreoffice/+bug/505188 1) lsb_release -rd Description: Ubuntu natty (development branch) Release: 11.04 2) apt-cache policy libreoffice-impress libreoffice-impress: Installed: 1:3.3.1-1ubuntu4 Candidate: 1:3.3.1-1ubuntu4 Version table: *** 1:3.3.1-1ubuntu4 0 500 http://us.archive.ubuntu.com/ubuntu/ natty/main i386 Packages 100 /var/lib/dpkg/status 3) What is expected to happen is when one performs at the Terminal: cd ~/Desktop && wget https://bugs.launchpad.net/ubuntu/+source/openoffice.org/+bug/505188/+attachment/1868399/+files/rotations.odp && loimpress -nologo rotations.odp click File -> Save as -> File type: Microsoft PowerPoint 2007 XML (.pptx) -> Save button -> Keep format button -> close file -> reopen via the Terminal: loimpress -nologo rotations.pptx the text is displayed as it was in rotations.odp. 4) What happens instead is that the text in rotations.pptx have been rotated erroneously.
Radek, one for you? Or can you give some pointers to transform it into an easy hack if possible?
I can confirm the effect with "LibreOffice 3.4.1 RC1 - WIN7 Home Premium (64bit) German UI [OOO340m1 (Build:201)]", 90° text and 180° text will be misrotated (0°) after document has been saved as .pptx and reopened in LibO. Unfortunately my Powerpoint Viewer will not open that document, and also my pptx to ppt batch converter fails. OOo-dev 3.4 also showed exported document with rotation 0° Modified Status due to facts
Since all new unconfirmed bugs start in state UNCONFIRMED now and old unconfirmed bugs were moved to NEEDINFO with a explanatory comment, all bugs promoted above those bug states to NEW and later are automatically confirmed making the CONFIRMED whiteboard status redundant. Thus it will be removed.
Ran test on 3.5.0b2 on Windows XP SP3. The result of exporting to .pptx is that the rotations are lost. Moreover, Powerpoint 2003 (with the 2007 filters installed) could not open the file. The result of export to .ppt is complex. When viewed in LOImpress 3.5.0b2 the ppt file looks like: "Text rotated 90" is at -90 "Text rotated 180" is at 90 when viewed in Powerpoint 2003 "Text rotated 90" is at -90 "Text rotated 180" is at 0
Created attachment 55697 [details] example of saved .ppt viewed in PowerPoint 2003.
Created attachment 55702 [details] Example ODP, text about every 45 degrees 3.5.0b2 all tests on Windows XP SP3 1. made an example rotations2.odp with text close to every 45 degrees (manual rotation, so not exactly at that multiple). 2. save as rotations2.ppt 3. open a fresh copy of rotations2.odp, save as rotations2.ppt2 Results: 4. rotations2.ppt text orientation incorrect for 90 and 180 degrees, all others OK. (Could be a coincidence it is right for one of the multiples of 90). File opens OK in MS PowerPoint 2003 and has the same text orientations as in LOImpress. 5. rotations2.pptx file will not open with either PowerPoint 2003 (with 2007 extensions) or PowerPoint 2010. 6. rotations2.pptx opens with 3.5.0b2 LOImpress with all text orientations at 0 degrees. (All text rotation information has been lost).
Attempted to change importance to medium/normal from lowest/trivial. Not sure if that will take or not. This is not a trivial problem - it offers the possibility for LOImpress to corrupt otherwise valid .ppt/.pptx files by just opening and saving them.
Created attachment 55744 [details] Screen shot, only example at 90 degrees is incorrect. Two more observations. 1. With LOImpress 3.5.0b2 made an odp with text at 89,90, and 91 degrees. Saved as .ppt Opened in PowerPoint 2003. Result: Only the text at 90 degrees is flipped, +/- one degree away is good enough to avoid the problem. (See the screen snap). Previous result showed that +/- 45 degrees also not a problem. Suggests that problem is most likely restricted to multiples of 90 degrees. 2. OpenOffice DEV300m106 does not have this problem when it saves to .ppt, rotated text stays at the angle it was set to in OOImpress.
Created attachment 55747 [details] Test .ppt and mangled result 1. mangle.ppt is the original drawing created in PPT 2003 2. open mangle.ppt in LOImpress 3.5.0b2 3. add one word to the slide, outside the diagram 4. save as mangle2.ppt 5. exit LOImpress 6. Open mangle2.ppt in LOImpress or PPT 2003 Result: some of the text which was originally horizontal has rotated to vertical. 3.4.4 release does exactly the same thing. I just went through a .ppt file I had been using to import .pdf (as a way of converting SVG drawings) which had been repeatedly opened in LOImpress 3.4.4. There were numerous examples of mangled diagrams, mostly text originally rotated by 90 degrees now at -90 degrees, and a few cases where the rotation was completely lost (not shown). Some of them were really awful, with text drawn mirrored, possibly the result of multiple cycles of .ppt open/save in LOImpress. (I have not yet reproduced that problem.) Conclusion: it is unsafe to open a .ppt drawing in LOImpress and save it again in that same format. The only safe way to convert (from PDF) through LO is to create a fresh .ppt for each diagram imported and then later move the contents of that .ppt into the main .ppt within Microsoft PowerPoint. The "easy" method, doing that conversion in the complete .ppt opened in LOImpress, results in earlier slides being mangled by later .ppt saves.
OS ALL Due to Comment 2
Since the first file doing bad stuff due to bug 45495 (bad pptx export), the remark with pptx does not longer apply. However, the problems Later filed here still remain: The ppt bug is still there (master 3.7.0, 10.11.2012). and - perhaps - the flipped stuff issue.
Its in filter/source/msfilter/escherex.cxx:692 There, something is wrong with the numbering of the rectangular text orientations. perhaps should be 2's potences? patch coming soon.
cedric: that line 692 comes from commit 24dd42f3 which is from "n#569266 sw-rtf-num-fix.diff:Fixes for RTF numbering export" with comment n#404221. Do we have the original documents behind that commit to see if https://gerrit.libreoffice.org/#/c/1165/ would break them ?
(In reply to comment #13) > cedric: that line 692 comes from commit 24dd42f3 which is from > "n#569266 sw-rtf-num-fix.diff:Fixes for RTF numbering export" with comment > n#404221. Do we have the original documents behind that commit to see if > https://gerrit.libreoffice.org/#/c/1165/ would break them ? We have the documents, but they can't be made public (customer ones). I checked the two bugs and everything is fine. I pushed the fix in gerrit.
Lennard committed a patch related to this issue. It has been pushed to "master": http://cgit.freedesktop.org/libreoffice/core/commit/?id=1f1ebf7d91d1b19c05d7114853ecdc40c8444a6a fdo#34897 numbers were wrong, code unnecessary The patch should be included in the daily builds available at http://dev-builds.libreoffice.org/daily/ in the next 24-48 hours. More information about daily builds can be found at: http://wiki.documentfoundation.org/Testing_Daily_Builds Affected users are encouraged to test the fix and report feedback.
Will it still be necessary to add: if (nAngle==1800) { - AddOpt( ESCHER_Prop_txflTextFlow, <some_half_way_reasonable_txfl_here> ); - } for perfectly upside-down text? Or doesn't that make a problem? by the way, I had to change the ,,magical'' numbers. (the constants had different numbers than the former numbers.) Does RTF need different ones? just without that bSuppressRotation=true;
Lennard committed a patch related to this issue. It has been pushed to "libreoffice-3-6": http://cgit.freedesktop.org/libreoffice/core/commit/?id=6ccbb67d653cb6769fdea7b8170840ace3f8b82c&g=libreoffice-3-6 fdo#34897 numbers were wrong, code unnecessary It will be available in LibreOffice 3.6.5. The patch should be included in the daily builds available at http://dev-builds.libreoffice.org/daily/ in the next 24-48 hours. More information about daily builds can be found at: http://wiki.documentfoundation.org/Testing_Daily_Builds Affected users are encouraged to test the fix and report feedback.