Apache OpenOffice (AOO) Bugzilla – Issue 98042
PDF export: lossless compressed JPEG image with CMYK color space displays corrupted
Last modified: 2013-10-13 17:14:20 UTC
When exporting a logo 'lossless' to PDF the result is dramatically different than exporting it 'optimized for JPEG', quality level 100%. In the latter case it is OK, in the first case it is rubbish. See attached example
Created attachment 59363 [details] example logo
I checked with "Ooo 3.0.0 (DE) Multilingual version German UI WIN XP: [OOO300m9 (Build9358)]" and can confirm the reported effect. It's something very special with that special picture. I can't reproduce the problem with other pictures, even not with "10000000000015E60000089F76568C01.jpg" extracted from "test_lossless.odp" @docb: Can you please provide the original picture file and some information how it has been created? Pls. specify your OS!
Created attachment 59395 [details] original logo
The original picture was received from an advertising agency. I have to ask which program they use to create it. I tested it on OpenSUSE 11.1 OOO300m21 (Build:9319) and WinXP OOO300m9 build 9358
The jpg was exported from Corel Draw
I believe that that is some special "copyright-trick" by the creator. When I open Hanse Vertrieb - West.jpg with "EditPad Lite", I find several funny lines starting with "n~ûlÿ" and all same contents near by the beginning of the document. After I deleted all those "same length lines" and saved again as .jpg, the image still looked unchanged, but the lossless export problem had vanished.
No, no malevolence involved :-) Incidentally I just had a look and the file is a JPEG, but unlike almost every other JPEG it is in CMYK color space. With lossless compression we enter the original file, but wrogly state it would be in RGB, which leads to the wron graphic. However simply putting the CMYK color space into the PDF results in the graphic being correctly rendered, but more black on brown than white on blue like on the display. Incidentally the previewer on the mac does the same with the original JPEG, while loading it into gimp produces the same blue and white that OOo does. Obviously we want the same result as on the display (which is more like it should be ?), so simply passing on the original file and writing CMYK as info will not work. @sj: one would need to find out if a jpeg file is CMYK encoded and in this case we want to go the normal path instead of passing it through. This however is more a matter of goodies than of vcl or pdfexport itself, could you please have a look ?
changed target
*** Issue 123461 has been marked as a duplicate of this issue. ***