Bug 36116 - EDITING: 'Break link' converts jpg format pictures to png format
Summary: EDITING: 'Break link' converts jpg format pictures to png format
Status: RESOLVED FIXED
Alias: None
Product: LibreOffice
Classification: Unclassified
Component: Writer (show other bugs)
Version:
(earliest affected)
3.3.2 release
Hardware: x86-64 (AMD64) All
: high major
Assignee: Not Assigned
URL:
Whiteboard:
Keywords:
Depends on:
Blocks:
 
Reported: 2011-04-10 07:43 UTC by Rainer Bielefeld Retired
Modified: 2017-06-02 21:13 UTC (History)
5 users (show)

See Also:
Crash report or crash signature:


Attachments
Sample Document, see original report! (241.65 KB, application/x-zip-compressed)
2011-04-10 07:43 UTC, Rainer Bielefeld Retired
Details
another test file (75.73 KB, application/zip)
2011-07-14 07:10 UTC, Alex 'AdUser' Z
Details
File with test images and documents (1.82 MB, application/zip)
2011-08-11 12:48 UTC, 1000dead
Details

Note You need to log in before you can comment on or make changes to this bug.
Description Rainer Bielefeld Retired 2011-04-10 07:43:43 UTC
Created attachment 45459 [details]
Sample Document, see original report!

My LibreOffice 3.3.2  – WIN7  Home Premium  (64bit) German UI [OOO330m19 (Build:202 / tag 3.3.2.2)]" converts linked images from .jpg to .png when I embed them.

Steps to reproduce:
0. Download and unzip attached Testkit.zip
1. Open presentation "Sample0.odp"
   containing links to also integrated .jpg pictures
2. Menu 'Edit > Links'
3. Select (mark) all selected images4 Click <Break Links>
4. Save as "Sample1.odp"
5. close document
6. Create a copy of "Sample1.odp" (Name may be "CopyOfSample1.odp")
7. rename "CopyOfSample1.odp" to "CopyOfSample1.zip"
8. Unzip "CopyOfSample1.odp" to folder "CopyOfSample1"
9. go to folder "CopyOfSample1/Pictures"
10. Check Pictures!
    Expected: 5 .jpg in folder
    Actual: 5 .png in folder

That's not wanted because it will cause gigantic document size for slide shows with complex images.

No .png conversion in OOo-dev 3.4

We had a similar Issues in OOo:
Impress converts jpg images to png resulting in big files and slow performance  
<http://openoffice.org/bugzilla/show_bug.cgi?id=60661>
Break link converts bmp, jpg, png and gif to png format
<http://openoffice.org/bugzilla/show_bug.cgi?id=15508>
Comment 1 Rainer Bielefeld Retired 2011-04-10 07:51:58 UTC
It seems that the problem is not limited to Presentation, I also saw it in a WRITER document after I broke links to 3 Smiley pictures from testkit.
Comment 2 tester8 2011-06-16 14:44:51 UTC
NOT Reproduced with

Ubuntu 10.04.2 x86
LO 3.4

JPEGs have names like 10000000000001880000019C2171442D.jpg, not 1.jpg.

Fixed in 3.4 or Windows specific?
Comment 3 noname 2011-06-25 06:22:19 UTC
Reproduced with go-oo OpenOffice.org 3.2.1 OOO320m19 (Build:9505).

NOT Reproduced with LibreOffice 3.4.1 OOO340m1 (Build:101).

All running on Win2K.

Seems this bug is already fixed.
Comment 4 Alex 'AdUser' Z 2011-07-14 04:29:24 UTC
Reproduced with:
LO 3.4.0 // WinXP
LO 3.4.1 // WinXP (exact version - OOO340m1 (Build:103))
LO 3.4.1 // Archlinux (exact version - OOO340m1 (Build:103))

Seems like it's still not fixed. If needed, i can upload additional test file.
Comment 5 Rainer Bielefeld Retired 2011-07-14 04:52:41 UTC
For me it's no longer reproducible with my old testkit, neither with Master "LibO-dev 3.4.5  – WIN7  Home Premium  (64bit) English UI 
[(Build ID:d337f79-a24c961-2865670-9752b71-7f8fd43
	2fdd60d-fd28b6a-fd7bf20-aa369cb-28da3fb
	6a9633a-931d089-ecd263f-c9b55e9-b31b807
	82ff335-599f7e9-bc6a545-1926fdf)]" 
nor with "LibreOffice 3.4.1  - WIN7  Home Premium (64bit) German UI [OOO340m1 (Build:103)]".

No idea what might be different in Alex's test.

@Alex:
What is your result with my attached test kit?
Please upload a similar test kit so that we can try to confirm your results.
Comment 6 Alex 'AdUser' Z 2011-07-14 07:10:16 UTC
Created attachment 49083 [details]
another test file

@Rainer Bielefeld
I'm sorry, just tested your file - it becomes working.
I should have done it before my first post.


But i still have unexpected image format conversion in another test file (attached). Original test file takes more than 7 mb, so i post only one cell from it (taken from real price list).

Im sure that embedded picture is jpeg - specific signatures "0xff 0xd8 0xff ..." - for start of file, then EXIF data. Besides this, i've found many occurences of the strings like 'dc:format="image/jpg"' in my original 'big' file.

How to reproduce:
Just unzip, open and try to save in .ods or even back in .xls.

Resulting file will be much bigger than original. By extractng images from .ods you may sure, that embedded pictures become .png's.

P.S. English isn't my native language, so i sorry for wrong grammar, if any.
Comment 7 tester8 2011-07-15 12:34:32 UTC
NOT Reproduced with last testfile.

LO 3.4.1 (OOO340m1 (Build:101))
Ubuntu 10.04.2 x86
Linux 2.6.32-32-generic Russian UI
Comment 8 Rainer Bielefeld Retired 2011-07-15 23:33:46 UTC
Due to latest test results WFM
Comment 9 1000dead 2011-08-10 14:17:20 UTC
(In reply to comment #8)
> Due to latest test results WFM



I have the same problem on Win2k with Libreoffice 3.4.2 Build 203

Jpeg inserted is converted to png when link is broken.



However, I have the no problem on Archlinux with Libreoffice 3.4.2 Build 203
Comment 10 Rainer Bielefeld Retired 2011-08-10 22:51:55 UTC
Strange effects!

@1000dead:
Can you please attach a sample document that still shows the behavior with 3.4.?
Comment 11 1000dead 2011-08-11 12:48:52 UTC
Created attachment 50142 [details]
File with test images and documents

No problem, file uploaded.


Test done on win2k. I noticed that all images which have their links broken are converted/changed in some way. 

I added a Jpg, Png and Gif.

I compress/optimize all Png files on my home system as much as possible to save space. When the link is broken to a PNG file, it increases in size. Libreoffice undoes any pre-optimisation I have already done. So it looks at least to me, like the files are not simply embedded but altered/recompressed in some way. I really don't want the program to do anything to the images other than embed them as Libreoffice wont be able to optimise the images as well as I can. I looked for any options which might tell the program not to recompress the images but I could not find one.


When I add a Jpg, break the link, it is converted to Png.

When I add a Gif, break the link, it is not converted 'but', it is altered, the file size more than doubles!

Yes, it's all a bit strange. I've stopped using libreoffice for the moment for some of my work, not wanting to make any more changes to a number of very large files with many images I have.

Another small bit of information, don't know if it's relevant. As I break the link on each picture one at a time, it's pretty quick, click break link and move on to the next. However, on the larger file in the test, I noticed I definite lag when I click break link, also the bigger the picture, the bigger the lag. I tried it later on an 8 Mb Jpg and it was really laggy. I always assumed when you break a link, the program just makes a quick list what needs to be embedded when you eventually save the document, no writing until save that is. I figured all that was needed was to note down file name and location to embed from when you save. Perhaps a some what simply view my end as a none coder.


Thanks
Comment 12 Rainer Bielefeld Retired 2011-08-11 22:33:15 UTC
[Reproducible] with "LibreOffice 3.4.2  - WIN7  Home Premium (64bit) German UI [OOO340m1 (Build:203)]" with 1000dead's test document. Also with my own writer document and 1000dead's pictures
Comment 13 Rainer Bielefeld Retired 2011-08-11 22:44:31 UTC
OS All due to Alex's results.

I't s a little strange that some testers (me included) had the result WFM, and now the problem is back? I'll still do some further tests, what might take some time, I have too much other research in the line.

But there can be no doubt, there is a bug.

@Cédric:
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 14 Rainer Bielefeld Retired 2011-08-11 22:59:20 UTC
A first quick test at least shows that the problem with 1000dead's pictures and own sample document also is reproducible with Master.
Comment 15 Glutanimate 2013-03-29 10:41:07 UTC
I can confirm this bug both under LO 3.6.5.2 and LO 4.0.2.1 with 1000dead's sample files (running Ubuntu 12.04.2 LTS).

This is something that recently surprised me when I tried to convert a document with 100+ linked jpegs into an embedded version: >700% file size increase out of nowhere.
Comment 16 vulcain 2014-02-12 15:52:46 UTC
This Bug 15508 is fixed in Apache OpenOffice 4.1

I can't reproduce this bug with the steps of comment 0 
Tested: 
* Ubuntu 12.04 x86_64 LibreOffice 3.5.7.2 Version ID : 350m1(Build:2)
* Ubuntu 12.04 x86_64 LibreOffice 4.2.0.4 Build ID: 05dceb5d363845f2cf968344d7adab8dcfb2ba71
* Windows XP x86 LibreOffice 4.1.4.2 Build ID: 0a0440ccc0227ad9829de5f46be37cfb6edcf72

I don't try the other testfile
Comment 17 Joel Madero 2015-05-02 15:41:00 UTC Comment hidden (obsolete)
Comment 18 Alex 'AdUser' Z 2015-05-07 04:19:13 UTC
Retested all three files with 4.3.3.2, 430m0(Build:2) @ Debian 7 x86

In order of appearance:

1) Testkit.zip -- works
2) test_cell.zip -- can't test, menu item "Edit > Links" seems to be inactive. After converting this file: xls -> ods, this menu item also inactive. After playing with selection (cell, note, image) - also nothing.
3) test.zip -- works, all files keeps their format (jpg, png, gif)

Should i create another bugreport? Original problem seems to be fixed.
Comment 19 QA Administrators 2016-09-20 09:36:49 UTC Comment hidden (obsolete)
Comment 20 Thomas Lendo 2017-06-02 21:13:11 UTC
Closing this bug as FIXED according to comment 18.

(In reply to Alex 'AdUser' Z from comment #18)
> Retested all three files with 4.3.3.2, 430m0(Build:2) @ Debian 7 x86
> ...
> Should i create another bugreport? Original problem seems to be fixed.
Yes, please create new bugs for follow-up bugs or other problems even if they are related to the original issue.