Created attachment 75471 [details] original odt Problem description: wrong export file with table to rtf and doc Steps to reproduce: 1. Make file with table 2. Save As *.rtf or Microsoft Word 97/2000/XP/2003 (.doc) Current behavior: New row from table on new list of document Expected behavior: Operating System: Windows XP Version: 4.0.0.3 release
Created attachment 75472 [details] save as .doc
Created attachment 75473 [details] save as .rtf Incorrect width of columns in a table
Verifed on 3.6.4.3 Bodhi Linux 2.2 Changing version: @John Doe - version is the oldest version we can confirm the issue ++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++ New (confirmed) Major (data corruption) High (default, this may be highest but so far only one test document shows error) @John Doe - can you reproduce this repetitively or does it only occur with this document?
Can't reproduce this repetitively. Seems like it only this file.
I am setting the options back to where I put them, it's confirmed on Linux as well.
Reproducible with LibreOffice 3.5.4, 4.3.3 and 4.4.0.0-beta1 on Debian.
This issue is still present in Version: 5.0.1.2 Build ID: 81898c9f5c0d43f3473ba111d7b351050be20261 Locale: es-ES (es_ES) on Windows 7 (64-bit) when exporting as .doc but not when exporting as .docx
Migrating Whiteboard tags to Keywords: (filter:doc filter:rtf) [NinjaEdit]
** 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
This was reported for both RTF and DOC. RTF is fine. But DOC repro with 6.2+. Not sure this should be kept open at all because it's thi specific document. But we should figure out the reason.
1.) This is an export bug - I see the same one-row-per-page in Word, due to a section break - next page. 2.) somehow coming from a RES_PAGEDESC in every single cell in ww8atr.cxx if ( SfxItemState::SET == pSet->GetItemState( RES_PAGEDESC, false, &pItem ) && static_cast<const SwFormatPageDesc*>(pItem)->GetRegisteredIn() != nullptr) { bBreakSet = true; bNewPageDesc = true; pPgDesc = static_cast<const SwFormatPageDesc*>(pItem); m_pCurrentPageDesc = pPgDesc->GetPageDesc(); } 3.) which ultimately comes from wrtww8.cxx WriteText's SectionBreaksAndFrames
Dear JohnDoe_71Rus, 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
Created attachment 154920 [details] original tested in LO 6.4+ and MSO 2016 Reproduced for DOC in LO 6.4+.
*** Bug 68710 has been marked as a duplicate of this bug. ***
Potential fix is found at https://gerrit.libreoffice.org/c/core/+/93729. However, it seems to be at odds with what MS is capable of doing. MS allows the first column, first paragraph to specify a "page break before" that it will honour. See bug 48097. What I just did here breaks that. Perhaps this needs to move into ww8atr.cxx OutputSectionBreaks and only affect a Section break, not a page break.
Created attachment 160536 [details] tdf61423_pageStyleInTable.patch
In users.odt, we see all cells in the first column in the table defined like <text:p text:style-name="P15"> <text:span text:style-name="T4">111111</text:span> </text:p> and the dynamic style P15 defined with <style:style style:name="P15" style:family="paragraph" style:master-page-name="Standard"> .../> </style:style> where master-page-name == RES_PAGEDESC - aka a break-before-with-page-style. You can't see this in the UI - probably because it is illegal. Again - not touching this as per comment 15.
Still reproducible in Version: 7.2.0.0.alpha0+ / LibreOffice Community Build ID: 8043fe3e45c8999c8eaf475ba46d50b125e38b93 CPU threads: 4; OS: Linux 5.7; UI render: default; VCL: gtk3 Locale: en-US (en_US.UTF-8); UI: en-US Calc: threaded
Dear JohnDoe_71Rus, 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 https://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://web.libera.chat/?settings=#libreoffice-qa Thank you for helping us make LibreOffice even better for everyone! Warm Regards, QA Team MassPing-UntouchedBug
Tested on version 7.4.6.2 and all now looks good. Closing.
Thanks for testing, really OK. If a fixing commit is not known, it's not marked FIXED but WFM.
I'm not sure how it could have been fixed in 7.4.6. I didn't see it fixed in Linux bibisect 7.4 - only in 7.5. The fix was not backported to 7.4 either. LO 7.5 commit c37f62b71fa59917ef85ff98480dff18aa936e41 Author: Justin Luth on Wed Jul 20 13:03:13 2022 -0400 tdf#145998 sw ms export: use page break, not section break If possible, use a simple page break instead of a section break. Eliminate unnecessary "page style" changes. If the page will become that style anyway, then a simple page break will suffice. The benefit is primarily for LO import, since it is virtually impossible on import to know if a section is identical to the previous section. Thus we have previously multiplied page styles - often redundantly. This also starts to fix a real problem with first headers showing up on an unnecessary new page style. Unit test deals with this. Change-Id: Ib9e24bbd579b29aa21efb2b85750ecfcb8c7e5cb
I assume ThomasBourchier missed comment 10 and was testing with RTF export which has already worked since at least 6.2. The bug report was limited to DOC export, and that was fixed in 7.5. Also confirmed that MS Word 2010 opens it correctly.