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 5.2.1.2 and LO 5.3.0.0.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
Reproduced in Version: 5.3.0.0.alpha0+ 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 Version: 5.0.0.0.alpha1+ Build ID: 0db96caf0fcce09b87621c11b584a6d81cc7df86 Locale: ca-ES (ca_ES.UTF-8)
I can reproduce in LO 5.2.0.0.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 Version: 5.0.0.0.alpha1+ 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 5.0.0.1 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 commit 9ff0a94931d5aba1e838c680c9604562eb2e71e2 Author: Norbert Thiebaud <nthiebaud@gmail.com> Date: Wed Feb 17 07:37:49 2016 -0800 source 76ec54e8c9f3580450bca85236a4f5af0c328588 author Michael Meeks <michael.meeks@collabora.com> 2016-02-08 14:24:15 (GMT) committer Michael Meeks <michael.meeks@collabora.com> 2016-02-09 00:09:08 (GMT) commit 76ec54e8c9f3580450bca85236a4f5af0c328588 (patch) tree 1c4d36e921be16426fc8a61c7a85bdc006e0fafa 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 5.3.0.3 / 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.
*** Bug 116829 has been marked as a duplicate of this bug. ***
I can reproduce this bug everytime in any LibreOffice application (Calc, Writer, Impress) in 5.4.x and 6.0.x version if I select Lossless compression in the export to PDF dialogue. If I check Reduce image resolution then the images are rendered correctly. This is the image I used: https://bugs.documentfoundation.org/attachment.cgi?id=141135
I get this bug in 5.4.5 even with resolution reduced. I have to ensure I check my PDFs and if I find a problem convert the offending image to RGB.
Still reproducible in Version: 6.1.0.0.alpha1+ Build ID: f1579d3d6c5f5f3a651825e035b93bee7a4f43c6 CPU threads: 4; OS: Linux 4.13; UI render: default; VCL: gtk3; Locale: ca-ES (ca_ES.UTF-8); Calc: group
I can reproduce it with 5.3.7.2 (linux opensuse). Opening the above image with gimp, converting it to RGB (Bild -> Modus -> RGB), insert it to the above test document again, the pdf will be fine. The same with another image which was also a company logo in CMYK as described in comment 9. Would be great to get this fixed.
Miklos Vajna committed a patch related to this issue. It has been pushed to "master": http://cgit.freedesktop.org/libreoffice/core/commit/?id=70537c8295f1b0a0c58b061dfca6cbc9def0d65b tdf#102928 PDF export: do recompress CMYK images It will be available in 6.2.0. 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.
Miklos Vajna committed a patch related to this issue. It has been pushed to "libreoffice-6-1": http://cgit.freedesktop.org/libreoffice/core/commit/?id=12ec0cbb301a5a895a21a850ba3c31c3abc448a1&h=libreoffice-6-1 tdf#102928 PDF export: do recompress CMYK images It will be available in 6.1.0.1. 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.
Miklos Vajna committed a patch related to this issue. It has been pushed to "libreoffice-6-0": http://cgit.freedesktop.org/libreoffice/core/commit/?id=4aaf958cdad2a19be49dbd5f9ca661753f8a94ab&h=libreoffice-6-0 tdf#102928 PDF export: do recompress CMYK images It will be available in 6.0.6. 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.
*** Bug 119062 has been marked as a duplicate of this bug. ***