Ben Galbraith wrote: > 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? > When I force FOP to interpret the CMYK JPG as not inverted (by modifying > the source code), they work as they should. > > Can we document this issue on the website for posterity? Yes, but I want to understand the issue better first. > A likely fix would be to add a configuration option to FOP that forces > JPGs to either be inverted or not inverted, regardless of what FOP > thinks it should do? The code that presently determines whether or not > to invert (JpegImage.java [fop-0_20_2-maintain] 1.1.2.3, 214-215; see > also 172-182) is rather approximate. 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'd be happy to contribute such a patch, if there is interest from the > community / developers. Excellent. Do you have any interest in helping us track down the more robust solution (if it exists)? Thanks again for your efforts here. Victor Mote --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
