Sun's new Java Advanced Imaging I/O Tools 1.0-RC plug-in writes CMYK JPGs in such a way that FOP believes the CMYK sample values are inverted when they are not. This leads to CMYK JPGs looking really, really bad.
Is this a problem from JAI's side or from FOP's side? IOW, should FOP be able to tell from the file itself whether to invert or not? Or is Sun writing the image wrong? Or is this a limitation in the JPG format?
Alas, we're bumping up against my limitations here. Here's my understanding:
The JPG spec. is rather vague when it comes to color spaces, preferring to leave that as an implementation detail. Thus, there's some freedom in how vendors encode color space information with their images.
JPEG stores metadata in various "markers". One marker, the APPE marker, is used by Adobe to store various data dealing with color space encoding. Other vendors / users have opted to use the Adobe's APPE marker specification to store color space information as well, building on Adobe's work.
The problem is that Adobe inverts the CMYK color space values. FOP therefore takes a shortcut and whenever it finds the APPE marker, it assumes that Adobe has written the image and thus the values must be inverted. The code does *not* check if the values are in fact inverted, which in a comment in acknowledges it should.
In this case, it would appears that JAI follows what seems to be a popular industry practice and uses the APPE marker to store information about the color space encoding, but does *not* invert the colors and I can only assume correctly records this information in the APPE marker.
Thus, the problem we're experiencing. To be fair, it appears that other popular products make the same assumption (such as iText), and to be honest, I might be misunderstanding this issue.
Depending on the answer to my question above, is it possible to make FOP's logic more definite? I would lean more toward such a solution, if it is feasible, than toward a configuration option that would force one result or another for all images in the document.
I think it is possible to patch FOP to properly detect whether or not to invert the image from the APPE marker values, rather than the presence of the marker. I'm not sure how to do it, yet. I 'spose I should figure it out!
Excellent. Do you have any interest in helping us track down the more robust solution (if it exists)?
Sure, I'll start tracking it down in my spare time.
Ben
--------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
