Created attachment 84324 [details] Bad table formating docx This document is only one page. Writer shows me 9 pages. Operating System: Windows 7 Version: 4.1.0.4 release
Thank you for your bug report, I can reproduce this bug running LibreOffice Version: 4.1.1.1 Build ID: a990db030b8125868501634ff662be1d89d0868 on Mac osx 10.8.4.
Version: 4.1.1.1 Build ID: a990db030b8125868501634ff662be1d89d0868 Windows XP The same problem. Part of the table on different pages.
it's still reproducible with: - Libreoffice 4.1.5.3 Build ID: 1c1366bba2ba2b554cd2ca4d87c06da81c05d24 - Libreoffice 4.2.2.1 Build ID: 3be8cda0bddd8e430d8cda1ebfd581265cca5a0f - Libreoffice 4.3.0.0.alpha0 Build ID: aeab0183e86fe011d32058864c02b2de4da32dc9
** 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
ver 4.4.3.2 still have the same
** 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
5.2.1.2 Windows 7 same problem
Please, do not change the version to a newer one as it should reflect the oldest version where the issue can be reproduced
Can be already reproduced in LibreOffice 3.5.0 Build ID: d6cde02
Interesting. I'd guess this is docx generated by some software. Justin, could you maybe say what this is? Some MSO feature LO doesn't support?
Created attachment 131688 [details] bad-doc1_docx.pdf: enabled table border lines first, then exported from Word 2003 This document is an extremely complex mess of tiny rows, columns, and tables within tables. I think every block of text is in a separate table. Some lines are extra heavy, because there are minimal-width columns touching each other. The problem is related to style "EmptyCellLayoutStyle" which doesn't seem to be created. So the outermost table is failing to be created because of exceptions.
The main table is created approximately correctly with this change: -if( pEntry->nStyleTypeCode == STYLE_TYPE_CHAR || pEntry->nStyleTypeCode == STYLE_TYPE_PARA || pEntry->nStyleTypeCode == STYLE_TYPE_LIST ) +if( pEntry->nStyleTypeCode == STYLE_TYPE_CHAR || pEntry->nStyleTypeCode == STYLE_TYPE_PARA || pEntry->nStyleTypeCode == STYLE_TYPE_LIST || pEntry->nStyleTypeCode == STYLE_TYPE_UNKNOWN ) { - bool bParaStyle = pEntry->nStyleTypeCode == STYLE_TYPE_PARA; + bool bParaStyle = pEntry->nStyleTypeCode == STYLE_TYPE_PARA || pEntry->nStyleTypeCode == STYLE_TYPE_UNKNOWN; However, the table-in-tables are mostly hidden behind the other cells, instead of being laid out on top. Dealing with tables is a bit too complicated for me...
** 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
(In reply to QA Administrators from comment #13) > ** 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.mangazuki.online/manga/the-abandoned-empress/ > > 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 I think every block of text is in a separate table. Some lines are extra heavy, because there are minimal-width columns touching each other. The problem is related to style "EmptyCellLayoutStyle" which doesn't seem to be created. So the outermost table is failing to be created because of exceptions.
Justin Luth committed a patch related to this issue. It has been pushed to "master": https://git.libreoffice.org/core/commit/a59ecc3137cc59438cc2cf946223148b6d1a5600 tdf#68326 writerfilter: default style type is paragraph It will be available in 7.1.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.
Bug not fixed, but one step forward by implementing the idea in comment 12.
(In reply to Timur from comment #10) > Interesting. I'd guess this is docx generated by some software. Yes, this is a generated document. This point is worth clearly highlighting (and it is mentioned in the bug summary). Thus I am lowering the importance to minor, since the onus should be on them to generate a document that their intended audience can use.
Next up is to handle w:hMerge properly. Instead of using w:gridSpan, this generator uses w:hMerge. Lots of loading errors suggesting off by one or more cells when trying to convert. likely there is confusion about what cell A1 etc means in this elaborate mess. Merge support was added via commit 97dcf77841d19d344d58d5bdacdab141cdea4817 Author: Miklos Vajna on Fri Dec 27 21:07:43 2013 +0100 Related: fdo#65090 DOCX import: handle w:hMerge cell property
Created attachment 163233 [details] bad-doc1RT2003.docx: round-tripped by MS Word 2003 - for comparison
Created attachment 163238 [details] hMerged1.docx: relatively complex merge. LO can in general handle hMerge properly.
Created attachment 163244 [details] hMerged_68326.zip: two minimalistic versions of the original file, with pdfs
It seems like UNO sometimes fails to select the requested table cells, therefore the merge fails, therefore default grid spacing exists. And things stay pretty messy since most of the grid widths are "1" and not a realistic number, or don't add up to the actual table width - and the extra width is usually given to the last column, squishing everything earlier. <text::XTextTableCursor>xCursor=xTable->createCursorByCellName(aFirst); xCursor->gotoCellByName(aLast, true); //returns false when select fails xCursor->mergeRange(); //returns false when it fails, i.e. when no selection. When it gets into this low level stuff, it is too hard and dangerous for me. Bye.
*** Bug 146353 has been marked as a duplicate of this bug. ***
(In reply to Justin L from comment #17) > (In reply to Timur from comment #10) > > Interesting. I'd guess this is docx generated by some software. > > Yes, this is a generated document. This point is worth clearly highlighting > (and it is mentioned in the bug summary). Thus I am lowering the importance > to minor, since the onus should be on them to generate a document that their > intended audience can use. It's Low priority for a Normal Importance that we give to OOXML docs.
Created attachment 178780 [details] Bad table formating DOCX resaved in MSO Opens OK in LO if resaved in MSO.
23 ugly pages instead only 1 in Version: 7.6.0.0.alpha0+ (X86_64) / LibreOffice Community Build ID: d7c609dbb1bd08865b43719d2fb7c316d30bcde5 CPU threads: 16; OS: Windows 10.0 Build 19045; UI render: Skia/Raster; VCL: win Locale: ru-RU (ru_RU); UI: ru-RU Calc: CL threaded