Download it now!
Bug 90613 - FILEOPEN: DOCX import blank document created from MSO normal.dotm (filesize 0 bytes)
Summary: FILEOPEN: DOCX import blank document created from MSO normal.dotm (filesize 0...
Status: NEW
Alias: None
Product: LibreOffice
Classification: Unclassified
Component: Writer (show other bugs)
Version:
(earliest affected)
Inherited From OOo
Hardware: All All
: medium normal
Assignee: Not Assigned
URL:
Whiteboard:
Keywords: filter:docx
: 98127 104819 (view as bug list)
Depends on:
Blocks: DOCX
  Show dependency treegraph
 
Reported: 2015-04-14 14:19 UTC by Orwel
Modified: 2020-04-11 17:14 UTC (History)
3 users (show)

See Also:
Crash report or crash signature:


Attachments
Step 3 file (18.99 KB, application/msword)
2015-04-14 14:21 UTC, Orwel
Details
New .docx created with right-click in explorer (122 bytes, application/zip)
2015-04-18 18:12 UTC, Buovjaga
Details

Note You need to log in before you can comment on or make changes to this bug.
Description Orwel 2015-04-14 14:19:09 UTC
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.
Comment 1 Orwel 2015-04-14 14:21:29 UTC
Created attachment 114785 [details]
Step 3 file
Comment 2 Orwel 2015-04-14 14:25:54 UTC
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).
Comment 3 Orwel 2015-04-14 14:37:28 UTC
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.
Comment 4 Buovjaga 2015-04-18 18:12:20 UTC
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.
Comment 5 Buovjaga 2015-04-18 18:13:18 UTC
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
Comment 6 Buovjaga 2015-04-18 18:31:40 UTC
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
Comment 7 QA Administrators 2016-09-20 09:24:58 UTC Comment hidden (obsolete)
Comment 8 Bartosz 2017-02-17 22:37:58 UTC
This bug is not existing with LibreOffice 5.2 and Ubuntu 16.10
Comment 9 Orwel 2017-02-20 08:00:09 UTC
This bug is still present under LO 5.2.1.5 and Win10. The behaviour as described in original post is still the same.
Comment 10 Buovjaga 2017-02-20 10:45:56 UTC
*** Bug 104819 has been marked as a duplicate of this bug. ***
Comment 11 Buovjaga 2017-02-20 10:46:12 UTC
*** Bug 98127 has been marked as a duplicate of this bug. ***
Comment 12 Justin L 2017-11-02 14:57:25 UTC
I'm not sure what normal.dotm has to do with this? This isn't any different than "touch new.docx".
Comment 13 Orwel 2017-11-03 09:55:26 UTC
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.
Comment 14 kt 2018-07-19 10:40:32 UTC
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.
Comment 15 junk_2010 2019-02-10 19:18:26 UTC
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.
Comment 16 junk_2010 2019-08-11 19:16:03 UTC
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.
Comment 17 junk_2010 2020-01-25 17:44:14 UTC
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