Created attachment 127784 [details]
An image in the pdf exported using 2 different versions of LibreWriter (damaged image is the one exported by 5.2.2 version, intact one is exported by 5.1.5 version)
After exporting a document to PDF, an image in the output file is damaged (see attachment), while the rest remains intact. This problem only happens in 5.2.x (0-2) versions.
I test with LO 184.108.40.206 and LO 220.127.116.11.alpha0, and I can not confirm the bug.
I insert the logo.png, and export it to PDF, with default options. In both case the export is perfect.
Please describe the exact steps to reproduce the bug.
Created attachment 127862 [details]
Test document file with the image
This file contains the image that is damaged after exporting to PDF using 5.2.x (0-2) version
Build ID: ae3ec79354f7b4967e736c6a4cd7c08fc52e2b7d
CPU Threads: 4; OS Version: Linux 4.2; UI Render: default;
Locale: ca-ES (ca_ES.UTF-8); Calc: group
this is a regression as I can't reproduce it in
Build ID: 0db96caf0fcce09b87621c11b584a6d81cc7df86
Locale: ca-ES (ca_ES.UTF-8)
I can reproduce in LO 18.104.22.168.alpha1+ Build ID: 3d27afd26f7b85c46a7c7d08498000b9dbcea1c8
This is the first version of witch can I reproduce.
Something weird is going on here...
I can reproduce the bug in
Build ID: 90e2dabb8d0bb5382234be776c2ad0e2d5d9e224
Locale: ca-ES (ca_ES.UTF-8)
if I use the bibisect repository lo-linux-dbgutil-daily-till50 but I can't reproduce it using bibisect-50max at the same commit, odd.
I try with LO 22.214.171.124 32 bit (win10 ent 64 bit), Build ID: 9a0b23dd0ab9652e0965484934309f2d49a7758e
and I can NOT reproduce the bug. I don't found earlier version from 5.0.
This seems to have begun at the below commit.
Adding Cc: to Michael Meeks; Could you possibly take a look at this one? Thanks
9ff0a94931d5aba1e838c680c9604562eb2e71e2 is the first bad commit
Author: Norbert Thiebaud <email@example.com>
Date: Wed Feb 17 07:37:49 2016 -0800
author Michael Meeks <firstname.lastname@example.org> 2016-02-08 14:24:15 (GMT)
committer Michael Meeks <email@example.com> 2016-02-09 00:09:08 (GMT)
commit 76ec54e8c9f3580450bca85236a4f5af0c328588 (patch)
parent e07ffae5046e9c91ef96026435cab84c3bcb4534 (diff)
tdf#97662 - Try to preserve original compressed JPEGs harder.
Hmm - I guess there is something about this JPEG that is messing with PDF viewers' ability to extract and render it. The image itself is somewhat unusual:
JPEG 2072x1372 2072x1372+0+0 8-bit CMYK 749KB 0.000u 0:00.010
The 8-bit CMYK is I guess the problem; the vast majority of images are 8bit gray, or 8-bit sRGB (I guess).
De-compressing to RGB and re-compressing them all to make PDF export happy is an extraordinarily slow and lame thing to do ;-)
It would be good to confirm (with a small image) that the CMYK-ness of the JPEG is the issue here. Beyond that - I guess we'll need an API to cache more detailed feature information from JPEG streams - which I suspect we don't currently have.
Also in Windows.
The bug still exists in all 5.2.x versions and 5.3.0 release.
Confirmed. Another test image: http://www.mathcomp.uni-heidelberg.de/service/logos-templates/ from http://www.mathcomp.uni-heidelberg.de/service/logos-templates/
Vedran, which is the example image on that page?
Whoops, pasted the same link twice. This one: http://www.mathcomp.uni-heidelberg.de/fileadmin/Redakteure/HGS_Templates/HGSMC_blue.jpg
What were the steps you followed? I inserted it in a document, then exported the document to PDF, but the image looked the same (LO 126.96.36.199 / Windows 7). Maybe you did something differently?
So the underlying issue isn't created by the commit identified in comment 8, it just makes the issue occur more frequently. If the original JPGs are preserved and they are CMYK (that's the likely cause), this bug happens.
In fact, the bug can be reproduced by following steps even in 3.3.0:
- Open / create a document with such a JPG included,
- Select File -> Export as PDF...,
- Select Lossless compression, uncheck Reduce image resolution, and click Export.
With these steps, Vedran's image shows similar distortion/decolorization as the reporter's (so probably some settings were different from default).
The regression part is what's been reported in bug 105954, fixing that should reduce the occurrence of this issue. Adjusting keywords and version field.
*** Bug 106095 has been marked as a duplicate of this bug. ***
I have just noticed this issue in 5.2. Always reproducible.
I feel it started about the same time as bug 104479 so may be related to the patch that caused that.