Created attachment 99125 [details] DOC file as example Open the attached file using programs LibreOfficeDev-4.3.0 (or LibreOffice-4.1.6\4.2.4) and LibreOffice-4.0.6. The second table is placed on the page incorrectly. It’s the regression to the LibreOffice-4.0.6.
Created attachment 99126 [details] The screenshot shows an error
It seems to me that there is an error in parsing file. Please read my message (bug 78745 comment 3) and look at the contents (content.xml) of this file (attachment 99152 [details]).
Created attachment 107001 [details] DOC re-saved with frame set to "no wrap" LOv4322 Originally provided DOC opened under GNU/Linux using: - v3.3.4.1 OOO330m19 Build: 401 - v3.4.6.2 OOO340m1 Build: 602 - v3.5.7.2 Build ID: 3215f89-f603614-ab984f2-7348103-1225a5b - v3.6.7.2 Build ID: e183d5b - v4.0.6.2 Build ID: 2e2573268451a50806fcd60ae2d9fe01dd0ce24 - v4.1.6.2 Build ID: 40ff705089295be5be0aae9b15123f687c05b0a - v4.2.6.3 Build ID: 3fd416d4c6db7d3204c17ce57a1d70f6e531ee21 - v4.3.2.2 Build ID: edfb5295ba211bd31ad47d0bad0118690f76407d - v4.4.0.0.alpha0+ Build ID: df73f4115cfe4d07e4159adf087571687eb173ec TinderBox: Linux-rpm_deb-x86_64@46-TDF, Branch:master, Time: 2014-09-25_23:06:16 Rendering under v3.3-4.0 are all OK. Rendering under v4.1-4.4 show the same problem: the frame (blue graphic) at top-left is anchored "to character" with wrap set to "through/in background". In older versions of LO this evidently was not being handled correctly and so was pushing the small table at top-right to the right and the larger table down the page, keeping positioning as expected. This is not correct behaviour for wrap "through/in background" i.e., other objects should flow over the top / in the foreground. Evidently under later versions this frame is now being treated in the correct manner, thus causing the other tables to appear in front. Changing the wrap of this frame to "no wrap" fixes the display as expected. Refer attached.
Bug was originally self-confirmed. I am confirming that in older versions there appears to have been a problem, but recent versions have fixed this issue. If my findings can be confirmed I think this report can be RESOLVED as NOTABUG. Severity set to normal. Summary amended for clarity.
Confirmed in Version: 4.4.0.0.alpha0+ Build ID: f33002aa5de7e88960e7c21286a661c89fd478c7 TinderBox: Win-x86@39, Branch:master, Time: 2014-10-04_03:31:18 Owen, if you open blank_edit.doc in Word and look at the properties of the TextBox, you'll see that it's set to "Wrap text behind image". So Writer's importer should no be setting Wrap to "No Wrap" as in your attached solution. The problem is likely similar to Bug 82824, where the importer is not setting the anchor position of the table on the right side correctly.
Sorry, but reduce the level of this bug, which is a regression, not right. So I returned the status to critical. Lowering the error status will lead to the fact that about her forget.
(In reply to Luke from comment #5) > Owen, if you open blank_edit.doc in Word and look at the properties of the > TextBox, you'll see that it's set to "Wrap text behind image". So Writer's > importer should no be setting Wrap to "No Wrap" as in your attached > solution. Which version of Word are you using? In Word 2007 the layout for the top-left AutoShape is "Behind text" and has "Allow overlap" checked. To be clear, I am suggesting that Writer (since v4.1) may be rendering correctly i.e., "Behind text"+"Allow overlap" == "through/in background". The suggestion/example of "No wrap" was a workaround. > The problem is likely similar to Bug 82824, where the importer is > not setting the anchor position of the table on the right side correctly. The example in that bug has columns. I am not clear whether the /anchoring/ reference here refers to the linked bug or this one (there does not appear to be any anchoring issue in this bug). In any case, the top-right table does have text wrapping set to "Around" while the main table has text wrapping set to "None". It may be the handling of these settings by Word that prevents overlap of the tables (as the summary now implies). Thanks for helping clear this up. (In reply to ape from comment #6) > Sorry, but reduce the level of this bug, which is a regression, not right. > So I returned the status to critical. Lowering the error status will lead to > the fact that about her forget. Setting this level too high will cause the bug to be ignored. The guidelines for setting this field are here: https://wiki.documentfoundation.org/File:Prioritizing_Bugs_Flowchart.jpg This is not a critical issue (although it may be important to you) as critical means data loss / crash. This is formatting issue, thus Severity = normal. Please ignore my statement about this not being a bug in comment 4.
Owen, Yes, it's not an anchor issue with the table. This can be verified by toggling the "Wrap Around" property of the upper right table in Word(I used 2013). When it is off, Word renders the document like current versions of LO. In writer turning the wrapping on for the table will also fix the import.
(In reply to Owen Genat from comment #7) > (In reply to Luke from comment #5) > Which version of Word are you using? In Word 2007 the layout for the > top-left AutoShape is "Behind text" and has "Allow overlap" checked. To be > clear, I am suggesting that Writer (since v4.1) may be rendering correctly > i.e., "Behind text"+"Allow overlap" == "through/in background". The > suggestion/example of "No wrap" was a workaround. > (In reply to ape from comment #6) WinWord-2007sp3 (last update)
There are only 'skip'ped commits left to test. The first bad commit could be any of: 7be68a718d3dbd2254fe62c0af8b4f0b5d602e4b d0234a72b2d4d1c6e1a54d5afb64fbd17df10cc2 We cannot bisect more [7be68a718d3dbd2254fe62c0af8b4f0b5d602e4b] source-hash-bd7b2c7befbd10bebaba3a9b6ea491969ac1dcb0 [d0234a72b2d4d1c6e1a54d5afb64fbd17df10cc2] source-hash-d74ba0c4147f33abd9d0c03883cc88f15e160ee5
Thanks to Kevin's bibisects, I was able to manually further narrow it down to id=578d3476f0c1bc13ac08cc111f5d758226f4d07b - BAD id=1591194a5fc45cbd44c0f4cb022d8ff8c88e0a24 - GOOD this leave a rage of http://cgit.freedesktop.org/libreoffice/core/log/?qt=range&q=1591194a5fc45cbd44c0f4cb022d8ff8c88e0a24..578d3476f0c1bc13ac08cc111f5d758226f4d07b With only http://cgit.freedesktop.org/libreoffice/core/commit/?id=4e07258cbd1f4fb16d6ce2174fb5c74c3b36da33 #i119466# Doc file loaded by AOO, table with incorrect text wrapping property. as the most likely cause. Before this commit Text box wrap - in background table wrap - optimal page wrap After Text box wrap - in background table wrap - page wrap We need to be careful that the fix for this does not break the test cases in https://issues.apache.org/ooo/show_bug.cgi?id=119466 Miklos, can you please take a look at this?
It seems that the commit that caused this regression was identified. (Or at least a commit is suspected as the offending one.) Thus setting keyword "bisected".
Thanks dev-list and this post http://nabble.documentfoundation.org/Help-needed-about-failing-build-same-pb-as-Clang-tinderbox-td4049931.html I was able to narrow the range further down to: http://cgit.freedesktop.org/libreoffice/core/log/?qt=range&q=5bdba378d6fc9f18f618967ec37d07efed2afee..ce0f4825730a0f96ca5369a7d07982ea073901fb 4e07258cbd1f4fb16d6ce2174fb5c74c3b36da33 is the source of this regression.
Use of freedesktop.org services, including Bugzilla, is subject to our Code of Conduct. How we collect and use information is described in our Privacy Policy.