Created attachment 141508 [details] Sample DOCX (created in Word) The attached DOCX contains two tables, right below one another. The first one is a floating table (text wrapping set to: Around), there's an empty line between the tables, but it slides up next to the first table because of that. In Writer the two tables (the first is imported inside a frame) mostly overlap. This is a case where having a setting mentioned in bug 117132 could be useful. Observed using LO 6.0.3.2 & 4.0.0.3 / Windows 7.
Created attachment 141509 [details] PDF exported in Word
Created attachment 141510 [details] Screenshot in Writer
Hi Aron, I reproduce with LO 6.0.4.1 Build ID: a63363f6506b8bdc5222481ce79ef33b2d13c741 Threads CPU : 2; OS : Windows 6.1; UI Render : par défaut; Locale : fr-FR (fr_FR); Calc: CL and LO 6.1.0.0.alpha0+ Build ID: f80029445e2b558f0d0e0a25c2c1bbcbe5254120 CPU threads: 2; OS: Windows 6.1; UI render: default; TinderBox: Win-x86@42, Branch:master, Time: 2018-04-13_23:07:11 Locale: fr-FR (fr_FR); Calc: CL
How should we filter import this OOXML "feature"? Notice that export / save-as of the sample document (attachment 141508 [details]) from OOXML -> ODF using Word 2016 eliminates the tblOverlap. So, Microsoft does not handle it with their ODF filters, we don't either--is it even possible? Don't think ODF can.
Confirmed! Tested on: Version: 6.0.3.2 Build ID: 8f48d515416608e3a835360314dac7e47fd0b821 CPU threads: 4; OS: Linux 4.13; UI render: default; VCL: gtk2; Locale: en-US (en_US.UTF-8); Calc: group Version: 6.1.0.0.alpha0+ Build ID: fcba22ef7959d3bf0c7f3fc02434a120e3d8c075 CPU threads: 4; OS: Linux 4.13; UI render: default; VCL: gtk2; TinderBox: Linux-rpm_deb-x86_64@70-TDF, Branch:master, Time: 2018-04-24_23:08:46 Locale: en-US (en_US.UTF-8); Calc: group
(In reply to V Stuart Foote from comment #4) > How should we filter import this OOXML "feature"? > > Notice that export / save-as of the sample document (attachment 141508 [details] > [details]) from OOXML -> ODF using Word 2016 eliminates the tblOverlap. So, > Microsoft does not handle it with their ODF filters, we don't either--is it > even possible? Don't think ODF can. I noted that this feature could be implemented in ODF, see bug 117132. Until then, perhaps the current behavior of letting tables/frames overlap should be disabled, at least when it comes to Office cimpatibility. To me letting these overlap seems to be the less frequently used option, normally you want to be able to see what is in your document.
Created attachment 144923 [details] Sample DOCX (frame+table) In this sample there's a frame + table in the document from the start. This similarly overlaps in Writer. Interestingly this starts to overlap in different versions compared to the table + table. Overlaps in 5.4.0.3. Doesn't overlap in 5.3.0.3. In Word frames don't have the options to allow or not allow overlap. Nevertheless, I'd guess there are things in common between the two cases.
(In reply to Aron Budea from comment #7) > In this sample there's a frame + table in the document from the start. This > similarly overlaps in Writer. Interestingly this starts to overlap in > different versions compared to the table + table. And DOC is unaffected.
(In reply to Aron Budea from comment #7) > In this sample there's a frame + table in the document from the start. This > similarly overlaps in Writer. Interestingly this starts to overlap in > different versions compared to the table + table. > > Overlaps in 5.4.0.3. > Doesn't overlap in 5.3.0.3. Starts to overlap because of this, height is updated (was incorrect before), but positioning isn't. The conneciton to this issue is that in Word the frame pushes the table down, while in Writer the table doesn't move, and the two overlap. https://cgit.freedesktop.org/libreoffice/core/commit/?id=94c533bc59a8fe50b3d44c3200646f99269faab5 author Vasily Melenchuk <Vasily.Melenchuk@cib.de> 2017-06-20 14:20:31 +0300 committer Thorsten Behrens <Thorsten.Behrens@CIB.de> 2017-06-29 14:16:29 +0200 tdf#100075 DOCX frame height rule updated
Dear Aron Budea, 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
Still buggy in 6.4.0.0.alpha0+ (bb6bcabda53dbd64dda43f09fab9f4ad6f34eba6).
The first sample (attachment 141508 [details]) now shows reasonably in Writer, since the following commit: https://cgit.freedesktop.org/libreoffice/core/commit/?id=fd7749fddc5a767461dfced55369af48e5a6d561 author Miklos Vajna <vmiklos@collabora.com> 2020-02-14 16:29:44 +0100 committer Miklos Vajna <vmiklos@collabora.com> 2020-02-14 18:37:34 +0100 "sw: fix handling of table vs fly overlaps in the AddVerticalFlyOffsets case" The objects second sample with frame and table (attachment 144923 [details]) still overlap.
(In reply to Aron Budea from comment #12) > The objects second sample with frame and table (attachment 144923 [details]) > still overlap. Layout must not treat a table as something that ought to wrap. Since the table is full width, it can't wrap, and thus should come underneath the fram.
Created attachment 165391 [details] Frame+table in Word and LO 7.0 Example file from comment #7 now looks good in 7.0 since: https://git.libreoffice.org/core/+/358f654af36fa12102685237f6eadebae4610fb5 author Tibor Nagy <nagy.tibor2@nisz.hu> Wed May 20 13:31:51 2020 +0200 committer László Németh <nemeth@numbertext.org> Mon May 25 10:12:44 2020 +0200 tdf#107119 DOCX import: fix parallel text wrap around frames
I guess we can consider this one fixed per comment #12 ? There are similar problems still (bug #76022 and bug #115625 is for shape + table ), but those are tracked as separate.
Let's close this per comment #14
Verified in LO Version: 7.3.0.0.alpha0+ (8151f3a1d99ab740d2affdccc7115faa156bf3ad).