Description: When converting formats txt→odt→txt LO inserts unnecessary characters at the beginning of the resulting text. It shouldn't insert any characters by itself, and instead it should preserve text bytes just as they are. Steps to Reproduce: 1. ``` echo 'foobar' > text.txt libreoffice --convert-to odt text.txt mv text.txt{,.orig} libreoffice --convert-to txt text.odt ``` Actual Results: $ sha256sum text.txt{,.orig} a2969248c7632f26c29e6d46a177f1f63334202d1d6170928e2e737d2b0f7c29 text.txt aec070645fe53ee3b3763059376134f058cc337247c978add178b6ccdfb0019f text.txt.orig $ hexdump -C text.txt.orig 00000000 66 6f 6f 62 61 72 0a |foobar.| 00000007 $ hexdump -C text.txt 00000000 ef bb bf 66 6f 6f 62 61 72 0a |...foobar.| 0000000a Expected Results: sha256 of both original and conversion output should be the same. Reproducible: Always User Profile Reset: No OpenGL enabled: Yes Additional Info: Version: 6.1.0.3 Build ID: 10(Build:3) CPU threads: 8; OS: Linux 4.18; UI render: default; VCL: gtk2; Locale: en-GB (en_GB.UTF-8); Calc: group threaded
Repro. I tried regression testing. With 3.3.0 the commands I found (old syntax) did not work, but 3.6.7 worked and the same bad result. libo36 --headless --convert-to odt:"OpenDocument Text Flat XML" text.txt libo36 --headless --convert-to txt:text text.odt Arch Linux 64-bit Version: 6.2.0.0.alpha0+ Build ID: 00e10ae3189a4407ffb1a48f836cd52dc9a1b6df CPU threads: 8; OS: Linux 4.18; UI render: default; VCL: gtk3_kde5; Locale: fi-FI (fi_FI.UTF-8); Calc: threaded Built on 13 October 2018
Dear Zetok, 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
Dear Zetok, 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
No repro in: Version: 7.2.0.4 (x64) / LibreOffice Community Build ID: 9a9c6381e3f7a62afc1329bd359cc48accb6435b CPU threads: 6; OS: Windows 6.1 Service Pack 1 Build 7601; UI render: Skia/Raster; VCL: win Locale: en-US (en_US); UI: en-US Calc: threaded Maybe it's Linux-only, or maybe it has been fixed.
Yep, I still repro with 7.2.1 on Linux
The three bytes that are inserted at the beginning of the converted file: ef bb bf Are the Unicode Byte Order Mark for UTF-8. You can explicitly specify whether you want it there or not by providing options to the text output filter. For example: libreoffice --convert-to "txt:Text (encoded):UTF8" text.odt will include the BOM, and: libreoffice --convert-to "txt:Text (encoded):ASCII" text.odt will not include the BOM. When I follow the STR but explicitly specify ASCII encoding, I receive the exact bytes as in the original text file, no BOM. It is a bit odd that it defaulted one way for Linux and another way for Windows, but there is probably some good reason for that, too. So, I think this should be resolved as either NOTABUG or WONTFIX.