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

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


FunctionTable has two new functions, cmyk and rgb-icc linked to two new
classes CMYKcolorFunction and ICCcolorFunction

parsePrimaryExpr recognizes functions that return a negative number from the
nbArgs as variable argument functions. Those are parsed with a new method,


New function class for the cmyk function


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

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)


Added a new method 
        public ColorProfile getColorProfile(String cpName)


Added a new method 
        public String getSrc()


Added a static member referring to a/the Log object

Added a static (synchronized) Map, colorSpaceMap, mapping color profile
src's to ICC_ColorSpace instances.


Now also recognizes fop-rgb-icc and cmyk functions invoking parseAsFopRgbIcc
or parseAsCMYK.

Removed cloning of the Color object before returning from parseColorString
(has a TODO in the current code)

        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.

        private static Color parseAsCMYK(String value) 
          throws PropertyException

Parses cmyk arguments and creates a Color from a CMYKColorSpace color space.


Changed to recognize and handle cmyk and rgb-icc colors. Perhaps the name of
the function should be changed?


        public float[] toRGB(float[] colorvalue)


New Color class keeping track of the rgb-icc arguments and color profile src



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.

        public PDFColor(java.awt.Color col)

Recognize Color instances based on CMYK or RgbIccColor and store relevant

        public String getColorSpaceOut(boolean fillNotStroke)

Recognize RgbIccColor based PDFColor instances and act accordingly


        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 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" 
>>> >> > 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: 
Sent from the FOP - Dev mailing list archive at Nabble.com.

Reply via email to