Created attachment 125266 [details] original docx file On pc Debian x86-64 with master sources updated today, the layout of the file attached is different between LO and Word 2013. (see attachments)
Created attachment 125267 [details] pdf generated from LO master sources updated today pdf export seems to correspond with LO display.
Created attachment 125268 [details] pdf from Word2013 + pdfcreator
Created attachment 125269 [details] console logs Here are console logs I noticed
Ok, so the arrangement of the field and ball images is on top. We can send them to back (right click - arrange) to fix it. Then there are several extra ball images we can delete. Also several extra Sport 2000 images we can delete (on top of each other like the tennis balls). Julien: do you consider the extra images as user errors and only keep this report for the arrangement issue or..? Arch Linux 64-bit, KDE Plasma 5 Version: 5.3.0.0.alpha0+ Build ID: 60041cb237ea73c2c1885dd6afd99d88780c2dfc CPU Threads: 8; OS Version: Linux 4.5; UI Render: default; Locale: fi-FI (fi_FI.UTF-8) Built on May 26th 2016 64-bit, KDE Plasma 5 Build ID: 5.1.3.2 Arch Linux build-1 CPU Threads: 8; OS Version: Linux 4.5; UI Render: default; Locale: fi-FI (fi_FI.UTF-8)
(In reply to Buovjaga from comment #4) > ... > > Julien: do you consider the extra images as user errors and only keep this > report for the arrangement issue or..? >... First, thank you for your detailed feedback. Indeed, we can consider the extra images as user issue and I suppose we can keep the report for arrangement issue. However, I hope Word's layout doesn't depend on some internal bugs. I mean perhaps it displays like this just because of bugs and, eg, Word > 2013 would display problems. In this case, I would't like LO mimicks these bugs :-)
** 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
On pc Debian x86-64 with master sources updated today, I could reproduce this.
Created attachment 155847 [details] pdf generated from LO master sources updated today (Win10) It's a bit better but it's not equivalent to Word now.
Created attachment 155848 [details] console logs
It seems that after opening .docx document with LibreOffice and resave it (into .docx), the arrange is correct.
Created attachment 155850 [details] test when resaving (In reply to Bartosz from comment #11) > It seems that after opening .docx document with LibreOffice and resave it > (into .docx), the arrange is correct. Hmm, I just did the test: - open initial tournoi.docx file - save it into docx tournoi2.docx it's a mess!
Created attachment 155851 [details] Minimal .docx document on which the arrange issue is visible
The remaining pb when opening tournoi.docx is the tennis ball where we can see the frame. The resaving is a bit scary (see my previous comment) but I suppose it should be a new bugtracker. The minimal doc shows only the tennis court so no pb here obviously.
Created attachment 155853 [details] Smallest .docx document on which the arrange issue is visible
That's a VML textbox with the yellow text in front of the tennis court image. Likely a duplicate to bug #67759 but let's keep this alive just in case. Still bad in current nightly: Version: 7.2.0.0.alpha0+ (x64) Build ID: cb084f475db33a2cfc62bc9c8de37b8c3c87b3c7 CPU threads: 4; OS: Windows 6.3 Build 9600; UI render: Skia/Raster; VCL: win Locale: hu-HU (hu_HU); UI: en-US Calc: CL
On pc Debian x86-64 with master sources updated today, I still reproduce this. Attila: thought you might be interested in this one since you already fixed some z-order pbs in docx import.
Tünde/László: noticing tdf#124333 (PPTX import: fix Z-order of embedded OLE objects), thought you might interested in this one. Of course, if it's not the case, don't hesitate to uncc yourself.
I forgot to tell I gave a new try on pc Debian x86-64 with master sources updated today (42a73e2259d5937ffb8896f7cd24991f83b1ad82)
Just for the record, I gave a new try with master sources updated today, I got the same.
proposed fix at https://gerrit.libreoffice.org/c/core/+/168511 Things are more or less in the correct zOrder now. (There is one button-in-a-textframe that should be above the tennis-ball-in-body-text, but I'm not sure how that kind of complexity should be handled). OOo 3.3 didn't read the textbox or images. LO 3.5 displayed everything, but rather badly, and on multiple pages.
Justin Luth committed a patch related to this issue. It has been pushed to "master": https://git.libreoffice.org/core/commit/69dd3061882971d18bb07e829c20241916f26fc5 NFC related tdf#100037: unify duplicate PropertySets, etc It will be available in 24.8.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.
Justin Luth committed a patch related to this issue. It has been pushed to "master": https://git.libreoffice.org/core/commit/6c2ab0f3ca440f6e10b438e6ee0e235cbe155216 tdf#100037 vml import: add AS_CHAR images to zOrder calculation It will be available in 24.8.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 Justin, I gave a try and it's indeed far better since we can read the text which is on top of the ball. However there's still a pb, the logo "Sport 2000" is cropped at the right (see https://bugs.documentfoundation.org/attachment.cgi?id=125268, the third attachment to see the result on Word). But perhaps you already have something on mind about this too?
"tournoi.docx" opens OK if first round-tripped by Word 2010 into its own format (DML-based CompatibilityMode 14). (In reply to Justin L from comment #21) > (There is one button-in-a-textframe (Image 20) that should be above > the tennis-ball-in-body-text (Image 10) [also mentioned in comment 24] This particular document would look better if /*LastDuplicateWins*/false, but I doubt it would be correct to do that. In general, AS_CHAR images should never be able to overlap anyway - so if anything the zOrder should probably be tied to the parent fly's zOrder. IIUC, the DML also just "punts" in the case of IsInShape(), so the last AS_CHAR-in-fly wins, but for VML we are always considered IsInShape, and so far I don't see how to detect that the VML is in something else. [Not m_StreamStateStack.top().bIsInTextBox or m_StreamStateStack.size() or embedded["<<m_StreamStateStack.top().xEmbedded.is() or HasTopAnchoredObjects() ] But even then, you just "get lucky" depending on how the flies are positioned. In any case, "tournoi.docx" round-trips in LO terribly anyway, so I'm not going to worry too much about an extreme edge case in this emulation game.
OK fair enough. Let's put this one to VERIFIED then.
Justin Luth committed a patch related to this issue. It has been pushed to "master": https://git.libreoffice.org/core/commit/f714fb262ad8561afcababf4b7a97dedb1b72c15 tdf#100037 vml import: set fly-anchored AS_CHARs above fly's zOrder It will be available in 24.8.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.
Somehow LO 7.2 fixed the DML version of the unit tests in comment 27 with commit 0e6d963fbca16f98a3dbb6ef2fee3736a89d055b Author: Attila Bakos (NISZ) on Fri May 7 10:18:01 2021 +0200 tdf#138141 sw: fix textbox z-order
(In reply to Commit Notification from comment #27) > Justin Luth committed a patch related to this issue. > It has been pushed to "master": > > https://git.libreoffice.org/core/commit/ > f714fb262ad8561afcababf4b7a97dedb1b72c15 > > tdf#100037 vml import: set fly-anchored AS_CHARs above fly's zOrder > ... Now it's perfect! Thank you Justin! :-)