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