1. Open LibreOffice 3.4 RC1 Writer. 2. Write a line, e.g. "This is a test." 3. Save as Word 97 DOC format. 4. Open the file in MS Office 2010. -> Protected View. Office has detected a problem with this file. Editing may harm your computer. Click for more details. Same sample saved from LibreOffice 3.3 is valid.
Created attachment 47067 [details] Valid DOC saved from LibreOffice 3.3.2
Created attachment 47068 [details] Invalid DOC saved from LibreOffice 3.4 RC1
Cedric, could you please have a look? IMHO, it is very annoying, ugly, and affecting many users :-(
This is an annoying bug but has no reason to block 3.4.0. The file can still be edited in MSO 2010 and no warning is shown on other versions of Words. There is furthermore no problem when resaving a file that hasn't been created with LO 3.4.
Created attachment 47768 [details] test file created by 3.3 and resaved by 3.4, valid for MSO 2010
Created attachment 47769 [details] same document than attachement 47768, but created from scratch with 3.4
It is quite confusing for users. We should do our best to fix it in 3.4.1 => increasing the severity.
I do not have MSO 2010 to test... Is Cédric Bosdonnat saying that he cannot reproduce this bug?
(In reply to comment #8) > I do not have MSO 2010 to test... > > Is Cédric Bosdonnat saying that he cannot reproduce this bug? Surely not. I'm just saying I still haven't found what causes it.
Created attachment 48628 [details] My testing document generated by 3.4 (bad one) for reference. So I got to something; I'll attach few files here.
Created attachment 48629 [details] Binary dump of test-3.4.doc (got using xxd test-3.4.doc > bad.txt).
Created attachment 48630 [details] This makes a working document from the non-working dump of test-3.4.doc. Just apply this patch over the bad.txt, and do xxd -r bad.txt > good.doc, and see that good.doc now opens without warning. So the difference that makes it non-working is newly introduced "ccb4 cc0c" in the WordDocument stream; no idea yet what does it mean, but hopefully we are close ;-)
It is SPRM SDxtCharSpace that has wrong value. Patch sent to the mailing list for approval & closing the bug :-)