Created attachment 117740 [details] .odt file and its export to .doc comparision As it can be seen in the attachment, exporting to .doc in LibreOffice 5.0.0.5. adds some unnecessary table borders when using more complex table border formatting. Similarly, it happens when exporting to .docx, but with extra borders in different places (not included in the screenshot). Note: In the screenshot .doc is opened in MS Office 2007; however, the same applies when the same .doc file is opened in LibreOffice. (I did not notice this behavior in previous LibreOffice 4 versions.)
Hello Toms, Thank you for filing the bug. Please send us a sample document, as this makes it easier for us to verify the bug. I have set the bug's status to 'NEEDINFO', so please do change it back to 'UNCONFIRMED' once you have attached a document. (Please note that the attachment will be public, remove any sensitive information before attaching it.) How can I eliminate confidential data from a sample document? https://wiki.documentfoundation.org/QA/FAQ#How_can_I_eliminate_confidential_data_from_a_sample_document.3F Thank you
Created attachment 117783 [details] A .doc document with wrongly drawn border lines (examples No.3 No.5) The intended borders of these tables can be seen in the screenshot.
Raal, Thank you for the response! Is the previous attachment enough or the original .odt document should be provided too? (I'm sorry for not including this comment, when attaching file. I wrongly imagined that "attaching file" would attach a file to a later created comment with an option to add another file and not suddenly create a new comment.)
@Toms, please attach .odt document. Thank you.
Created attachment 117932 [details] An .odt document showing the original tables.
I cannot reproduce with Version: 5.1.0.0.alpha1+ Build ID: 6b7354ae66db40246a09e00aa876443057655a43 TinderBox: Linux-rpm_deb-x86_64@70-TDF, Branch:master, Time: 2015-08-19_01:05:16 Seems to be fixed in dev version.
Created attachment 118037 [details] printscreen .doc export is correct, but I can reproduce the problem when exporting to .docx Version: 5.1.0.0.alpha1+ Build ID: 6b7354ae66db40246a09e00aa876443057655a43 TinderBox: Linux-rpm_deb-x86_64@70-TDF, Branch:master, Time: 2015-08-19_01:05:16
** 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
DOCX export isn't quite right (Table 5 has a full border) Reproduced with Version: 5.4.0.0.alpha0+ Build ID: a9f56091b6422ec8c42f09b8472200ae4ab12548 CPU Threads: 4; OS Version: Windows 6.19; UI Render: default; TinderBox: Win-x86@42, Branch:master, Time: 2016-12-05_23:12:26 Locale: nl-NL (nl_NL); Calc: CL
Reproduced with Version: 6.0.0.0.beta2
Table 5 having full border is confirmed with LO 6.0.4.2. It can be noted that this behaviour is consistent with reporting (by me) in bug 92026 that the borders of the FIRST CELL IN THE TABLE are erronously copied to other cells when saved as DOCX. It therefore seems that at the present state, this bug can be considered a duplicate of bug 92026.
(In reply to Lars Jødal from comment #11) > It therefore seems that at the present state, this bug can be considered a > duplicate of bug 92026. There seems to be more than just the problem in 92026. In the example ODT, notice that no cell in table 3 has a bottom border, but in the DOCX, the middle cell does have a bottom border (and no other cell). So that at least is not a case of just replicating the first cell's borders.
(In reply to Eyal Rozenberg from comment #12) > (In reply to Lars Jødal from comment #11) > > It therefore seems that at the present state, this bug can be considered a > > duplicate of bug 92026. > > There seems to be more than just the problem in 92026. In the example ODT, > notice that no cell in table 3 has a bottom border, but in the DOCX, the > middle cell does have a bottom border (and no other cell). So that at least > is not a case of just replicating the first cell's borders. True, the pdf attachment from comment 1 shows differences that cannot be explained by bug 92026. However, if the odt file given as attachment in comment 5 is tested with LO 6.0.4.2 (present fresh version), then the result is different from the original bug report: Tables 1, 2 AND 3 now have correct borders as docx. Unlike the original report, Table 4 now has an extra right border at the right-most cell. Table 5 is now correct regarding the vertical borders, but now has a bottom border for all cells (including the middle cell). Assuming that table 3 had the vertical borders set from the middle cell, not from the first cell, all of this is consistent with borders of the first cell being copied to the whole cell. I.e., SET borders are copied, unset borders does not seem erase set borders. In summary: Originally, this bug was more complicated. Comment 9 seems to indicate that the problem was partly fixed by version 5.4. The remaining problem is consistent with being a duplicate of bug 92026. Agree?
Agreed, but that means that the original problem was not a dupe, but rather depended on some issue which by now has been resolved, and 92026. So - marking the second dependency for now. When 92026 is finally resolved, we'll double-check this one has been fully resolved as well.
(In reply to Eyal Rozenberg from comment #14) > When 92026 is finally resolved, we'll > double-check this one has been fully resolved as well. The remaining problem of table 5 is definitely a duplicate of bug 92026. This document worked perfectly up until LO 4.3 commit ae61569eea0719a882010cfbb260a1a0d690d974 because "Our exporter was writing all the cell properties in all cases, regardless of them being defined by the theme or not" and obviously if every border is being explicitly written out, then it is easy to look like the original.
Fixed in 6.2 confirmed after bug 92026 was closed