Description: Boxes containing text rotated 90 deg, which should read vertically (bottom to top) is shown upside-down. Steps to Reproduce: This originated from the "Picture Accent List" tempalte from "SmartArt" in PowerPoint. An attachment will be added to show the effect. Actual Results: The text at the left of each block appears upside-down Expected Results: That text should be vertical Reproducible: Always User Profile Reset: No Additional Info: -
Created attachment 160571 [details] sample PPTX showing bad behavior The texts "Area 1", "Area 2", "Area 3" should be vertical.
Created attachment 160572 [details] Comparison of PowerPoint vs Impress rendering See the "Area 1"... texts. Also the "Content" text renders incorrectly, but not rotated, with a seemingly wrong bounding box. And you may ignore the wrong letter "C" which is probably a different bug.
This may be related to or a duplicate of Bug 127437 and/or Bug 104430.
Reproduced in Version: 7.0.0.0.alpha1+ Build ID: 86bc13248c1d9f63b10aac304bdf0361d1dcc47f CPU threads: 4; OS: Linux 4.19; UI render: default; VCL: gtk3; Locale: en-US (en_US.UTF-8); UI: en-US Calc: threaded Version: 5.2.0.0.alpha1+ Build ID: 5b168b3fa568e48e795234dc5fa454bf24c9805e CPU Threads: 4; OS Version: Linux 4.8; UI Render: default; Locale: ca-ES (ca_ES.UTF-8) Version: 4.3.0.0.alpha1+ Build ID: c15927f20d4727c3b8de68497b6949e72f9e6e9e Version 4.1.0.0.alpha0+ (Build ID: efca6f15609322f62a35619619a6d5fe5c9bd5a)
*** Bug 132896 has been marked as a duplicate of this bug. ***
(In reply to Alvaro Segura from comment #2) > See the "Area 1"... texts. Also the "Content" text renders incorrectly, but > not rotated, with a seemingly wrong bounding box. The "Content" text rendering incorrectly has been addressed with current head Version: 7.2.0.0.alpha0+ / LibreOffice Community Build ID: 5bd90f7f5852056342f1a81a1285b474d468eadd CPU threads: 8; OS: Linux 5.10; UI render: default; VCL: gtk3 TinderBox: Linux-rpm_deb-x86_64@86-TDF, Branch:master, Time: 2021-01-17_18:20:32 and back to Version: 7.0.5.0.0+ Build ID: 44d17f8feca372acd41142d1b607d3360282bf30 CPU threads: 8; OS: Linux 5.10; UI render: default; VCL: gtk3 TinderBox: Linux-rpm_deb-x86_64@86-TDF, Branch:libreoffice-7-0, Time: 2021-01-07_07:37:59 The "Area" text labels being rotated incorrectly, so the core of this issue, still applies.
The diagram layout has an additional text rotation (txXfrm) with the same angle as the shape rotation. Apparently PowerPoint uses only the shape rotation. When it saves the file, the additional angle in the txXfrm attribute is removed. Currently LO uses both the shape rotation and the text rotation.
How was the file created? I cannot create such file using PowerPoint. I use "Picture Accent List". But the contained <txXfrm> elements do not have any rotation.
As explained in the first post, using said template from SmartArt. But it was an old Power Point version, maybe newer versions don't behave the same. The template has these 3 blocks, each with the left side having vertical text, and bullet points at the right side, plus placeholders for an "icon" image for each block. The 3rd "icon image" (with a letter C) was manually rotated in PowerPoint. The raw image file containing a rotated C (a "U"-like shape).
[Automated Action] NeedInfo-To-Unconfirmed
Confirming for Version: 7.5.0.0.alpha0+ / LibreOffice Community Build ID: 61f5c991a97de8990badfed6ef840941b5aa8c7f CPU threads: 8; OS: Linux 5.18; UI render: default; VCL: gtk3 Locale: en-US (en_US.UTF-8); UI: en-US Also per comment #6 and comment #4.
In the meantime I could reproduce the problem using the SmartArt "Trapezoid List". It seems, that it is not possible to manually change the value of the 'rot' attribute of element <txXfrm>. But PowerPoint generates it on opening the document from the shape rotation in the <dgm:layoutDef> element in layout.xml. I have ask Microsoft, whether my assumption is correct, and waiting for an answer now.
There something inconsistent with the attached file. When I save it with PowerPoint, which regenerates the drawing.xml part, the text directions will be correct in my current build. But the 'C'-image rotation is still missing. Microsoft told me, that the drawing.xml part gives the last state of the diagram. The diagram is always recreated from layout.xml and data.xml on file opening and any manually changes in diagram.xml will be lost on opening the file. In theory LibreOffice could use the layout.xml and data.xml to generate the diagram, but currently the shape definitions from drawing.xml are used in addition. I have no solution for the attached file.
Saving the file again in PP and opening it then with LO 7.3.5, the text is still upside down (180-deg rot.). But it might be a different build and a different PP. Regarding the "C", I have observed that in LO Impress if I select that image (after ungrouping) and rotate it with the mouse, only its rectangular "frame" rotates, but the contained bitmap remains "upright". (upright in this case means the C looking like a U because the bitmap is like that). I think I observed that in the past: images remaining upright even when rotated. Can it be a limitation or bug in LO?
(In reply to Alvaro Segura from comment #14) > Saving the file again in PP and opening it then with LO 7.3.5, the text is > still upside down (180-deg rot.). But it might be a different build and a > different PP. For the then corrected text you need a daily build. That is a LO 7.5. > Regarding the "C", I have observed that in LO Impress if I select that image > (after ungrouping) and rotate it with the mouse, only its rectangular > "frame" rotates, but the contained bitmap remains "upright". (upright in > this case means the C looking like a U because the bitmap is like that). I > think I observed that in the past: images remaining upright even when > rotated. Can it be a limitation or bug in LO? I had not noticed that, but it explains, why in my test the 'C'-image rotation was missing. The image is not imported as image but as rectangle with the image as background fill. And because a background does not rotate together with the shape in LibreOffice, the 'C' has no rotation.
Still reproducible in Version: 7.6.0.0.alpha0+ (X86_64) / LibreOffice Community Build ID: 81ced283de2d0da377225afeb589b793716238bd CPU threads: 8; OS: Linux 5.10; UI render: default; VCL: gtk3 Locale: de-DE (es_ES.UTF-8); UI: en-US Calc: threaded
Created attachment 184927 [details] How it looks in LibreOffice 7.6 master
Still reproducible with the latest LO 7.6 dev master: Version: 7.6.0.0.alpha0+ (X86_64) / LibreOffice Community Build ID: 2478d4b1a4cec495f1bf68f1e62c01031cdeec86 CPU threads: 4; OS: Windows 10.0 Build 19045; UI render: Skia/Raster; VCL: win Locale: fa-IR (fa_IR); UI: en-US Calc: threaded The rendering is different from the rendering in the previous LO versions, but it is still incorrect.