I had problem sending this mail and try it again, so my apologize to people who receive this mail twice. ========================================================== Hi, I looked into the sources. The Decode array insertion is hardcoded whenever a jpeg image with colorspace CMYK is included. The support of additional colorspace was added by request of Hans Hagen IIRC, he needed a mean to change the default colorspace of images. So it was done with this assumption: if someone supplies his own colorspace, he is responsible for everything related. I am not sure what can be done with this, since it's hard to define the right behaviour of pdftex in this situation. My vote is to leave things as they are, and document relevant issues in the manual. Thanh PS: I uploaded the test files here: http://www.sendspace.com/file/rc04al On Thu, May 03, 2007 at 08:48:10PM +0200, Pawel Jackowski wrote:
Hi!
While making a sample for Jano in BachoTeX I've found the following issue. Please consider the attached example.
pdfTeX automatically recognizes embedded JPEG colorspace. I guess it also reads decoding parameters from the image and (re)inserts them to PDF if necessary; in the first case one may see
/ColorSpace /DeviceCMYK /Decode [1 0 1 0 1 0 1 0]
key in XObject dictionary. Once the user povides 'colorspace' keyword, no /Decode is inserted, that (may) result in negative output, as in example. Obviously one can insert decoding as a custom image attribute, but one cannot control what is the proper decoding.
This happens for all cmyk jpegs from photoshop.
Cheers, -- Pawe/l Jackowski GUST, Poland P.Jackowski@gust.org.pl www.pawcoo.com www.acchsh.com
Thanh Han The wrote:
I am not sure what can be done with this, since it's hard to define the right behaviour of pdftex in this situation. My vote is to leave things as they are, and document relevant issues in the manual.
I'm with Thanh, when it comes to the actual behaviour of the program. I do not see how pdftex could distinguish between a user who is knowledgeable and purposely trying to achieve a special effect and a user who is naively doing something redundant. In the case of CMYK image files, the probability of dealing with an expert user is pretty high, so the current action seems fine to me. That said, the behaviour should be documented, and perhaps even a warning could be issued if the /Decode in the image does not agree with the PDF default value? Best, Taco
Hi, Thanh:
I am not sure what can be done with this, since it's hard to define the right behaviour of pdftex in this situation. My vote is to leave things as they are, and document relevant issues in the manual.
Taco:
I do not see how pdftex could distinguish between a user who is knowledgeable and purposely trying to achieve a special effect and a user who is naively doing something redundant. In the case of CMYK image files, the probability of dealing with an expert user is pretty high, so the current action seems fine to me.
I'm convinced in all the points. Manual updated. Thanks, -- Pawe/l Jackowski P.Jackowski@gust.org.pl
Paweł Jackowski
Thanh:
I am not sure what can be done with this, since it's hard to define the right behaviour of pdftex in this situation. My vote is to leave things as they are, and document relevant issues in the manual.
Taco:
I do not see how pdftex could distinguish between a user who is knowledgeable and purposely trying to achieve a special effect and a user who is naively doing something redundant. In the case of CMYK image files, the probability of dealing with an expert user is pretty high, so the current action seems fine to me.
I'm convinced in all the points. Manual updated.
Well, there is a point for "do what the naive user expects" rather than "do the least invasive thing". Of course, there should be an option for the expert to switch the behavior to the minimal thing if he needs it. The point is that the expert will be more likely to know that something "special" is called for, even if this "something special" consists in _not_ doing something. It appears to me like the files in question might certainly constitute something that might crop up in a naive user's workflow. Having them get false color is not going to be a selling point, even though there is a technical reason behind it and there _might_ be cases where the user indeed prefers the system not interfering. But those, I think, would be the special cases. That being said, I am clearly out of my depth here with regard to the technical issues involved and possible solutions, so I have to accept the expert's decisions on them. -- David Kastrup
2007/5/7, David Kastrup
That being said, I am clearly out of my depth here with regard to the technical issues involved and possible solutions, so I have to accept the expert's decisions on them.
CMYK-JPEGs are not something the average TeX user will ever see. They are even rare in preprint environments, as the JPEG/JFIF standard allows only 3 colors (YCbCr). Best Martin
participants (5)
-
David Kastrup -
Martin Schröder -
Paweł Jackowski -
Taco Hoekwater -
Thanh Han The