Created attachment 101926 [details] Original .doc file with resulting .odt, along with screenshots (MS Word viewer + LO) Problem description: When importing a WinWord document containing tables and an image, various settings of the original document are not respected: - page margins - table dimensions (margins, column width and row height) - space between tables Steps to reproduce: 1. File/Open... with a .doc file. Operating System: Windows 7 Version: 4.1.2.3 release
Confirmed in Linux Mint in 4.2.5 and 4.3.0. The table width is correct in 4.0.6.
(In reply to comment #1) > Confirmed in Linux Mint in 4.2.5 and 4.3.0. The table width is correct in > 4.0.6. Hi Jay, When commenting, can you pls explain what is confirmed :) ? Marc mentions "various settings" Ciao, Cor
(In reply to comment #2) > Marc mentions "various settings" Which in itself is not a good habbit too: one issue for one problem pls.
(In reply to comment #2) > Hi Jay, > > When commenting, can you pls explain what is confirmed :) ? Marc mentions > "various settings" > Ciao, > Cor Hi Cor, I did state what was confirmed with 'The table width is correct' and did change the bug summary to reflect what the issue was, as the only thing wrong is the table width. :)
(In reply to comment #4) > (In reply to comment #2) > > Hi Jay, > > > > When commenting, can you pls explain what is confirmed :) ? Marc mentions > > "various settings" > > Ciao, > > Cor > > Hi Cor, > > I did state what was confirmed with 'The table width is correct' and did > change the bug summary to reflect what the issue was, as the only thing > wrong is the table width. :) Hi Jay, Thanks for checking and precising. But then (i.e. if only the table width in incorrectly imported), there is a puzzling discrepancy: why is the import result not the same on your system as on mine? In the imported ODT on my system, as shown in the attached screenshots: - the table is spread over 2 pages; - there is a 5-cm-high gap between the first 3 rows and the rest. In the original DOC: - the whole document fits on one page; - the gap after the first 3 rows is a mere 5 mm high. To say nothing of the page margins. These issues above are systematically reproductible on my system, not only with the attached file, but with other files created with the same MS Word template. Shall I create 3 separate bug entries for the remaining issues (row height, gap, page margins)? But if they aren't reproductible on LO test computers, it's annoying. Have a good week, Marc
Hi Marc, Yes our bug system works with one bug per report and the biggest problem i noticed with both the doc and odt is that the table started going out of the page in 4.1, so i made this bug about that. There isnt an issue with the margins because the table is out of the margins to begin with. :) Please do open an additional bug report regarding the spacing issue, as in 4.1.6 its 5 mm high, but in 4.2.5 and above, its 7 rows high, similar to the exported odt. Once these two issues are dealt with, i assume the document will show up correctly. The main problem here is that is opening the DOC file improperly, and as a result, it exports it improperly as an ODT.
(In reply to comment #6) > [...] Please do open an additional bug report regarding the spacing issue, [...] Ok: it's bug 80717.
bibisect range: 2ede6c95e6481c92cc199e7d74fd36c841636304..1472b5f87314fe660ef1a7b254e51272669f12f6 commit 8fe8bd6c3b5b1a539b7370f8c457fa69c061d2de Author: Miklos Vajna <vmiklos@suse.cz> AuthorDate: Mon May 13 11:24:58 2013 +0200 Related: fdo#61594 SwWW8ImplReader::StartApo: don't always start a frame ah another one of those pesky Word floating tables...
(This is an automated message.) 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".
Migrating Whiteboard tags to Keywords: (bibisected) [NinjaEdit]
adding filt:doc keyword.
It's not "width not imported properly" but rather "SPACING not imported properly". Spacing is table spacing, i.e. position. Here it's left and above. They can be changed manually and it's correct then. So, Bug 80717 may be the same and Bug 80869 looks like a duplicate.
*** Bug 80869 has been marked as a duplicate of this bug. ***
Created attachment 126875 [details] Original DOC without protection Original DOC is protected and it's show split in Word. Please don't confirmt the bugs with such unproper examples. I add the same one without protection. Example DOC from the bug I closed as a duplicate: attachment 102217 [details]
*** Bug 80717 has been marked as a duplicate of this bug. ***
Adding Cc: to Miklos Vajna
*** Bug 97312 has been marked as a duplicate of this bug. ***
adding a bug showing the maybe related but opposite problem; bug 59274
*** Bug 97037 has been marked as a duplicate of this bug. ***
*** Bug 94950 has been marked as a duplicate of this bug. ***
*** Bug 94955 has been marked as a duplicate of this bug. ***
*** Bug 100676 has been marked as a duplicate of this bug. ***
*** Bug 113672 has been marked as a duplicate of this bug. ***
** 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
Bug 97037 (a duplicate from this one) is still not fixed, using LibreOffice 6.1.3.1.
Created attachment 146414 [details] Original DOC without protection, proper encoding I ran into encoding errors when opening the previous copy. This one is created with Word 2016.
I created a stripped down version for testing: attachment 146504 [details] I also, spun off the 2 page import issue into Bug 121318
Dear Marc PHILIPPE, 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
(In reply to Luke from comment #26) > Created attachment 146414 [details] > Original DOC without protection, proper encoding > > I ran into encoding errors when opening the previous copy. This one is > created with Word 2016. There seems to be some serious import problems with this example. It doesn't even go through the "should I convert this centred, floating table to an inline one?" process. So it is a very different case from the originally reported example...
(In reply to Justin L from comment #29) > There seems to be some serious import problems with this example. Please ignore this. I think I accidentally saved overtop of the original example.
The proposed patches should cover most, if not all, bugs reported here. -https://gerrit.libreoffice.org/c/core/+/91188 tdf#80635 ww8import:1 take float table CENTER to inlined table fixes: -GE Bilokin Nadia.doc from this bug -gerrit.libreoffice.org/c/core/+/91272 tdf#80635 ww8import:2 take float table RIGHT to inlined table -gerrit.libreoffice.org/c/core/+/91273 tdf#80635 ww8import:3 take float table orient to inlined table
The proposed patches should cover most, if not all, bugs reported here. -https://gerrit.libreoffice.org/c/core/+/91188 tdf#80635 ww8import:1 take float table CENTER to inlined table fixes: -GE Bilokin Nadia.doc from this bug comment 0 -GE Bilokin Nadia-fixed.doc from this bug comment 26 -PageBug.doc from this bug comment 27 -test file.doc from bug 97312 -AccountInfo-Sanatized.doc from bug 97037 -https://gerrit.libreoffice.org/c/core/+/91272 tdf#80635 ww8import:2 take float table RIGHT to inlined table -https://gerrit.libreoffice.org/c/core/+/91273 tdf#80635 ww8import:3 take float table orient to inlined table fixes: -act2.doc from this bug report comment 14's attachment 102217 [details] -Resume.doc from bug 97037 -Document.doc from bug 113672 The following duplicates were vertical alignment problems, which is the topic of bug 80717 which is approximately impossible to solve. -bug 94950 -bug 94955 Ignoring bug 100676 since it is password protected and thus is a useless test document. There are plenty of other examples, so very safe to ignore this one.
Justin Luth committed a patch related to this issue. It has been pushed to "master": https://git.libreoffice.org/core/commit/35b3a3eb001ec8ff8c808ad6d990a583163ad365 tdf#80635 ww8import:1 take float table CENTER to inlined table It will be available in 7.0.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/cd868678583fa92833c37a63089131ba905dd3a6 tdf#80635 ww8import:2 take float table RIGHT to inlined table It will be available in 7.0.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/ba989a99ea19ffd0aafeea01f9b737ea79fa952a tdf#80635 ww8import:3 take float table orient to inlined table It will be available in 7.0.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, congrats for all untangling, patches and tests. While you already did a great work, I kindly ask you to comment on the following. In bug 100676 file was password protected, but I added non-protected now, please see if that is this bug or (to me seems) not. I tested with patches 1 and 2 and looks as before fixes.
(In reply to Timur from comment #36) > In bug 100676 file was password protected, but I added non-protected now, > please see if that is this bug or (to me seems) not. Seems to have already been fixed in LO 5.3. Full reply in bug 100676.
*** Bug 76805 has been marked as a duplicate of this bug. ***