Created attachment 95588 [details] doc with textframe layout problem The attached document is containing two tables which are placed within textframes. If the document is loaded within LibreOffice then it looks like the two tables are lying upon each other (which is not the case if loaded with Word).
Confirmed with versions 4.2.3.0.0+ and 4.1.5 under Linux / Ubuntu 13.10. It is clear that something goes wrong. Changed version number to 4.1.5. Note: when opened in LibreOffice, the file has only one text frame (it contains the table 1) anchored to the character. Hi Miklos, this one me be interesting for you. Best regards. JBF
** 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 on a currently supported version of LibreOffice (4.4.2 or later) https://www.libreoffice.org/download/ If the bug is present, please leave a comment that includes the version of LibreOffice and your operating system, and any changes you see in the bug behavior If the bug is NOT present, please set the bug's Status field to RESOLVED-WORKSFORME and leave a short comment that includes your version of LibreOffice and Operating System 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) 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: http://webchat.freenode.net/?channels=libreoffice-qa Thank you for your help! -- The LibreOffice QA Team This NEW Message was generated on: 2015-05-02
Document looks identical in Word viewer - something is clearly wrong with the document and not LibreOffice! Please confirm with MSO, I will test with it at some later time. Win 7 Pro 64-bit Version: 5.1.0.0.alpha1+ Build ID: 3ecef8cedb215e49237a11607197edc91639bfcd TinderBox: Win-x86@62-merge-TDF, Branch:MASTER, Time: 2015-06-19_23:16:58 Locale: fi-FI (fi_FI)
Created attachment 116721 [details] the same bugdoc stored as normal docx via MSO 2013 This bug is still happening with my latest LibreOffice (4.3.72)...The XML version saved back with MSO 2013 is having the same layout problems but might be better to debug this issue.
Ok, I confirmed in MSO 2013. In LibO, the tables are on top of each other both in the doc & docx, while they are fine in MSO. Win 8.1 32-bit MSO 2013 LibO Version: 5.1.0.0.alpha1+ Build ID: 2885e157674dbefa7d9b984a399fabd1238eeedd TinderBox: Win-x86@39, Branch:master, Time: 2015-06-22_07:52:27 Locale: fi-FI (fi_FI)
** 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 on a currently supported version of LibreOffice (5.1.5 or 5.2.1 https://www.libreoffice.org/download/ If the bug is present, please leave a comment that includes the version of LibreOffice and your operating system, and any changes you see in the bug behavior If the bug is NOT present, please set the bug's Status field to RESOLVED-WORKSFORME and leave a short comment that includes your version of LibreOffice and Operating System 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) 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: http://webchat.freenode.net/?channels=libreoffice-qa Thank you for helping us make LibreOffice even better for everyone! Warm Regards, QA Team MassPing-UntouchedBug-20160920
There are many frame bugs, I'm not sure which are related. Bug 78756. Bug 66039.
** 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
Still reproducible in Version: 6.3.0.0.alpha0+ Build ID: 49c61f660d05ab13140d4349a0b3f6efba742022 CPU threads: 4; OS: Linux 4.15; UI render: default; VCL: gtk3; Locale: ca-ES (ca_ES.UTF-8); UI-Language: en-US Calc: threaded
(In reply to Buovjaga from comment #3) > Document looks identical in Word viewer Also overlapping in MSWord 2003 - for both the doc and docx
Created attachment 165271 [details] The minimized docx example file in Word and Writer It seems like the shape is anchored to page in Word, but it's opened as anchored to paragraph in Writer. It is also having square wrap in Word. Setting it manually to anchored To page and Wrap Off recreates the original look.
@Attila I thought you might be interested in this one.
Created attachment 165275 [details] Same Settings In Word And Writer 7.1 with the sample file In my opinion, basically there is no problem with the positioning/anchoring. Both program uses the same distance (1,22 cm and 2,9 cm) and relative point (page) for positioning, and the textbox -- what includes the first table -- is in the right place, see this attachment. The problem with the other table which outside the textbox. In Word in spite of the wrap setting, which is optimal (means, the text can be that side what have greater space) there is no surround, but in Writer there is, this is the problem, I think. So this rather a table positioning problem, than a frame. And how can it solved is a so good question... (I think there is a calculating mechanism in Word which indicates that there is not enough space for the second table and that is the reason for the difference.)
A bit of experimentation in Word: - The top textbox has the Allow overlap setting enabled. This means that another textbox or shape can overlap it, if that also ha Allow overlap enabled. But only if both have it enabled, even if one of them has it disallowed, they can't overlap. - The normal i.e. non-floating table however does not have an Allow overlap setting among it's settings. However it behaves in my Word 2019 as if it had it disabled: never overlaps the top textbox. In Writer however the table overlaps the textbox. It should behave in Writer in relation to shape objects as if it were having this Allow overlap feature, and it were disabled.
*** Bug 143743 has been marked as a duplicate of this bug. ***
*** Bug 143729 has been marked as a duplicate of this bug. ***
I suspect this may be fixed when we no longer convert page-wide floating tables into regular tables. (bug 65509)
Justin: if the root cause is lack of floating tables, then please add this bug to the bug 139532 tracker, I guess that's where we collect floating table problems. Thanks.
Created attachment 186008 [details] tableWrapping.odt: fundamental difference between LO and MS Word in table wrapping. (In reply to Miklos Vajna from comment #18) After re-examining, only one the shorter table is anchored (inside a textbox). The longer one is just a normal inline table with no wrapping. The problem appears to be that LO doesn't consider tables when dealing with image wrapping. This minimal example (tableWrapping.odt) shows that natively LO doesn't consider tables need to be impacted by floating stuff. When saved as DOCX, MS Word doesn't "fit" the table "beside(under)" the image.
*** Bug 115625 has been marked as a duplicate of this bug. ***
Created attachment 186038 [details] tableWrapping2.odt: one case where LO does wrap a table (poorly) There is one type of situation where LO does wrap a table, but only if the orientation is set to "LEFT" or "RIGHT" and the wrap is also left/right/parallel (but not optimal). The code for all this is in sw/source/core/layout/tabfrm.cxx CalcFlyOffsets()
attachment 139768 [details] (test.docx) from duplicate bug 115625 is a good example with several unique qualities of its own: -it also imports nicely in MSO2003 -in LO it is a sync'd textbox with an unsynchronized wrap (RES_SURROUND) where in the layout code it looks like it is THROUGH instead of the UI's PARALLEL. There are also various existing unit tests related to this bug's issues: -through wrap should be ignored: fdo43573-2-min.docx on page 11 -MS brochure that always exhibits every bug: tdf81345.docx -parallel wrapping (already works): table-fly-overlap-spacing.docx -parallel in header (already works): table-fly-overlap.docx Related but no real impact noticed, but probably useful to verify against to ensure no bad side effects: -page-remove-fly-no-table.fodt -tdf105688.docx -tdf123163-1.docx -tdf132911.odt -tdf135061.odt -tdf151375.ott -testCustomShapePresetExport.odt
This is noteworthy: // fly anchored at character or at paragraph bConsiderFly = ... pFly->IsFlyAtContentFrame() ... Obviously AsChar has no wrapping, but that ToPage is excluded is unexpected.
I ran out of time and also running out of confidence. Posting what I have... https://gerrit.libreoffice.org/c/core/+/149347 related tdf#76022 sync textbox RES_SURROUND text wrapping // quickly fails a make sw.check https://gerrit.libreoffice.org/c/core/+/149348 related tdf#76022: don't ConsiderFly offsets when wrap is THROUGH https://gerrit.libreoffice.org/c/core/+/149349 [WIP] tdf#76022 table wrap: always wrap if space
Justin Luth committed a patch related to this issue. It has been pushed to "master": https://git.libreoffice.org/core/commit/afbe948d4c47391092c8fcf4130bd7501c3d5062 tdf#115625 tdf#76022 sw table: CalcFlyOffset: get correct surround for textbox It will be available in 7.6.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/4ca4282517d02592966576fc642048b3d5ae5532 related tdf#76022 sw CalcFlyOffset: no ConsiderFly if THROUGH wrap It will be available in 7.6.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.
The document (test.docx) in duplicate bug 115625 is fixed by comment 25's patch, but that is only one instance in many. This bug report is not yet solved.
Created attachment 186252 [details] 76022_tableWrappingOptimal.docx: bizarre layout in MS 2010 I wanted to know how Microsoft would handle multiple floating objects when one was set to optimal (largest side) wrap. Does it make a one-time decision based on the single fly, or does it take all flies into consideration? For plain text, the answer clearly seems to be that it takes everything into consideration. [However, LO doesn't.] For tables, the answer is very mixed. "It depends" on seemingly random considerations.
*** Bug 117132 has been marked as a duplicate of this bug. ***
Bug 117132 has been closed as duplicate, but that was about completely supporting the feature in Writer, even on the UI, and even when working with ODTs, which doesn't necessarily equate with providing solution to a "DOC/DOCX import" issue. So I'm noting here that consequently the scope of this bug report has been expanded to include those considerations.
There really shouldn't be a UI component - it should happen automatically.
Is that not an incompatible change with existing LO versions, though?
(In reply to Aron Budea from comment #32) > Is that not an incompatible change with existing LO versions, though? Of course, but the same compat flag that allows MS layout can be used for ODT as well. The inability of table to wrap around flies is not a "feature" that needs to be preserved.
*** Bug 106840 has been marked as a duplicate of this bug. ***
*** Bug 119914 has been marked as a duplicate of this bug. ***
*** Bug 107628 has been marked as a duplicate of this bug. ***
*** Bug 137822 has been marked as a duplicate of this bug. ***
*** Bug 112359 has been marked as a duplicate of this bug. ***