I ran the unit tests and I am getting a failure in StandardTestSuite - testEquals.
The reason for the failure is a change in ColorUtil (see 4/ lower). Would changing the test to no longer check for unequality between two returned Color objects be an option? Thanks, Peter > -----Original Message----- > From: Peter Coppens [mailto:[EMAIL PROTECTED] > Sent: Tuesday, October 10, 2006 9:32 PM > To: fop-dev@xmlgraphics.apache.org > Subject: Re: Including an sRGB color profile? > > > I finished(?) working on the somewhat modified items (1), (2) and (4) of > Jerememias' list. > > I plan to clean up to code a bit and then try to submit a patch (there > should be a first time for everything I guess :)) > > Here is an overview of what has been done - probably belongs in the patch > as > well, but if someone, despite the length of this post, decides to go > through > it anyway, an upfront red flag can be waved if needed, keeping me from > going > through the patch process..... > > > From the users point of view. > > The rgb-icc function is accepted as input for color properties of fo > elements and the generated PDF will include and refer to those color > profiles. Other renderers will use profile based converted sRGB values. > The > ICC profiles are loaded using the src attribute from the color-profile > element. The uri resolution relies on how the Java VM resolves color > profiles. > > A cmyk function accepting 4 arguments (values ranging from 0%-100% or > 0.0-1.0) is also available. The PDF renderer will generate DeviceCMYK > colors > based on the provided values, the other renderers will use a "standard" > cmyk-rgb conversion and generated rgb colors. > > > Implementation wise the following changes were done > > > org.apache.fop.fo.expr.PropertyParser > > 1/ > FunctionTable has two new functions, cmyk and rgb-icc linked to two new > classes CMYKcolorFunction and ICCcolorFunction > > 2/ > parsePrimaryExpr recognizes functions that return a negative number from > the > nbArgs as variable argument functions. Those are parsed with a new method, > parseVarArgs > > org.apache.fop.fo.expr.CMYKColorFunction > > New function class for the cmyk function > > org.apache.fop.fo.expr.ICCColorFunction > > New function class for the rgb-icc function. It is a somewhat peculiar > function class for two reasons. > > First, it returns an negative number for nbArgs (flagging a variable > number > of arguments function). > > Second its eval method returns a string that contains a fop-rgb-icc > function > call. The arguments for this new function are the same as the one of rgb- > icc > with the exception of the fifth, which is an extra argument that contains > the src attribute for the color profile (from > /root/declarations/color-profile/@src) > > An alternative suggested by Jeremias was to introduce a color context > tracking the mapping between ICC profile name and src. Certainly a more > elegant approach but it would require more classes to be touched something > I > was reluctant to do (this being my first attempt to a fop contribution) > > > org.apache.fop.fo.pagination.Declarations > > Added a new method > public ColorProfile getColorProfile(String cpName) > > org.apache.fop.fo.pagination.ColorProfile > > Added a new method > public String getSrc() > > > org.apache.fop.util.ColorUtil > > 1/ > Added a static member referring to a/the Log object > > 2/ > Added a static (synchronized) Map, colorSpaceMap, mapping color profile > src's to ICC_ColorSpace instances. > > 3/ > parseColorString > > Now also recognizes fop-rgb-icc and cmyk functions invoking > parseAsFopRgbIcc > or parseAsCMYK. > > 4/ > Removed cloning of the Color object before returning from parseColorString > (has a TODO in the current code) > > 5/ > Added > private static Color parseAsFopRgbIcc(String value) > throws PropertyException > > If the color profile src (5th argument) is not available in the > colorSpaceMap cache, an attempt is made to create an ICC_Profile and > associated ICC_ColorSpace based on the src. If successful, the ColorSpace > is added to the cache, if not the fallback rgb values are used to create > an > rgb based color. If an ICC_ColorSpace is available an RgbIccColor (new > class) object is created. > > 6/ > Added > private static Color parseAsCMYK(String value) > throws PropertyException > > Parses cmyk arguments and creates a Color from a CMYKColorSpace color > space. > > > 7/ > colorTOsRGBString > > Changed to recognize and handle cmyk and rgb-icc colors. Perhaps the name > of > the function should be changed? > > > > org.apache.fop.util.CMYKColorSpace > > Implemented > public float[] toRGB(float[] colorvalue) > > > org.apache.fop.util.RgbIccColor > > New Color class keeping track of the rgb-icc arguments and color profile > src > information. > > > > org.apache.fop.pdf.PDFColor > > 1/ > > Added a private RgbIccColor member. This is probably the least elegant > change in this patch. > > There is something I do not understand with the way PDFColorSpace, > PDFDeviceColorSpace and PDFPathPaint are used. PDFPathPaint has a > PDFDeviceColorSpace member while for me and at least at first sight it > would > make more sense to use a PDFColorSpace member in stead. Changing that > would > however result in quite a few changes lots of which would occur in code I > have no clue when it would be called. > > The alternative approach I took is to add an RgbIccColor member which is > only filled in when the PDFColor is created from an RgbIccColor source in > PDFColor(java.awt.Color col). > > Eventually, perhaps when svg rgb-icc and cmyk support is added, this will > have to be dealt with. > > Bottom line is I would prefer to see these first set of changes rolled in > before starting to add changes to code not well understood. > > 2/ > public PDFColor(java.awt.Color col) > > Recognize Color instances based on CMYK or RgbIccColor and store relevant > information > > 3/ > public String getColorSpaceOut(boolean fillNotStroke) > > Recognize RgbIccColor based PDFColor instances and act accordingly > > > > org.apache.fop.render.pdf.PDFRenderer > > protected void setColor(Color col, boolean fill, StringBuffer pdf) > > When color is an RgbIccColor instance the ICC profile is added to the pdf > when needed. > > > Peter > > > > Peter Coppens wrote: > > > > Jeremias > > > > That is certainly a good start in terms of information to digest. > > > > I'll give it some time to sink in, and I'll try to browse through the > code > > a bit the coming week to see how familiar I can get with it in that > time. > > > > Thanks, > > > > Peter > > > > > > > > > > Jeremias Maerki-2 wrote: > >> > >> 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 > >> > >> > >> > > > > > > -- > View this message in context: http://www.nabble.com/Including-an-sRGB- > color-profile--tf1373500.html#a6743661 > Sent from the FOP - Dev mailing list archive at Nabble.com.
