Created attachment 178886 [details] Sample slide (PPTX as saved by LibreOffice) How to reproduce: 1. Open document (in PPTX format) in LibreOffice 2. Save document (in PPTX format) 3. Open just saved document in Office 365 4. Observe how the title color changed from white to black and also how the second line of the paragraph is indented a bit more. Version: 7.4.0.0.alpha0+ / LibreOffice Community Build ID: be1aab8632ead65d75c0436005d3cac7d43b9f02 CPU threads: 8; OS: Linux 5.16; UI render: default; VCL: gtk3 Locale: en-US (en_US.UTF-8); UI: en-US
Created attachment 178887 [details] Visual comparison Office 365 (left) vs LibreOffice 7.4 (right)
Version: 6.4.8.0.0+ Build ID: 99b065ec31d032fc08ab14f66430dac4fef904a5 CPU threads: 8; OS: Linux 5.16; UI render: default; VCL: gtk3; TinderBox: Linux-rpm_deb-x86_64@86-TDF, Branch:libreoffice-6-4, Time: 2020-10-08_08:57:08 also shows the color change (white -> black), alas not the indentation issue.
Sample slide (PPTX as saved by LibreOffice) IsNoGood file to start. You should start with ODP. This would first be filesave problem, because sample is white in LO and black in MSO, maybe existing bug.
Created attachment 180283 [details] Sample slide (ODP as saved from original PPTX) (In reply to Timur from comment #3) > Sample slide (PPTX as saved by LibreOffice) IsNoGood file to start. I beg to disagree. LibreOffice also is used to create and edit PPTX. That is a key use case for users like myself. And it is how this specific bug and test case naturally came into light. > You should start with ODP. That said, I now saved the original document as ODP and repeated the steps in the original description starting from that. · The color change (white to black) is still there when opening in O365. · The incorrect indentation no longer is there when opening in O365. · Opening either the original PPTX, the "original" ODP, or the newly saved PPTX in LibreOffice both shows correct colors and correct indentation.
Version: 7.4.0.0.alpha1+ / LibreOffice Community Build ID: b2467d6c7af988f8ed4e090ebf9472be6c84fb06 CPU threads: 8; OS: Linux 5.17; UI render: default; VCL: gtk3 Locale: en-US (en_US.UTF-8); UI: en-US
(In reply to Gerald Pfeifer from comment #0) > 4. Observe how the title color changed from white to black and also This is probably closely related to bug 94122.
Let's consider duplicate for color. "One issue per report" applies. *** This bug has been marked as a duplicate of bug 94122 ***
(In reply to Timur from comment #7) > Let's consider duplicate for color. > "One issue per report" applies. What is one issue, and what is two, isn't quite clear. > *** This bug has been marked as a duplicate of bug 94122 *** Makes sense if this is really a duplicate of #94122. Reopening and adjusting the title for the other issue, then.
Point of a bug is that it's clear for someone to resolve. I don't see exactly what different paragraph indentation is about. What are the steps here? Should be: open attached ODT and save as PPTX and see a difference (best with screenshot of all those in LO and MS but with same zoom ratio).
LO ODT: Exploring Cloud-Native Platforms for Accelerated Digital Transformation MSO ODT: Exploring Cloud-Native Platforms for Accelerated Digital Transformation MSO saved PPTX in LO: Exploring Cloud-Native Platforms for Accelerated Digital Transformation MSO saved PPTX in MSO: Exploring Cloud-Native Platforms for Accelerated Digital Transformation It's trivial and happens because of Poppins Medium which I don't have recognized in LO so it's expected that replacement font behaves differently. So really this report should be left duplicated of color bug as I did. But now I mark as NotABug for font. If you can give a better explanation for indent, please do.
Attachment #2, "Visual comparison Office 365 (left) vs LibreOffice 7.4 (right)" has the side by side visual. The initial description has the steps to reproduce. Admittedly you and me disagree on the need to have the initial document as ODP, see comment #4.
Gerald, please take time to consider Comment 11 and make this clear.
Gerald, please take time to consider Comment 10 and make this clear.
Created attachment 180343 [details] Sample slide (PPTX as saved by LibreOffice, font changed to Arial)
Created attachment 180344 [details] Visual comparison Office 365 (left) vs LibreOffice 7.4 (right), font changed to Arial, including visual markers for Timur
This is not related to Poppins font. I changed the font to Arial and incorrect indentation still occurs - see screenshot. By indentation I am referring to the distance of the leftmost part of a line of text (or multiple lines of text) from the left edge of the slide. When Impress renders this document, both lines are indented by the same amount. When Powerpoint shows this document, as saved by Impress, the second line is farther indented than the first (regardless of font used).
Right, not about font. But it's still NotABug. Because LO doesn't write that in PPTX and MSO sets some arbitrary value.
Only way to "fix" it is to prevent the issue by setting value in LO.
(In reply to Timur from comment #17) > Right, not about font. But it's still NotABug. > Because LO doesn't write that in PPTX and MSO sets some arbitrary value. I'd rather someone actually analyzed what is going on with the file instead of pure guesswork. As principle, the reference of handling a PPTX is PowerPoint, if there is a disparity in Impress, there has to be a good reason for it, otherwise we can assume Impress is to blame. I've bibisected the point where the extra indent is shown in PowerPoint using repo bibisect-linux-64-7.2. It's the 7.2 backport of the following commit in 7.4. Adding CC: to Attila Bakos (NISZ). Note the steps: - open attachment 180283 [details], - save as PPTX, - reload the PPTX, and save it, - reload the PPTX again, and save it, - open PPTX in PowerPoint. (if there is no second reload, the indent isn't there) https://cgit.freedesktop.org/libreoffice/core/commit/?id=f57cfddb51b7d7409b7b425dc200aa73406a13bd author Attila Bakos (NISZ) <bakos.attilakaroly@nisz.hu> 2021-12-08 10:22:37 +0100 committer László Németh <nemeth@numbertext.org> 2021-12-09 12:14:51 +0100 tdf#145162 PPTX export: fix extra bullet regression
It's Before text and Hanging or indent in MSO. LO doesn't write it in PPTX and when LO opens it, it assumes zeros. When MSO opens it, it assumes 1/4 inch. There's no value in PPTX. Only when MSO saves it, it writes some value, as well as LO if some value is set. No guessing here.
Steps seem to be in accordance to what I wrote: as long as you save in LO you don't set value. When MSO opens it, it does. I don't think this is a regression, but let Attila say. LO can prevent MSO behavior and it can be enhancement or it's NotABug. http://officeopenxml.com/drwSp-text-paraProps-margins.php
(In reply to Timur from comment #21) > Steps seem to be in accordance to what I wrote: as long as you save in LO > you don't set value. When MSO opens it, it does. > I don't think this is a regression, but let Attila say. > LO can prevent MSO behavior and it can be enhancement or it's NotABug. > http://officeopenxml.com/drwSp-text-paraProps-margins.php Hi There! It seems to me, the problem is the following: Before, in Impress during pptx export, the placeholders were simply shapes, which has no indent by default and disconnected from the master slide. I changed that to export real placeholders so they depends on the master slide setting. On the other hand the ooxml uses default numbering and indent for placeholders if nothing is exported to the xml. The commit -- what have mentioned above to cause the problem -- disabled that, to paragraphs have default bullet/numbering, but the default indent kept (because it is not exported yet and not implemented.) So if I make Impress to export the 0 values to indent it will be fine (as i did it manually and worked.) :) Patch soon. For the interest, this happens in newer powerpoint only, the 2010 one renders it fine :) (as Impress did) Not think its a real regression, rather a simple export bug. (Not to mention how many default things might be in the PowerPoint what if has nothing in the xml are set, causing difference. So that change, where placeholders exported instead of shapes -- despite it was only a few line modification -- can cause so many differences (because the different default values).
I remove regression and set Enhancement. Because it's not LO that makes it wrong, but adapting to MSO which has this default reading which is not 0.
(In reply to Timur from comment #23) > I remove regression and set Enhancement. Because it's not LO that makes it > wrong, but adapting to MSO which has this default reading which is not 0. Given MSO is the reference implementation for PPTX, LO not properly adapting to that is a bug, not an enhancement. Or as Aron wrote in comment #19: "As principle, the reference of handling a PPTX is PowerPoint, if there is a disparity in Impress, there has to be a good reason for it, otherwise we can assume Impress is to blame." Or as Attila wrote in comment #22: "Not think its a real regression, rather a simple export bug." Thank you Aron for putting us on the right track, and Attila for diving into this and coming up with a patch! :-)
Eventually i guessed it... :) If there is list setting (numbering or bulleting) that was fine but, if there is no setting the zero indent have to be forced for PP, the buNone tag not enough. There is the fix: https://gerrit.libreoffice.org/c/core/+/135025
Created attachment 180416 [details] The original pptx resaved with patched LO
Attila Bakos (NISZ) committed a patch related to this issue. It has been pushed to "master": https://git.libreoffice.org/core/commit/445d4ce232b8e8efaeb2605533fede1b71f52f30 tdf#147991 PPTX export: fix bullet indent regression It will be available in 7.4.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.
Thank you, Attila! Happy to confirm this resolves the original issue (cf. initial description). Version: 7.4.0.0.alpha1+ / LibreOffice Community Build ID: 66b1ebd4ddc7127a923bf81eb569e7f99dd52022 CPU threads: 8; OS: Linux 5.18; UI render: default; VCL: gtk3 Locale: en-US (en_US.UTF-8); UI: en-US And thank you for adding that regression test, too! (Turns out both this *and* the commit leading to this came from me. :-O)