Ok, so here's a rough overview what needs to be done. No guarantee for completeness or accuracy.
1. Implementation of the rgb-icc() function. See also: http://www.antennahouse.com/xslfo/axf4-extension.htm#rgb-icc http://www.renderx.com/reference.html#Color_Specifiers Whether the #CMYK pseudo-profile is really needed or if ICC colors are sufficient, I cannot say at this time. In the end, the function needs to generate a java.awt.Color (or descendant if necessary). I'm not sure if the rgb-icc() function can sufficiently be mapped into FOP's function infrastructure because it uses a non-constant number of parameters. 2. Internal representation of colors Thanks to Max Berger FOP already uses java.awt.Color throughout the layout engine so we don't have to worry much anymore how the color information is transported to the renderers. However, I can't tell if Java's color infrastructure is up to the task of transporting the color information as we need it for CMYK support. 3. org.apache.fop.image package This package is in need of a redesign for various reasons, one of them being that it doesn't use RenderedImage/BufferedImage internally to represent decoded images. Instead it uses byte arrays with decoded RGB data. In order to properly support CMYK not only for JPEGs, the refactoring will need to be done if we want a clean solution. 4. Improving the renderers to implement CMYK I assume the PDF renderer is the most important here. It needs to be able to deal with the additional color types. But the other renderers at least shouldn't fail when they encounter non-RGB data. The PDF library is another place to look out for color stuff (like the PDFColor class). PDF profiles like PDF/A-1b and PDF/X-3:2003 will also need to be verified to work again after CMYK support is there. Having CMYK support enables the implementation of other PDF/X standards. 5. SVG support As XSL-FO, SVG is primarily operating in the sRGB space, but has extensions for ICC color (icc-color() function in SVG). I'm not sure about the status of ICC color support in Batik, so this has to be investigated. At any rate, there will need to be some changes to handle CMYK requirements for SVG graphics. Otherwise, you will only get RGB/sRGB colors in the PDF. That's quite a bit to do. I guess it would make sense to start a Wiki page to write down all the info around the topic, gather knowledge, to track progress and to coordinate. As for estimates, that's actually quite difficult at this time, without further investigation. Point 1 shouldn't be all that hard, maybe a day or so. Point 2 is probably ignorable except if AWT cannot hold the color information like we need it. Point 3 is larger, probably 4 to 5 days. It will take some more investigation and design. I've got a idea how this should look like but so far I haven't written it down. I've only done some requirements gathering on http://wiki.apache.org/xmlgraphics-fop/ImageSupport. Point 4 is probably not that difficult but a lot of tedious work which involves a lot of testing and reading specifications. I assume it's another 3 to 4 days. Point 5 is difficult to estimate at this time. Add at least a couple of days if you're not familiar with color handling and the PDF specification. The good news is that all this doesn't require knowledge about the layout engine which simplifies getting into this a lot!!! But of course, there's still a lot to learn about colors, PDF and PDF profiles. Point 3 is on my middle-term radar, as is the rest but with lower priority. So it's most likely I can help with the image package, but not immediately. Ideas and guidance, sure, but not code at this time. On 20.09.2006 22:48:20 Peter Coppens wrote: > > FOP fans, > > I could also use cmyk support in fop. My options are to buy some xsl fo > implementation that supports it or trye to contribute to fop (assuming the > community lets me) > > Could someone give me a very rough estimate on how much work it would > require, including getting acquainted with the fop architecture. > > Thanks, > > Peter > > > > Jeremias Maerki-2 wrote: > > > > > > On 31.03.2006 21:48:43 Max Berger wrote: > >> I know I have no vote in this, but I do disagree. > > > > Every opinion is always welcome. > > > >> 1) I still believe that PDF is a print medium and should therefore > >> default to CMYK colorspace. If supported correctly by software, the > >> colors should show up right on the screen. > > > > One use case of PDF is as a print medium, but it's not the only one. If > > we're talking about producing documents for offset printing, then yes, I > > agree with you. Fact is that most PDF-producing software packages I know > > produce RGB (either uncalibrated DeviceRGB or sRGB). This applies to > > OpenOffice, Acrobat Distiller with its default settings, GhostScript. > > The list probably goes on. > > > > Supporting CMYK in FOP means some additional work which I don't have > > time for (and don't really have a need myself). The client that has > > asked me to implement PDF/A-1 is happy with sRGB since it's only about > > patent documents. If someone (you?) implements an option to generate a > > full CMYK PDF, then I'm all for adding that since it has been requested > > a number of times. But doing that per default would be a change in > > long-standing standard FOP behaviour which I don't support. > > > >> 2) If you want to embedd the sRGB profile, I would recommend using the > >> profiles found at the International Color Consortium: > >> http://www.color.org > >> > >> especially > >> > >> http://www.color.org/srgbprofiles.html > >> > >> unfortunately I was unable to find the exact licensing terms. > > > > That's exactly why I didn't use them. Licensing terms are not clear. On > > the other side, Adobe & Co. are distributing the sRGB profile from > > srgb.com, not from color.org. It's also unclear to me which of the two > > variants (withBPC/noBPC) would have to be used. > > > >> just my 2 cts. > >> > >> Max > >> > >> > >> Jeremias Maerki wrote: > >> > I'm near the end of my work for basic PDF/A-1b support. PDF/A-1b > >> > mandates the use of an OutputIntent if uncalibrated color spaces (like > >> > DeviceRGB) are used. That means that in each PDF which has PDF/A-1b > >> > enabled an ICC color profile will be embedded and used in the > >> > OutputIntent object. Since we don't support ICC-based colors, yet, I've > >> > hard-coded sRGB into PDF/A-1b support (XSL-FO supports sRGB and > >> > ICC colors, XSL 1.0, 5.9.9). But that means I need to embed the sRGB > >> > IEC61966-2.1 color profile. The JRE provides such a color profile but > >> > does this is a weird way: the profile alone is about 140KB. That's why > >> > I'd like to use the standard sRGB profile from HP. Info on that file: > >> > > >> > Obtained from: http://www.srgb.com/usingsrgb.html > >> > > >> > The file "sRGB Color Space Profile.icm" is: > >> > Copyright (c) 1998 Hewlett-Packard Company > >> > > >> > To anyone who acknowledges that the file "sRGB Color Space Profile.icm" > >> > is provided "AS IS" WITH NO EXPRESS OR IMPLIED WARRANTY: > >> > permission to use, copy and distribute this file for any purpose is > >> hereby > >> > granted without fee, provided that the file is not changed including > >> the HP > >> > copyright notice tag, and that the name of Hewlett-Packard Company not > >> be > >> > used in advertising or publicity pertaining to distribution of the > >> software > >> > without specific, written prior permission. Hewlett-Packard Company > >> makes > >> > no representations about the suitability of this software for any > >> purpose. > >> > > >> > I need to get the license approved by the VP legal affairs but I don't > >> > expect any problems. > >> > > >> > Anyone against me including this color profile (3144 bytes, > >> uncompressed) > >> > in the org.apache.fop.pdf package? > >> > > >> > Jeremias Maerki > > > > > > > > Jeremias Maerki > > > > > > > > -- > View this message in context: > http://www.nabble.com/Including-an-sRGB-color-profile--tf1373500.html#a6416371 > Sent from the FOP - Dev mailing list archive at Nabble.com. Jeremias Maerki
