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...
Created attachment 112100 [details]
shows 1 correct and 2 incorrect file opens
(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?
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.
Created attachment 112253 [details]
reduced docment showing problem
File attached is .docx saved from 18.104.22.168
TESTING on Ubuntu 14.04 + LO 22.214.171.124
(In reply to mike.hall from comment #3)
> 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
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: 126.96.36.199
Build ID: a3603970151a6ae2596acd62b70112f4d376b99
and Version: 188.8.131.52.alpha0+
Build ID: b3b4bbaf6cbd2226b659fea7d6ae473ccf84e9dd
TinderBox: Win-x86@39, Branch:master, Time: 2015-01-12_06:13:44
Migrating Whiteboard tags to Keywords: (possibleRegression)
No repro with:
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