Hello again,

Today I played with the FOP PDF package and I seem to making good progress.

That means that besides (1) from below I think I can move forward with (3)
as well. The idea is to have rgb-icc support for pdf output. All other
renderers could use the rgb fallback values specified in the rgb-icc
function. That looks easy enough by extending the Color class that is now
used to carry the color information through the different layers and make
that behave as an rgb Color object, except for the pdf renderer which could
gather the icc parameters from the class instance.

Something that is not clear to me in this context is whether cmyk support
can be sufficiently covered by always relying on icc profiles. That would
mean either fop should package a cmyk profile or the user should get one
from somewhere. To be honest, the #CMYK approach, that then generates
/DeviceCMYK colors seems rather nice (from a users' perspective).

Anyone any thoughts?

Also - any pointers for me to figure out what it would take to get these
changes into the fop code base eventually?

Thanks,

Peter





Peter Coppens wrote:
> 
> So i have started to look into this today.
> 
> Starting at the beginning, I am looking into 
>   1. Implementation of the rgb-icc() function.
> 
> I have added the necessary code to get the function and its arguments
> parsed and I am now about to create the java.awt.Color object in
> ColorUtil#parseAsRgbIccColor
> 
> What is not clear to me is how I can get hold of the color-profile
> information (as in 
>     <fo:declarations>
>         <fo:color-profile color-profile-name="...." src="..."/> ?
>     </fo:declarations>
> )
> 
> 
> I did bump into the ColorProfile object getting created but I am not sure
> what the best way is to get hold of that object from the parseColorString
> method
> 
> Any guidances would be appreciated.
> 
> Thanks,
> 
> 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#a6679791
Sent from the FOP - Dev mailing list archive at Nabble.com.

Reply via email to