Steps to reproduce: Not sure, I found the problem by chance trying to export a document I had written, but I'm not sure how to trigger the bug again. It seems to have something to do with the use of ljist styles... I'll attach a sample document that shows the problem, and the same document exported to .doc Expected result: Both documents should look the same. The .doc one should look the same in MS Word. Actual results: Libreoffice draws a bigger bullet in the .doc version than in the .odt one. MS Word (2003) breaks the formatting, it looks like it changed the first character in the bulleted line with a new line. It also uses a bigger bullet than the .odt version. Notes: This bug was found in Libreoffice 3.5.4, but it has been confirmed with 4.0.0rc1
Created attachment 73399 [details] sample documents
Created attachment 73400 [details] screenshot top: Libreoffice, exported .doc file middle: MS Word 2003, exported .doc file bottom: Libreoffice, original .odt file
Reproducible with 3.6.3.2 - changing version. @Jaime - just a heads up that Version refers to the oldest version that we see the bug, not the latest that it was tested. Thanks for reporting! Marking as: New (confirmed) Minor (can theoretically make high quality work harder to achieve) Low (default for minor, don't see a reason to change this)
** 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.0.3 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) Thank you for your help! -- The LibreOffice QA Team This NEW Message was generated on: 2015-02-19
Tried again and got the same result. I've tested with: 4.3.5 on Windows XP 4.4.1.1 40m0(Build:1) (Debian experimental) 4.5.0.0.alpha0+ Build ID: e1ef9e9999b1d9256a803abb59c9b70e4690f8be self built on Debian No changes whatsoever
Still present in LO 5.1.0.3.
** 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
The bullet size looks fine to me in LO 7.0+ for doc and docx. However, there are serious problems with tabstops not matching up in Word - which pushes the content to the line below the bullet. And Word 2003 is using a pretty heavy bullet.
The size of the bullets is covered in bug 85964. So in this report, just focus on the tabstops. Notice that it is MICROSOFT WORD that isn't looking good here. Also notice that the tabstop is for 0.3cm and 20cm - so if it misses the 0.3cm tabstop, it just jumps to the next line.
repro 7.1 for exporting to both DOC and DOCX formats.
Created attachment 163608 [details] tabstopTest_59674.doc: two pages in MS Word 2016 - with dot-leader tabstop So, it looks like this document was carefully designed - except wrongly done. On the first numbering, the Indent is 0.5 and the tabstop is 0.8 On the bullet numbering, the Indent is 0.8 and the tabstop is 0.3 (after a first line indent of 0.5.). So, it looks like the author added up 0.5 and +0.3 to try to get the tabstop at 0.8 - except it doesn't work that way. The tabstop is not relative positioning, but absolute. So a tabstop BEFORE the first line indent does nothing. LO treats the IndentAt as a tabstop, but MS Word does not. (Well, that statement needs to be qualified - for .doc format it is true. It is also true for .docx with Word 2003, but NOT with Word 2016.) So the fix in this case seems to be to set the tabstop at IndentAt if the tabstop is less than or equal to the first line indent. (really it should be <= firstLineIndent+numberingCharWidth).
Justin Luth committed a patch related to this issue. It has been pushed to "master": https://git.libreoffice.org/core/commit/5ad17c85dc93973c0cbb1d633b9eed144f0677de tdf#59674 Word export: set a tabstop at numbering IndentAt 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.
Justin Luth committed a patch related to this issue. It has been pushed to "master": https://git.libreoffice.org/core/commit/23126db6e0ca3eb51748b6f579d066f20536d27b Revert "tdf#59674 Word export: set a tabstop at numbering IndentAt" 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.
(In reply to Commit Notification from comment #13) > Revert "tdf#59674 Word export: set a tabstop at numbering IndentAt" reverted because it caused a regression, documented in bug 136644.
Dear Jaime Velasco Juan, 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
(In reply to QA Administrators from comment #15) > 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/ I confirm that the bug is still present. Opening the attached ODT file and saving as DOC (not DOCX) produces the same result: the DOC file is broken when opened with MS Word. Version: 7.4.1.2 (x64) / LibreOffice Community Build ID: 3c58a8f3a960df8bc8fd77b461821e42c061c5f0 CPU threads: 6; OS: Windows 10.0 Build 19044; UI render: Skia/Vulkan; VCL: win Locale: es-ES (es_ES); UI: es-ES Calc: threaded