Hi, I suppose it is a LO bug, because I tried all steps I had found trying to fix the behaviour within the MS Office normal.dotm template without success. Environment: Win7-64bit, Office 2010, LO 4.2.2.2 Situation: 1. Create a blank docx document - in Win Explorer right click empty space - New - Microsoft Word Document 2. If you open this file with LO, it is opened in a .txt format, which you can recognize by a) font: Liberation Mono, b) Formatting: Preformated Text... or simply by clicking File - Save as - you see file type ".txt" 3. If yo open the created document (Step 1) in MS Office instead of LO and simply write just one letter (e.g. "a") and save it, after reopening it in LO the document is consistent (all format types are now present and by Save as you see the file is a .docx type). Attachement: 1. Original docx document created in Win7-Explorer by right click - new - Microsoft Word document 2 docx with a letter "a" inserted and saved in MS Office.
Created attachment 114785 [details] Step 3 file
Important amendment: By attaching the original file (step 1) it was not possible to submit it. The file has a 0kB size(is empty), so it is not possible to attach it. So one more time, I am not sure if it is a LO bug or not (sorry if not).
May be I should also explain what is the main problem with such a behavior. If you create such a document, start to write inside it in LO, do formatting and save the document, there is no warning you are saving a formatted document as simple text (.txt), although you save it as docx file type and the formatting is lost after closing the document what is really annoying if you work few hours on the document and forget LO opens such a file as simple text. May be the solution is simple - Set a warning that the file although it is a .docx type is going to be save in txt format.
Created attachment 114889 [details] New .docx created with right-click in explorer File is zipped to go around 0kB limit. MSO 2013 installed on system.
Confirmed all steps. Win 8.1 32-bit MSO 2013 LibO Version: 4.5.0.0.alpha0+ Build ID: 211c12b9c64facd1c12f637a5229bd6a6feb032a TinderBox: Win-x86@39, Branch:master, Time: 2015-04-18_00:35:20 Locale: fi_FI
LibO 3.3.0 gives ASCII filter options dialog on opening the 0kB file. Ubuntu 14.10 64-bit LibreOffice 3.3.0 OOO330m19 (Build:6) tag libreoffice-3.3.0.4
** 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
This bug is not existing with LibreOffice 5.2 and Ubuntu 16.10
This bug is still present under LO 5.2.1.5 and Win10. The behaviour as described in original post is still the same.
*** Bug 104819 has been marked as a duplicate of this bug. ***
*** Bug 98127 has been marked as a duplicate of this bug. ***
I'm not sure what normal.dotm has to do with this? This isn't any different than "touch new.docx".
Probably nothing. By posting the bug I only described the way I tried to fix this behaviour, because I was not sure, if this is a LO bug or Win/MS Office bug for the reason of creating a new empty MS Word document in the described way), but it seems to be a LO bug (still present in 5.3.6.1), because LO does not open this 0 kB file correctly - it seems to be opened only as pure TEXT document.
I've stumbled upon this bug in LO 6.0.1 and I find it pretty serious, because it results in the following user experience: - The user (Win10) does Right Click on the Desktop -> New -> Microsoft Word Document (docx) [because there's an unactivated OEM Office installation on the machine and they are used to creating Word documents]. - The user double-clicks on the new document, which opens it in LibreOffice [because that was installed to be the primary office package]. - The user edits the file and uses cyrillic characters. - The user presses "Ctrl+S" to save the document, which LO happily does, no questions asked. - The user exits LO, feeling good for having done a lot of work. - The user re-opens the file next day and behold - all of the Cyrillic characters were saved as question marks. - The user is sad and runs to Microsoft with their money, never wanting to have anything to do with OSS again. This stems from a bad combination of a number of current "features" of LO. - Firstly, LO detects the file type from its contents rather than the extension. Hence a "new docx file" (which happens to be just an empty file with the docx extension) is considered to be a text file by LO and when you press Ctrl+S, LO implicitly saves the file as text. - Secondly, LO seems to save text files in ANSI, no matter what type of characters you used to type. It asks no questions and does not care at all about losing the data in the process. I mean, shouldn't at least UTF8 be the default for text everywhere in the second decade of the XXIst century unless explicitly requested otherwise? - Thirdly, LO does not seem to care about warning the user before saving a file in a destructive manner. Formatting, non-ANSI characters, everything is destroyed on an implicit "save as text", and, worse of all, it is all done covertly. Each of those three aspects are, in my opinion, major drawbacks/bugs, which need to be fixed. It's a shame to still have them in version 6.x, after ages of development.
I original reported this as: Bug #104819 - Formatting: Corrupt Document/Format After Save When Starting With Empty .docx Document which has been marked as a duplicate of this bug. I can confirm that following the steps in Bug #104819 that this issue is still present in LibreOffice 6.1.5.
I original reported this as: Bug #104819 - Formatting: Corrupt Document/Format After Save When Starting With Empty .docx Document which has been marked as a duplicate of this bug. I can confirm that following the steps in Bug #104819 that this issue is still present in LibreOffice 6.3.0.4.
I original reported this as: Bug #104819 - Formatting: Corrupt Document/Format After Save When Starting With Empty .docx Document which has been marked as a duplicate of this bug. I can confirm that following the steps in Bug #104819 that this issue is still present in LibreOffice 6.3.4.2 on Windows 10. The "saved" document can be re-opened by LibreOffice, however all formatting etc is "missing". It appears to just open as a plain text file. If you try to open the saved document using Microsoft Word 2013, the document is reported as being "corrupt" and not "recoverable" Version used details: Version: 6.3.4.2 (x64) Build ID: 60da17e045e08f1793c57c00ba83cdfce946d0aa CPU threads: 4; OS: Windows 10.0; UI render: default; VCL: win; Locale: en-GB (en_GB); UI-Language: en-GB Calc: threaded
I can confirm that following the steps in Bug #104819 that this issue is still present in LibreOffice 7.0.3.1 (x64) on Windows 10.
Fixed in LO 7.1.1 *** This bug has been marked as a duplicate of bug 123476 ***