Bug 88305 - FILEOPEN: docx file opens wrongly and inconsistently
Summary: FILEOPEN: docx file opens wrongly and inconsistently
Status: RESOLVED WORKSFORME
Alias: None
Product: LibreOffice
Classification: Unclassified
Component: Writer (show other bugs)
Version:
(earliest affected)
4.4.0.0.beta2
Hardware: x86-64 (AMD64) Windows (All)
: medium normal
Assignee: Not Assigned
URL:
Whiteboard: needsWindows
Keywords: filter:docx, possibleRegression
Depends on:
Blocks: DOCX
  Show dependency treegraph
 
Reported: 2015-01-11 23:16 UTC by mike.hall
Modified: 2016-12-09 11:30 UTC (History)
3 users (show)

See Also:
Crash report or crash signature:


Attachments
shows 1 correct and 2 incorrect file opens (160.19 KB, image/jpeg)
2015-01-11 23:32 UTC, mike.hall
Details
reduced docment showing problem (5.60 KB, application/vnd.openxmlformats-officedocument.wordprocessingml.document)
2015-01-14 21:51 UTC, mike.hall
Details

Note You need to log in before you can comment on or make changes to this bug.
Description mike.hall 2015-01-11 23:16:56 UTC
A file sent from someone else saved from MS Word has very odd FILEOPEN behaviour.

A significant characteristic of the file may be that the font in use (Arial Narrow) is not on this PC. If I change the font to one that's present, the problem goes away.

I also noticed that on select all and apply font Calibri to everything (the font defined in the active styles) if you then put the cursor next to the end of paragraph mark, it still shows Arial Narrow as the active font.

I'm attaching a .jpg showing three alternative views of the file immediately after opening, one of which is correct. The incorrect ones appear when this is the first file opened after LO starts or after closing it and reopening as the only file open. The correct one appears when another file has already been opened.

I'm not willing to attach the file here because it has personal address details etc which are not mine and if I anonomise it the problem goes away. However, the file is on the web if you know where to look and I'm happy to send it to anyone who wants to work on this bug.

Regression: File opens correctly in 4.3.5 under Win 8.1 and in 4.2.7 under Linux (Mint Cinnamon Rebecca = Ubuntu).

Leads to data loss if you export the incorrectly opened file to pdf. 

Attachment will follow in a few mins...
Comment 1 mike.hall 2015-01-11 23:32:41 UTC
Created attachment 112100 [details]
shows 1 correct and 2 incorrect file opens
Comment 2 Robinson Tryon (qubit) 2015-01-14 19:51:57 UTC
(In reply to mike.hall from comment #0)
> I'm not willing to attach the file here because it has personal address
> details etc which are not mine and if I anonomise it the problem goes away.

Having a test document makes things infinitely easier for both QA and for the developers. It also means that we have something we can use as the basis for a unit test, preventing a regression of this problem in the future.

How have you tried to anonymize the document?  Have you tried deleting a paragraph or a few lines at a time, or just replacing the address text with x's?
Comment 3 mike.hall 2015-01-14 21:48:29 UTC
Sorry, I thought that if I saved it from LO the problem always went away, but that isn't true. I will attach a reduced document that shows the same characteristics described above.
This is a bit like black magic, but to see the problem, it seems important to have closed LO completely and to have clicked on another application other than win explorer. Then if you open the document by double-clicking from win explorer you should see the problem.

Export to pdf-> lost data
select all and apply any available font -> problem goes away
Ctlr+Z -> visible chars look OK BUT export to pdf -> still data loss
select all and apply any available font -> problem goes away - export to pdf is OK

So, all to do with the non-present font probably.
Comment 4 mike.hall 2015-01-14 21:51:12 UTC
Created attachment 112253 [details]
reduced docment showing problem

File attached is .docx saved from 4.4.0.2
Comment 5 Robinson Tryon (qubit) 2015-01-14 22:07:00 UTC
TESTING on Ubuntu 14.04 + LO 4.4.0.2

(In reply to mike.hall from comment #3)

REPRO Steps:
> This is a bit like black magic, but to see the problem, it seems important
> to have closed LO completely and to have clicked on another application
> other than win explorer. Then if you open the document by double-clicking
> from win explorer you should see the problem.

Okay -- it's a shot-in-the-dark testing w/GNU-Linux, but we'll see what happens :-)

1) Start LibreOffice and open file (attachment 112253 [details])

> Export to pdf-> lost data

RESULT: PDF (opened in Evince) looks ok to me, so NOREPRO.

I'll make a note in the Whiteboard that we should test in Windows
Whiteboard -> needsWindows
Comment 6 Buovjaga 2015-01-16 12:48:58 UTC
Something funny going on in Windows, definitely.

For me in LibO 4.4 rc2 and 4.5, exporting to PDF doesn't change anything, but "Carmina Burana and Chichester Psalms" in the subheading and "Chichester Psalms" after "Bernstein’s" are invisible upon opening.
This happens inconsistently, sometimes both are invisible, sometimes the other.

If I change the font of a problematic piece of text to something that is available, close without saving and immediately reopen from the LibO start center, three things might happen:
1. the text is visible and ok.
2. only the C of Chichester Psalms is visible and there is a mysterious extra blank line before the sentence continues - no actual line-break is inserted, though.
3. problematic words are invisible like from a fresh open

Win 7 64-bit, LibO Version: 4.4.0.2
Build ID: a3603970151a6ae2596acd62b70112f4d376b99

and Version: 4.5.0.0.alpha0+
Build ID: b3b4bbaf6cbd2226b659fea7d6ae473ccf84e9dd
TinderBox: Win-x86@39, Branch:master, Time: 2015-01-12_06:13:44
Comment 7 Robinson Tryon (qubit) 2015-12-09 18:31:51 UTC Comment hidden (obsolete)
Comment 8 Telesto 2016-12-09 11:30:58 UTC
No repro with:
Version: 5.4.0.0.alpha0+
Build ID: a9f56091b6422ec8c42f09b8472200ae4ab12548
CPU Threads: 4; OS Version: Windows 6.19; UI Render: default; 
TinderBox: Win-x86@42, Branch:master, Time: 2016-12-05_23:12:26
Locale: nl-NL (nl_NL); Calc: CL