Download it now!
Bug 117638 - FILEOPEN: Corrupt image when loading RTF file
Summary: FILEOPEN: Corrupt image when loading RTF file
Status: NEW
Alias: None
Product: LibreOffice
Classification: Unclassified
Component: Writer (show other bugs)
Version:
(earliest affected)
5.0 all versions
Hardware: All All
: medium normal
Assignee: Not Assigned
URL:
Whiteboard:
Keywords: notBibisectable, regression
Depends on:
Blocks: RTF-Images
  Show dependency treegraph
 
Reported: 2018-05-16 08:38 UTC by Milan Bouchet-Valat
Modified: 2019-12-30 09:03 UTC (History)
4 users (show)

See Also:
Crash report or crash signature:


Attachments
RTF file to reproduce the problem (403.72 KB, application/rtf)
2018-05-16 08:38 UTC, Milan Bouchet-Valat
Details
DOCX file which is loaded correctly (273.58 KB, application/vnd.openxmlformats-officedocument.wordprocessingml.document)
2018-05-16 08:39 UTC, Milan Bouchet-Valat
Details
how it looks in MS2010 (164.13 KB, image/png)
2018-05-30 15:34 UTC, Xisco Faulí
Details

Note You need to log in before you can comment on or make changes to this bug.
Description Milan Bouchet-Valat 2018-05-16 08:38:25 UTC
Description:
In the attached RTF file, the first image isn't rendered correctly. And when saving it to an external file, only a small part of the actual image is used.

The correct image can be seen by loading the second attached file, which is a .docx version of the first one, saved using MS Word.

Steps to Reproduce:
Load attached .rtf file.

Actual Results:  
Image is corrupt.

Expected Results:
Image should look like in the .docx file.


Reproducible: Always


User Profile Reset: No



Additional Info:


User-Agent: Mozilla/5.0 (X11; Fedora; Linux x86_64; rv:60.0) Gecko/20100101 Firefox/60.0
Comment 1 Milan Bouchet-Valat 2018-05-16 08:38:54 UTC
Created attachment 142122 [details]
RTF file to reproduce the problem
Comment 2 Milan Bouchet-Valat 2018-05-16 08:39:35 UTC
Created attachment 142123 [details]
DOCX file which is loaded correctly
Comment 3 Milan Bouchet-Valat 2018-05-16 08:40:08 UTC
I should have noted that the problem is still in present in LO 6.0.3.2.
Comment 4 Roman Kuznetsov 2018-05-20 06:34:18 UTC
Confirmed on LO 6.0.4.2 (64 bit) on Xubuntu 17.10 (64-bit)

Milan, please add info from dialogue Help > About
Comment 5 Xisco Faulí 2018-05-30 15:34:05 UTC
Created attachment 142412 [details]
how it looks in MS2010
Comment 6 Xisco Faulí 2018-05-30 15:42:47 UTC
I can reproduce it back to

Version: 5.0.0.0.alpha1+
Build ID: 0db96caf0fcce09b87621c11b584a6d81cc7df86
Locale: ca-ES (ca_ES.UTF-8)

but not in

Version: 4.5.0.0.alpha0+
Build ID: 2c5ce8ea8eb98f2d82986448af448d11b60a3ea1
Locale: ca_ES

it needs to be bisected with bibisect-50max
Comment 7 Buovjaga 2018-06-07 08:26:00 UTC
I declare this notBibisectable after about 2 hours of trying, having to mostly git bisect skip due to General error in opening. I got as far as "756 revisions left to test after this" (Win 5.0 repo)
Comment 8 Aron Budea 2018-12-09 07:11:50 UTC
A note here, this bug started in two steps, because even before the change in 5.0, the order of images is reversed. In 3.3.0 the order is correct, in 3.5.0.3 the images aren't imported, and in 4.2.0.4 they appear, but the legend is above the chart, while it should be below.
Comment 9 QA Administrators 2019-12-10 04:00:22 UTC Comment hidden (obsolete)
Comment 10 Roman Kuznetsov 2019-12-30 09:03:37 UTC
still repro in

Version: 6.5.0.0.alpha0+ (x64)
Build ID: 42a1a1c6b91907f81e15066ffab219411f18c4db
CPU threads: 4; OS: Windows 10.0 Build 18362; UI render: default; VCL: win; 
Locale: ru-RU (ru_RU); UI-Language: en-US
Calc: threaded