Bug 37691 - FILEOPEN: [RTF] embedded picture invisible, rendering messed up.
Summary: FILEOPEN: [RTF] embedded picture invisible, rendering messed up.
Status: RESOLVED FIXED
Alias: None
Product: LibreOffice
Classification: Unclassified
Component: Writer (show other bugs)
Version:
(earliest affected)
3.3.2 release
Hardware: All All
: medium minor
Assignee: Miklos Vajna
URL:
Whiteboard: target:4.4.0
Keywords:
Depends on:
Blocks:
 
Reported: 2011-05-28 06:44 UTC by Ihar Filipau
Modified: 2014-09-22 16:33 UTC (History)
3 users (show)

See Also:
Crash report or crash signature:


Attachments
The problematic .doc (106.80 KB, application/rtf)
2011-05-28 06:44 UTC, Ihar Filipau
Details

Note You need to log in before you can comment on or make changes to this bug.
Description Ihar Filipau 2011-05-28 06:44:47 UTC
Created attachment 47250 [details]
The problematic .doc

I'm not sure how the .doc document was generated. I presume it was created by some scanner software. (Inspecting it in text editor reveals that it is a RTF file and most of the space in file is taken by the blob with the image.)

WinWord displays the .doc as expected: single page with a picture.

LO shows an empty page instead. Trying to type anything has no effect. ^A+^C doesn't help: nothing is pasted into the new document.
Comment 1 Rainer Bielefeld Retired 2011-05-28 08:16:43 UTC
Effect is reproducible with reporter's sampl document and "LibreOffice 3.4.0RC2  – WIN7  Home Premium  (64bit) German UI [OOO340m1 (Build:12)]". 
MS WORD Viewer shows a picture, OOo3.1.1 and OOo1.1.4 do not.

I can't tell whether the embedded picture is one that we should support.

It's an obscure document with wrong name extension (it's an .rtf pretending to be a .DOC) with unknown image contents - does not sound very important
Comment 2 Ihar Filipau 2011-05-28 08:53:20 UTC
> It's an obscure document with wrong name extension (it's an .rtf pretending to
be a .DOC) 

This is actually how WinWord saves the documents when you ask to save in "WinWord 97/2000" format: extension is .doc, but content looks like RTF.

> with unknown image contents

It's a plain JPEG (ok, for pedants: JFIF). I could extract it from the RTF with trivial perl script. LO Calc had no problems printing it later.

> does not sound very important

I'm more concerned that LO failed to behave in the case normally. One thing LO couldn't display picture - but the other thing LO behaved with the document open rather abnormally: I couldn't even type the text!

But of course, choice of priorities is up to LO.
Comment 3 Rainer Bielefeld Retired 2011-05-28 10:31:43 UTC
@IharFilipau:
> This is actually how WinWord saves the documents

so they are in Redmond ;-)

> It's a plain JPEG (ok, for pedants: JFIF).

That sounds interesting. My first suspect was that it might be EPS or similar (although document contents did not look so), but a simple JPEG should not cause any problem. might be something with the embedding.
 
> I'm more concerned that LO failed [...]

Yes, that's bad, but the same problem also for OOo, and not a general rtf problem, only with your document, as it seems. BTW, you can type (try Arial 100px and you will see some reaction), but rendering of the document will be totally messed up, it's impossibloe to recognize any character.

So it seems to be a more general "Contents invisible" problem than only "no image".
Comment 4 Don't use this account, use tml@iki.fi 2011-05-30 01:21:02 UTC
Something for Cédric? Please assign back to list if not, or if not likely you would have time to work on this in the foreseeable future anyway.
Comment 5 Rainer Bielefeld Retired 2011-08-11 22:43:55 UTC
No activity here. May be Miklós can help?

@Miklós:
Please feel free to reassign (or reset Assignee to default) if it’s not your area or if provided information is not sufficient. Please set Status to ASSIGNED if you accept this Bug.
Comment 6 Miklos Vajna 2011-08-12 03:39:38 UTC
This is fixed in my GSoC repo:

http://cgit.freedesktop.org/~vmiklos/lo-core/commit/?id=bcc2fbef8fc9eec7664fc7592fa27e7804a4fc88

I'll merge that repo to master before 2011-08-15 and you'll have this feature
if you enable experimental features. (Later hopefully it'll be the default, but
there is no decision about that yet.)
Comment 7 Jean-Baptiste Faure 2012-03-18 14:55:11 UTC
Hmm, LO 3.5.1 and LO 3.5.2 rc0+ show 2 pages, the first one is empty and the second shows the picture. 

Master (LibreOffice 3.6.0alpha0+ Build ID: 08ba87c-49d3d39-e67b1bf-879ce36-638d9c) shows 2 pages too, but the first shows the picture and the second is empty.
 
Abiword shows only one page with the picture.

Tested on Ubuntu 11.10 x86_64.

Who is right ? ;-)

Best regards. JBF
Comment 8 Rainer Bielefeld Retired 2012-03-18 22:46:10 UTC
@Jean-Baptiste Faure:
I believe you observed a new, different problem (may be related to the reported one. 

The report was 1 blank picture without picture shown", what I can confirm with "LibreOffice 3.4.5 German UI [Build ID: OOO340m1 (Build:502)]" parallel Server installation on German WIN7 Home Premium (64bit) and reporter's sample.

With "LibreOffice 3.4.6 RC1 German UI [Build ID: OOO340m1 (Build:601)]" parallel Server installation on German WIN7 Home Premium (64bit) I see a Page with an empty placeholder(?) frame instead of the picture

"LibreOffice 3.5.1.2 German UI/Locale [Build-ID: dc9775d-05ecbee-0851ad3-1586698-727bf66] on German WIN7 Home Premium (64bit) shows a first blank page and as second one with correctly shown picture.

MS word viewer shows 1 page with picture on the right half page, same with AbiWord.

I have no RTF skills, can't tell what the correct way to show the picture is.
Comment 9 Teo91 2013-09-29 13:19:15 UTC
LO 4.1.1. on Windows 7 SP1 shows a first page with correctly shown picture and a second blank page.
The second page should not exist.
Comment 10 Jorendc 2013-12-29 17:41:54 UTC
(In reply to comment #8)
> MS word viewer shows 1 page with picture on the right half page, same with
> AbiWord.
> 
> I have no RTF skills, can't tell what the correct way to show the picture is.

Looks to me like the good behavior. I can reproduce this tested using Windows 8.1 with MS Word 2010.

Tested using LibreOffice Version: 4.3.0.0.alpha0+
Build ID: 5be7ec4193b892e5643ff5f3f2e6755319569190
TinderBox: Win-x86@39, Branch:master, Time: 2013-12-27_23:55:02
Same behavior as MS Word 2010, and like Rainer said also in AbiWord.

So all 3 same behavior, looks as expected then.

Marking as RESOLVED FIXED, see comment 6 for commit
Comment 11 Commit Notification 2014-09-22 16:33:38 UTC
Caolan McNamara committed a patch related to this issue.
It has been pushed to "master":

http://cgit.freedesktop.org/libreoffice/core/commit/?id=cfbcce701cd6dc3af6086428399136efef33ff59

Related: fdo#37691 \shptxt ... \jpegblip



The patch should be included in the daily builds available at
http://dev-builds.libreoffice.org/daily/ in the next 24-48 hours. More
information about daily builds can be found at:
http://wiki.documentfoundation.org/Testing_Daily_Builds
Affected users are encouraged to test the fix and report feedback.