Description: The attached PPTX has 2 lines of text and a third line with equation. Each line has on-click animation. The text is duplicated and the animation is wrong. This is somehow caused by the equation. Steps to Reproduce: 1. Open the attached PPTX in Impress 2. Compare with the PDF exported from PowerPoint 2013. 3. Try to play the animations. Actual Results: The text is duplicated. The animations don't play one by one on click. Expected Results: No duplicate text. Separate animations on click. Reproducible: Always User Profile Reset: No Additional Info: Version: 6.3.3.2 (x86) Build ID: a64200df03143b798afd1ec74a12ab50359878ed CPU threads: 8; OS: Windows 6.1; UI render: default; VCL: win; Locale: en-US (en_US); UI-Language: en-US Calc: CL
Created attachment 156147 [details] PPTX with text, equation and animations
Created attachment 156148 [details] PDF exported from PowerPoint 2013
Hello, So the duplicate equation is fixed in https://cgit.freedesktop.org/libreoffice/core/commit/?id=4038d6c393c3cf6330671124ba69cdba98b24960 However, the same commit has caused the equation x to disappear... I believe we can consider that a regression... author Miklos Vajna <vmiklos@collabora.com> 2019-11-13 17:41:45 +0100 committer Miklos Vajna <vmiklos@collabora.com> 2019-11-13 18:43:57 +0100 commit 4038d6c393c3cf6330671124ba69cdba98b24960 (patch) tree 79dbbc062df6fb3acd544e223b6b7cd036f1da54 parent ae499df25c01a149dfbb387da17a7f8a232a6a4e (diff) tdf#117658 PPTX import: fix duplicated math object handling Bisected with: bibisect-linux64-6.5 Adding Cc: to Miklos Vajna
Created attachment 156149 [details] Minimal sample document
This is how this "worked" in the past: The PPTX file contains both drawingML / mathML markup for the slide and also a replacement image. We used to read both: the OOXML markup missed the math formula and the replacement image did not. This is how this is "broken" currently: we now only read the OOXML markup to avoid the duplication, but Impress doesn't support inline formulas (just math objects), so the import can't really do much more than just ignoring the math formula. Considering this as a regression is fair enough, but I would say the root cause here is missing feature, it's not like I can sit down and just "fix this": if we read both versions, then we have duplication, if we read only the markup then we can have problems when Impress misses some PowerPoint feature and if we only read the replacement image, then we regress because the formula is not editable. To sum up, the root cause here is really a missing feature, let me tag this as an implementation error, rather than a regression. This Impress core limitation is even documented in a debug warning in commit 332a796366b7cb91dff41de4b9ffb17843112a3e (oox: import Math objects from PPTX files, 2016-01-21): warn:oox.drawingml:2141:2141:oox/source/drawingml/shape.cxx:667: losing a Math object...
Miklos, can you please give an example of OOXML element representing inline formula that Impress doesn't support and Math object that Impress does support? Maybe I can preprocess the pptx and replace inline formulas with math objects.
This bug has an example of a PPTX shape which has both text and math markup, Impress can't handle this. E.g. bug 117658 has an example PPTX shape which has only math markup, so we can map that to Impress math objects.
*** Bug 125123 has been marked as a duplicate of this bug. ***
*** Bug 105886 has been marked as a duplicate of this bug. ***
Inline math examples in: - PPTX attachment 131045 [details] from bug 105886, PDF as attachment 131046 [details]. - attachment 113333 [details] from bug 81494, equation𝑡ℎ𝑒 is shown as equation. - slide 3 of attachment 151079 [details] from bug 124976
*** Bug 81494 has been marked as a duplicate of this bug. ***
*** Bug 124976 has been marked as a duplicate of this bug. ***
Further examples in https://web.archive.org/web/20160721184553/http://www.mmds.org/mmds/v2.1/ch10-graphs1.pptx from bug 102200. I didn't close as duplicate because it needs to be thoroughly checked.
*** Bug 130026 has been marked as a duplicate of this bug. ***
*** Bug 132692 has been marked as a duplicate of this bug. ***
*** Bug 133232 has been marked as a duplicate of this bug. ***
*** Bug 134001 has been marked as a duplicate of this bug. ***
*** Bug 134068 has been marked as a duplicate of this bug. ***
Still reproducible in Version: 7.1.0.0.alpha0+ Build ID: 6f1e02c96b887750f974c187a82ecd6236e6a435 CPU threads: 4; OS: Linux 5.7; UI render: default; VCL: gtk3 Locale: en-US (en_US.UTF-8); UI: en-US Calc: threaded
*** Bug 136910 has been marked as a duplicate of this bug. ***
*** Bug 138971 has been marked as a duplicate of this bug. ***
Increasing importance due to the number of duplicates
Can someone (Timur?) who knows what to check have a look at bug 138633 and see if that's also a duplicate? Thanks.
*** Bug 138633 has been marked as a duplicate of this bug. ***
I just wanted to mention that https://bugs.documentfoundation.org/show_bug.cgi?id=138971 contains kind of minimal test files of the same document (one line of text, one formula) in odp, pptx and pdf format (all saved with some version of PP Office 365).
*** Bug 133239 has been marked as a duplicate of this bug. ***
*** Bug 143479 has been marked as a duplicate of this bug. ***
*** Bug 146100 has been marked as a duplicate of this bug. ***
*** Bug 91300 has been marked as a duplicate of this bug. ***
Miklos/Regina/Michael: reading https://bugs.documentfoundation.org/show_bug.cgi?id=129061#c5 + 332a796366b7cb91dff41de4b9ffb17843112a3e I understand that it's an ODF limitation. 1) Is it something which could be asked and hoped for a future ODF version? 2) would it be possible to implement this as an ODF LO extension (waiting by an official ODF version supporting the ad hoc feature)?
(In reply to Julien Nabet from comment #30) > Miklos/Regina/Michael: reading > https://bugs.documentfoundation.org/show_bug.cgi?id=129061#c5 + > 332a796366b7cb91dff41de4b9ffb17843112a3e > I understand that it's an ODF limitation. No, it is not a limitation of ODF. The feature exists in ODF but is not implemented in LibreOffice. From view of ODF, Writer frames (which can have formulas as content in LibreOffice) and Draw/Impress "text box" are the same.
it depends - the math formulas could be imported into as-char Math embedded objects, which is already possible with ODF but not implemented in LO (svx/editeng). but IIRC the math formulas aren't laid out like embedded objects, they may be laid out as in-line text so you could have half of the formula at the end of one line and the other half at the start of the next line - this is a feature that is missing in both ODF and LO. (also commit 332a796366b7cb91dff41de4b9ffb17843112a3e indicates that in PresentationML formulas aren't supported either so it's not OOXML feature but PowerPoint extension...)
> but IIRC the math formulas aren't laid out like embedded objects, they may > be laid out as in-line text so you could have half of the formula at the end > of one line and the other half at the start of the next line - this is a > feature that is missing in both ODF and LO. Having formulas that can be automatically split to adjust to the paragraph (or to a text box) is something that affects all LO modules, specially Writer in DOCX imports. For instance, when you open DOCX files with long equations that span more than one line in Word, they will not be entirely visible in Writer.
any news on this?
In February 2022 I read a blog post by TDF about a tender that tried to address bug 129061, among many other ODF compliance issues. https://blog.documentfoundation.org/blog/2022/02/28/tender-to-cleanup-and-further-improve-odf-conformance-202202-01/ At first I was very excited because I thought the inline formula issue in Impress was finally coming to an end. However, the bug was in a list from which not all of them needed to be fixed. So I'd like to know if this was one of the bugs fixed for this tender.
(In reply to Rafael Lima from comment #35) > ... > https://blog.documentfoundation.org/blog/2022/02/28/tender-to-cleanup-and- > further-improve-odf-conformance-202202-01/ > ... > So I'd like to know if this was one of the bugs fixed for this tender. Well if any progress on inline math element of the tender, it has not made it into current master against 7.5.0 Version: 7.5.0.0.alpha0+ (x64) / LibreOffice Community Build ID: 9063d99ff5ee43cc1239fc1dbb5d9897bdda1c9b CPU threads: 8; OS: Windows 10.0 Build 19044; UI render: Skia/Vulkan; VCL: win Locale: en-US (en_US); UI: en-US Calc: CL threaded
this bug was included in the tender, at least to the extent that Math embedded objects in shape text should be implemented, similar to existing feature in Writer text frames - the inline layout doesn't exist in ODF currently. but i'm sorry to report that currently the customer doesn't want us to start working on the tender.
*** Bug 154741 has been marked as a duplicate of this bug. ***
Setting "User printer metrics for text formatting" toggles SCINPUTOPT_TEXTWYSIWYG and SC_UNONAME_PRMETRICS, guess that means the default mode (without precise scaling fidelity) is necessary for performance of the sheet? But have to wonder if any improvement could be made to layout fidelity of the general case without impacting performance? =-ref-= https://ilarsi.com/