You are viewing a plain text version of this content. The canonical link for it is here.
Posted to fop-dev@xmlgraphics.apache.org by Jeremias Maerki <de...@jeremias-maerki.ch> on 2006/03/31 11:09:48 UTC
Including an sRGB color profile?
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
Re: Including an sRGB color profile?
Posted by Jeremias Maerki <de...@jeremias-maerki.ch>.
No, not as long as a special base URL for that is requested by anybody.
The normal base URL should be used in this case. Too many different base
URLs only causes confusion.
On 11.10.2006 16:48:38 Peter wrote:
> >
> > Would you please try to run URI resolution through
> > FOUserAgent.resolveURI()? That way we'll have a uniform URI resolution
> > everywhere.
> >
> I am trying, but have a question - does that mean a new base uri config
> setting has to be introduced, equivalent to e.g. the fontBaseURL ?
Jeremias Maerki
RE: Including an sRGB color profile?
Posted by Peter <pc...@gmail.com>.
I filed it (http://issues.apache.org/bugzilla/show_bug.cgi?id=40729)
Thanks for your patience and support. Would not have worked without it.
Next is svg I guess....but I am not sure that will be immediately. I have
only a day or so left for now.
Peter
> -----Original Message-----
> From: Jeremias Maerki [mailto:dev@jeremias-maerki.ch]
> Sent: Wednesday, October 11, 2006 6:49 PM
> To: fop-dev@xmlgraphics.apache.org
> Subject: Re: Including an sRGB color profile?
>
> Without seeing the code, no objections here. It's good to be on the safe
> side by using a synchronized Map. I'll look into the "base" parameter
> for getColorSpace() when I see the code.
>
> When you submit the first patch, please don't expect a fast turn-around,
> since right now I can't tell when I will be able to process it. I'm
> currently struggling to juggle my items on my task list and all the
> other FOP stuff (like this) in the little time I have available for FOP
> nowadays.
>
> On 11.10.2006 17:35:34 Peter wrote:
> > So I think I have it working but not without substantial changes
> >
> > A summary
> >
> > 1)FopFactory
> > ============
> > *) Added a synchronized Map, colorSpaceMap to cache ...ColorSpace
> > objects(life can be easy). Don't know whether this has to be
> synchronized.
> > Have not looked into the details of FOP MT features.
> >
> > *) Added a public method
> > public ColorSpace getColorSpace(
> > String base,
> > String iccProfileSrc)
> >
> > Kind of awkward to have to pass in the base but the only way I could see
> to
> > work around that is to have the cache in the user agent iso the factory
> >
> > 2) AreaTreeParser.Handler#setTraits
> > ===================================
> > *) Change invocation of ColorUtil.parseColorString (2x). It now needs a
> > first FOUserAgent argument
> > *) Change invocation of BorderProps.valueOf. Expects a first FOUserAgent
> > argument
> >
> > 3) NCNameProperty#getColor
> > ==========================
> > *) New first FOUserAgent argument
> > *) Invoke ColorUtil.parseColorString with the FOUserAgent argument
> >
> > 4) NumericProperty#getColor
> > ============================
> > *) New first FOUserAgent argument
> >
> > 5) PropertyParser#parsePrimaryExpr
> > ==================================
> > *) ColorProperty constructor takes new first FOUserAgent argument
> >
> > 6) SystemColorFunction#eval
> > ===========================
> > *) ColorProperty constructor takes new first FOUserAgent argument
> >
> >
> > 7) ColorProperty
> > ================
> > *) Constructor new first FOUserAgent argument
> > *) getColor - new first FOUserAgent argument
> >
> > 8) CommonBorderPaddingBackground
> > ================================
> > *) getColor - new first FOUserAgent argument
> >
> > 8) NumberProperty
> > =================
> > *) getColor - new first FOUserAgent argument
> >
> > 9) Property
> > ===========
> > *) getColor - new first FOUserAgent argument
> >
> > 10) ColorUtil has been changed to take "advantage" of these changes
> >
> >
> > I have not added a lot of tests to check the arguments which are
> accessed to
> > get hold of the FOUserAgent and the unit tests gave one NPE because one
> of
> > the arguments to one of the functions was null. I am trying to decide
> > whether more defensive checks for null arguments would make sense.
> >
> > Anyone any thoughts?
> >
> > Thanks,
> >
> > Peter
> >
> >
> >
> > > -----Original Message-----
> > > From: Jeremias Maerki [mailto:dev@jeremias-maerki.ch]
> > > Sent: Wednesday, October 11, 2006 2:29 PM
> > > To: fop-dev@xmlgraphics.apache.org
> > > Subject: Re: Including an sRGB color profile?
> > >
> > > ColorUtil, as the name implies, is a utility class and it doesn't feel
> > > right to put an instance of it in FOUserAgent. I would extract the
> > > profile caching into a separate class and put that there (or rather in
> > > the FopFactory so multiple rendering runs can use the cache). The
> > > ColorUtil methods should then usually receive an instance of the
> profile
> > > cache to work with.
> > >
> > > You will easily see from the unit tests if anything breaks. I will
> also
> > > do extensive tests when reviewing your patch. Since it probably needs
> > > some additional work afterwards, we will probably put it in a branch
> > > until it's ready to be merged back into Trunk. Don't be too afraid to
> > > change some method signatures. What needs to be done, needs to be
> done.
> > >
> > > On 11.10.2006 14:07:51 Peter wrote:
> > > > Some more information....found during the last few hours....and
> finished
> > > > typing in just before your reply came in.
> > > >
> > > > I have been trying to figure out whether it would help to add an
> > > instance of
> > > > ColorUtil to the FOUserAgent (and changing some of its methods and
> > > members
> > > > to instance level)
> > > >
> > > > Skipping to the conclusion first - in theory it seems possible to
> make
> > > > ColorUtil#parseColorString an instance method and add a ColorUtil
> > > instance
> > > > to the FOUserAgent. In theory, because API wise an FOUserAgent can
> > > always be
> > > > made available (given enough API changes) but I have no idea whether
> it
> > > will
> > > > actually be there at runtime (could be null).
> > > >
> > > > Actually there might a problem with one or more static function of
> one
> > > of
> > > > the calling classes/methods I just realize.
> > > >
> > > > Anyway, changes are rather extensive and I am not sure whether they
> will
> > > > work or break anything I overlooked.
> > > >
> > > > Please advice - I am willing to give it a try but need to decide
> asap (I
> > > am
> > > > running out of my time slot that was made available for fop dev work
> for
> > > the
> > > > coming weeks).
> > > >
> > > > Thanks,
> > > >
> > > > Peter
> > > >
> > > >
> > > > What I found out, ColorUtil is referenced from
> > > >
> > > > 1/ colorEqualTest
> > > > ==> Not an issue I guess (test)
> > > >
> > > > 2/ AreaTreeParser.Handler#setTraits
> > > > ==> Not an issue as an FOUserAgent is available
> > > >
> > > > 3/ Trait.Background#toString ==> FOUserAgent not needed
> > > > ==> Not an issue as an FOUserAgent is not needed (only colorToString
> is
> > > > called)
> > > >
> > > > 4/ NCNameProperty#getColor
> > > > ==> NO FOUserAgent ==> ISSUE
> > > >
> > > > 5/ ColorProperty#ColorProperty
> > > > ==> NO FOUserAgent ==> ISSUE
> > > >
> > > > 6/ ColorProperty#toString ==> FOUserAgent not needed
> > > > ==> Not an issue as an FOUserAgent is not needed (only colorToString
> is
> > > > called)
> > > >
> > > > 7/ XMLRenderer#addTraitAttributes ==> FOUserAgent not needed
> > > > ==> Not an issue as an FOUserAgent is not needed (only colorToString
> is
> > > > called)
> > > >
> > > > 8/ BorderProps#toString ==> FOUserAgent not needed
> > > > ==> Not an issue as an FOUserAgent is not needed (only colorToString
> is
> > > > called)
> > > >
> > > > 9/ BorderProps#valueOf
> > > > ==> NO FOUserAgent ==> ISSUE
> > > >
> > > > To summarize three invocations of ColorUtil#parseColorString give
> > > problems
> > > >
> > > > I went a level further
> > > >
> > > > 4/ NCNameProperty#getColor
> > > > ==> NO FOUserAgent ==> But all callers of getColor seem to have
> access
> > > to
> > > > something that in theory should be able to return the FOUserAgent
> > > > ==> No longer an issue
> > > >
> > > >
> > > > 5/ ColorProperty#ColorProperty
> > > > ==> NO FOUserAgent ==> But all callers of ColorProperty constructor
> seem
> > > to
> > > > have access to something that in theory should be able to return the
> > > > FOUserAgent ==> No longer an issue
> > > >
> > > > 9/ BorderProps#valueOf
> > > > ==> NO FOUserAgent ==> ==> But all callers of valueOf (one :)) seem
> to
> > > have
> > > > access to something that in theory should be able to return the
> > > FOUserAgent
> > > > ==> No longer an issue
> > > >
> > > >
> > > >
> > > >
> > > > > -----Original Message-----
> > > > > From: Jeremias Maerki [mailto:dev@jeremias-maerki.ch]
> > > > > Sent: Wednesday, October 11, 2006 2:05 PM
> > > > > To: fop-dev@xmlgraphics.apache.org
> > > > > Subject: Re: Including an sRGB color profile?
> > > > >
> > > > > Ok for me, as long as we track the outstanding issues.
> > > > >
> > > > > On 11.10.2006 12:01:19 Peter wrote:
> > > > > > >
> > > > > > > Would you please try to run URI resolution through
> > > > > > > FOUserAgent.resolveURI()? That way we'll have a uniform URI
> > > resolution
> > > > > > > everywhere.
> > > > > >
> > > > > > I understand your concern. I will look into it but the issue is
> that
> > > > > > ColorUtil is really a bunch of static methods that at this stage
> > > have no
> > > > > > access to any instance objects. I am sure that can be changed
> but I
> > > am
> > > > > > concerned this is going to ripple down to a lot of files and I
> would
> > > > > rather
> > > > > > start out by leaving as much code as possible untouched.
> > > > > >
> > > > > >
> > > > > > > Uhm, that's not so good. We were trying to avoid statics where
> > > > > possible.
> > > > > > > I'd prefer to keep that Map in FOUserAgent (per rendering
> run), or
> > > if
> > > > > > > you want to cache the profiles, we should make a cache class
> with
> > > > > > > SoftReferences similar to what is implemented in ImageFactory
> and
> > > > > attach
> > > > > > > that to the FopFactory. But I can look into this. I don't want
> to
> > > put
> > > > > > > too much on your shoulders if you don't want to. It's cool
> enough
> > > that
> > > > > > > you're putting so much energy into this.
> > > > > >
> > > > > > Basically the same issue here. ColorUtil is static....and as a
> > > (lousy)
> > > > > > excuse, I mainly just duplicated the colorMap cache
> "idea"....but I
> > > > > agree
> > > > > > one should avoid those static beasts. Not caching the
> ColorProfiles
> > > on
> > > > > the
> > > > > > other hand seems not a good idea either, from a memory
> consumption
> > > > > > perspective.
> > > > > >
> > > > > > Again (sorry for repeating myself) I would rather see this
> included
> > > and
> > > > > > continue from there...building up fop-dev experience step by
> step.
> > > > >
> > > > >
> > > > >
> > > > > Jeremias Maerki
> > >
> > >
> > >
> > > Jeremias Maerki
>
>
>
> Jeremias Maerki
Re: Including an sRGB color profile?
Posted by Jeremias Maerki <de...@jeremias-maerki.ch>.
Without seeing the code, no objections here. It's good to be on the safe
side by using a synchronized Map. I'll look into the "base" parameter
for getColorSpace() when I see the code.
When you submit the first patch, please don't expect a fast turn-around,
since right now I can't tell when I will be able to process it. I'm
currently struggling to juggle my items on my task list and all the
other FOP stuff (like this) in the little time I have available for FOP
nowadays.
On 11.10.2006 17:35:34 Peter wrote:
> So I think I have it working but not without substantial changes
>
> A summary
>
> 1)FopFactory
> ============
> *) Added a synchronized Map, colorSpaceMap to cache ...ColorSpace
> objects(life can be easy). Don't know whether this has to be synchronized.
> Have not looked into the details of FOP MT features.
>
> *) Added a public method
> public ColorSpace getColorSpace(
> String base,
> String iccProfileSrc)
>
> Kind of awkward to have to pass in the base but the only way I could see to
> work around that is to have the cache in the user agent iso the factory
>
> 2) AreaTreeParser.Handler#setTraits
> ===================================
> *) Change invocation of ColorUtil.parseColorString (2x). It now needs a
> first FOUserAgent argument
> *) Change invocation of BorderProps.valueOf. Expects a first FOUserAgent
> argument
>
> 3) NCNameProperty#getColor
> ==========================
> *) New first FOUserAgent argument
> *) Invoke ColorUtil.parseColorString with the FOUserAgent argument
>
> 4) NumericProperty#getColor
> ============================
> *) New first FOUserAgent argument
>
> 5) PropertyParser#parsePrimaryExpr
> ==================================
> *) ColorProperty constructor takes new first FOUserAgent argument
>
> 6) SystemColorFunction#eval
> ===========================
> *) ColorProperty constructor takes new first FOUserAgent argument
>
>
> 7) ColorProperty
> ================
> *) Constructor new first FOUserAgent argument
> *) getColor - new first FOUserAgent argument
>
> 8) CommonBorderPaddingBackground
> ================================
> *) getColor - new first FOUserAgent argument
>
> 8) NumberProperty
> =================
> *) getColor - new first FOUserAgent argument
>
> 9) Property
> ===========
> *) getColor - new first FOUserAgent argument
>
> 10) ColorUtil has been changed to take "advantage" of these changes
>
>
> I have not added a lot of tests to check the arguments which are accessed to
> get hold of the FOUserAgent and the unit tests gave one NPE because one of
> the arguments to one of the functions was null. I am trying to decide
> whether more defensive checks for null arguments would make sense.
>
> Anyone any thoughts?
>
> Thanks,
>
> Peter
>
>
>
> > -----Original Message-----
> > From: Jeremias Maerki [mailto:dev@jeremias-maerki.ch]
> > Sent: Wednesday, October 11, 2006 2:29 PM
> > To: fop-dev@xmlgraphics.apache.org
> > Subject: Re: Including an sRGB color profile?
> >
> > ColorUtil, as the name implies, is a utility class and it doesn't feel
> > right to put an instance of it in FOUserAgent. I would extract the
> > profile caching into a separate class and put that there (or rather in
> > the FopFactory so multiple rendering runs can use the cache). The
> > ColorUtil methods should then usually receive an instance of the profile
> > cache to work with.
> >
> > You will easily see from the unit tests if anything breaks. I will also
> > do extensive tests when reviewing your patch. Since it probably needs
> > some additional work afterwards, we will probably put it in a branch
> > until it's ready to be merged back into Trunk. Don't be too afraid to
> > change some method signatures. What needs to be done, needs to be done.
> >
> > On 11.10.2006 14:07:51 Peter wrote:
> > > Some more information....found during the last few hours....and finished
> > > typing in just before your reply came in.
> > >
> > > I have been trying to figure out whether it would help to add an
> > instance of
> > > ColorUtil to the FOUserAgent (and changing some of its methods and
> > members
> > > to instance level)
> > >
> > > Skipping to the conclusion first - in theory it seems possible to make
> > > ColorUtil#parseColorString an instance method and add a ColorUtil
> > instance
> > > to the FOUserAgent. In theory, because API wise an FOUserAgent can
> > always be
> > > made available (given enough API changes) but I have no idea whether it
> > will
> > > actually be there at runtime (could be null).
> > >
> > > Actually there might a problem with one or more static function of one
> > of
> > > the calling classes/methods I just realize.
> > >
> > > Anyway, changes are rather extensive and I am not sure whether they will
> > > work or break anything I overlooked.
> > >
> > > Please advice - I am willing to give it a try but need to decide asap (I
> > am
> > > running out of my time slot that was made available for fop dev work for
> > the
> > > coming weeks).
> > >
> > > Thanks,
> > >
> > > Peter
> > >
> > >
> > > What I found out, ColorUtil is referenced from
> > >
> > > 1/ colorEqualTest
> > > ==> Not an issue I guess (test)
> > >
> > > 2/ AreaTreeParser.Handler#setTraits
> > > ==> Not an issue as an FOUserAgent is available
> > >
> > > 3/ Trait.Background#toString ==> FOUserAgent not needed
> > > ==> Not an issue as an FOUserAgent is not needed (only colorToString is
> > > called)
> > >
> > > 4/ NCNameProperty#getColor
> > > ==> NO FOUserAgent ==> ISSUE
> > >
> > > 5/ ColorProperty#ColorProperty
> > > ==> NO FOUserAgent ==> ISSUE
> > >
> > > 6/ ColorProperty#toString ==> FOUserAgent not needed
> > > ==> Not an issue as an FOUserAgent is not needed (only colorToString is
> > > called)
> > >
> > > 7/ XMLRenderer#addTraitAttributes ==> FOUserAgent not needed
> > > ==> Not an issue as an FOUserAgent is not needed (only colorToString is
> > > called)
> > >
> > > 8/ BorderProps#toString ==> FOUserAgent not needed
> > > ==> Not an issue as an FOUserAgent is not needed (only colorToString is
> > > called)
> > >
> > > 9/ BorderProps#valueOf
> > > ==> NO FOUserAgent ==> ISSUE
> > >
> > > To summarize three invocations of ColorUtil#parseColorString give
> > problems
> > >
> > > I went a level further
> > >
> > > 4/ NCNameProperty#getColor
> > > ==> NO FOUserAgent ==> But all callers of getColor seem to have access
> > to
> > > something that in theory should be able to return the FOUserAgent
> > > ==> No longer an issue
> > >
> > >
> > > 5/ ColorProperty#ColorProperty
> > > ==> NO FOUserAgent ==> But all callers of ColorProperty constructor seem
> > to
> > > have access to something that in theory should be able to return the
> > > FOUserAgent ==> No longer an issue
> > >
> > > 9/ BorderProps#valueOf
> > > ==> NO FOUserAgent ==> ==> But all callers of valueOf (one :)) seem to
> > have
> > > access to something that in theory should be able to return the
> > FOUserAgent
> > > ==> No longer an issue
> > >
> > >
> > >
> > >
> > > > -----Original Message-----
> > > > From: Jeremias Maerki [mailto:dev@jeremias-maerki.ch]
> > > > Sent: Wednesday, October 11, 2006 2:05 PM
> > > > To: fop-dev@xmlgraphics.apache.org
> > > > Subject: Re: Including an sRGB color profile?
> > > >
> > > > Ok for me, as long as we track the outstanding issues.
> > > >
> > > > On 11.10.2006 12:01:19 Peter wrote:
> > > > > >
> > > > > > Would you please try to run URI resolution through
> > > > > > FOUserAgent.resolveURI()? That way we'll have a uniform URI
> > resolution
> > > > > > everywhere.
> > > > >
> > > > > I understand your concern. I will look into it but the issue is that
> > > > > ColorUtil is really a bunch of static methods that at this stage
> > have no
> > > > > access to any instance objects. I am sure that can be changed but I
> > am
> > > > > concerned this is going to ripple down to a lot of files and I would
> > > > rather
> > > > > start out by leaving as much code as possible untouched.
> > > > >
> > > > >
> > > > > > Uhm, that's not so good. We were trying to avoid statics where
> > > > possible.
> > > > > > I'd prefer to keep that Map in FOUserAgent (per rendering run), or
> > if
> > > > > > you want to cache the profiles, we should make a cache class with
> > > > > > SoftReferences similar to what is implemented in ImageFactory and
> > > > attach
> > > > > > that to the FopFactory. But I can look into this. I don't want to
> > put
> > > > > > too much on your shoulders if you don't want to. It's cool enough
> > that
> > > > > > you're putting so much energy into this.
> > > > >
> > > > > Basically the same issue here. ColorUtil is static....and as a
> > (lousy)
> > > > > excuse, I mainly just duplicated the colorMap cache "idea"....but I
> > > > agree
> > > > > one should avoid those static beasts. Not caching the ColorProfiles
> > on
> > > > the
> > > > > other hand seems not a good idea either, from a memory consumption
> > > > > perspective.
> > > > >
> > > > > Again (sorry for repeating myself) I would rather see this included
> > and
> > > > > continue from there...building up fop-dev experience step by step.
> > > >
> > > >
> > > >
> > > > Jeremias Maerki
> >
> >
> >
> > Jeremias Maerki
Jeremias Maerki
RE: Including an sRGB color profile?
Posted by Peter <pc...@gmail.com>.
So I think I have it working but not without substantial changes
A summary
1)FopFactory
============
*) Added a synchronized Map, colorSpaceMap to cache ...ColorSpace
objects(life can be easy). Don't know whether this has to be synchronized.
Have not looked into the details of FOP MT features.
*) Added a public method
public ColorSpace getColorSpace(
String base,
String iccProfileSrc)
Kind of awkward to have to pass in the base but the only way I could see to
work around that is to have the cache in the user agent iso the factory
2) AreaTreeParser.Handler#setTraits
===================================
*) Change invocation of ColorUtil.parseColorString (2x). It now needs a
first FOUserAgent argument
*) Change invocation of BorderProps.valueOf. Expects a first FOUserAgent
argument
3) NCNameProperty#getColor
==========================
*) New first FOUserAgent argument
*) Invoke ColorUtil.parseColorString with the FOUserAgent argument
4) NumericProperty#getColor
============================
*) New first FOUserAgent argument
5) PropertyParser#parsePrimaryExpr
==================================
*) ColorProperty constructor takes new first FOUserAgent argument
6) SystemColorFunction#eval
===========================
*) ColorProperty constructor takes new first FOUserAgent argument
7) ColorProperty
================
*) Constructor new first FOUserAgent argument
*) getColor - new first FOUserAgent argument
8) CommonBorderPaddingBackground
================================
*) getColor - new first FOUserAgent argument
8) NumberProperty
=================
*) getColor - new first FOUserAgent argument
9) Property
===========
*) getColor - new first FOUserAgent argument
10) ColorUtil has been changed to take "advantage" of these changes
I have not added a lot of tests to check the arguments which are accessed to
get hold of the FOUserAgent and the unit tests gave one NPE because one of
the arguments to one of the functions was null. I am trying to decide
whether more defensive checks for null arguments would make sense.
Anyone any thoughts?
Thanks,
Peter
> -----Original Message-----
> From: Jeremias Maerki [mailto:dev@jeremias-maerki.ch]
> Sent: Wednesday, October 11, 2006 2:29 PM
> To: fop-dev@xmlgraphics.apache.org
> Subject: Re: Including an sRGB color profile?
>
> ColorUtil, as the name implies, is a utility class and it doesn't feel
> right to put an instance of it in FOUserAgent. I would extract the
> profile caching into a separate class and put that there (or rather in
> the FopFactory so multiple rendering runs can use the cache). The
> ColorUtil methods should then usually receive an instance of the profile
> cache to work with.
>
> You will easily see from the unit tests if anything breaks. I will also
> do extensive tests when reviewing your patch. Since it probably needs
> some additional work afterwards, we will probably put it in a branch
> until it's ready to be merged back into Trunk. Don't be too afraid to
> change some method signatures. What needs to be done, needs to be done.
>
> On 11.10.2006 14:07:51 Peter wrote:
> > Some more information....found during the last few hours....and finished
> > typing in just before your reply came in.
> >
> > I have been trying to figure out whether it would help to add an
> instance of
> > ColorUtil to the FOUserAgent (and changing some of its methods and
> members
> > to instance level)
> >
> > Skipping to the conclusion first - in theory it seems possible to make
> > ColorUtil#parseColorString an instance method and add a ColorUtil
> instance
> > to the FOUserAgent. In theory, because API wise an FOUserAgent can
> always be
> > made available (given enough API changes) but I have no idea whether it
> will
> > actually be there at runtime (could be null).
> >
> > Actually there might a problem with one or more static function of one
> of
> > the calling classes/methods I just realize.
> >
> > Anyway, changes are rather extensive and I am not sure whether they will
> > work or break anything I overlooked.
> >
> > Please advice - I am willing to give it a try but need to decide asap (I
> am
> > running out of my time slot that was made available for fop dev work for
> the
> > coming weeks).
> >
> > Thanks,
> >
> > Peter
> >
> >
> > What I found out, ColorUtil is referenced from
> >
> > 1/ colorEqualTest
> > ==> Not an issue I guess (test)
> >
> > 2/ AreaTreeParser.Handler#setTraits
> > ==> Not an issue as an FOUserAgent is available
> >
> > 3/ Trait.Background#toString ==> FOUserAgent not needed
> > ==> Not an issue as an FOUserAgent is not needed (only colorToString is
> > called)
> >
> > 4/ NCNameProperty#getColor
> > ==> NO FOUserAgent ==> ISSUE
> >
> > 5/ ColorProperty#ColorProperty
> > ==> NO FOUserAgent ==> ISSUE
> >
> > 6/ ColorProperty#toString ==> FOUserAgent not needed
> > ==> Not an issue as an FOUserAgent is not needed (only colorToString is
> > called)
> >
> > 7/ XMLRenderer#addTraitAttributes ==> FOUserAgent not needed
> > ==> Not an issue as an FOUserAgent is not needed (only colorToString is
> > called)
> >
> > 8/ BorderProps#toString ==> FOUserAgent not needed
> > ==> Not an issue as an FOUserAgent is not needed (only colorToString is
> > called)
> >
> > 9/ BorderProps#valueOf
> > ==> NO FOUserAgent ==> ISSUE
> >
> > To summarize three invocations of ColorUtil#parseColorString give
> problems
> >
> > I went a level further
> >
> > 4/ NCNameProperty#getColor
> > ==> NO FOUserAgent ==> But all callers of getColor seem to have access
> to
> > something that in theory should be able to return the FOUserAgent
> > ==> No longer an issue
> >
> >
> > 5/ ColorProperty#ColorProperty
> > ==> NO FOUserAgent ==> But all callers of ColorProperty constructor seem
> to
> > have access to something that in theory should be able to return the
> > FOUserAgent ==> No longer an issue
> >
> > 9/ BorderProps#valueOf
> > ==> NO FOUserAgent ==> ==> But all callers of valueOf (one :)) seem to
> have
> > access to something that in theory should be able to return the
> FOUserAgent
> > ==> No longer an issue
> >
> >
> >
> >
> > > -----Original Message-----
> > > From: Jeremias Maerki [mailto:dev@jeremias-maerki.ch]
> > > Sent: Wednesday, October 11, 2006 2:05 PM
> > > To: fop-dev@xmlgraphics.apache.org
> > > Subject: Re: Including an sRGB color profile?
> > >
> > > Ok for me, as long as we track the outstanding issues.
> > >
> > > On 11.10.2006 12:01:19 Peter wrote:
> > > > >
> > > > > Would you please try to run URI resolution through
> > > > > FOUserAgent.resolveURI()? That way we'll have a uniform URI
> resolution
> > > > > everywhere.
> > > >
> > > > I understand your concern. I will look into it but the issue is that
> > > > ColorUtil is really a bunch of static methods that at this stage
> have no
> > > > access to any instance objects. I am sure that can be changed but I
> am
> > > > concerned this is going to ripple down to a lot of files and I would
> > > rather
> > > > start out by leaving as much code as possible untouched.
> > > >
> > > >
> > > > > Uhm, that's not so good. We were trying to avoid statics where
> > > possible.
> > > > > I'd prefer to keep that Map in FOUserAgent (per rendering run), or
> if
> > > > > you want to cache the profiles, we should make a cache class with
> > > > > SoftReferences similar to what is implemented in ImageFactory and
> > > attach
> > > > > that to the FopFactory. But I can look into this. I don't want to
> put
> > > > > too much on your shoulders if you don't want to. It's cool enough
> that
> > > > > you're putting so much energy into this.
> > > >
> > > > Basically the same issue here. ColorUtil is static....and as a
> (lousy)
> > > > excuse, I mainly just duplicated the colorMap cache "idea"....but I
> > > agree
> > > > one should avoid those static beasts. Not caching the ColorProfiles
> on
> > > the
> > > > other hand seems not a good idea either, from a memory consumption
> > > > perspective.
> > > >
> > > > Again (sorry for repeating myself) I would rather see this included
> and
> > > > continue from there...building up fop-dev experience step by step.
> > >
> > >
> > >
> > > Jeremias Maerki
>
>
>
> Jeremias Maerki
Re: Including an sRGB color profile?
Posted by Jeremias Maerki <de...@jeremias-maerki.ch>.
ColorUtil, as the name implies, is a utility class and it doesn't feel
right to put an instance of it in FOUserAgent. I would extract the
profile caching into a separate class and put that there (or rather in
the FopFactory so multiple rendering runs can use the cache). The
ColorUtil methods should then usually receive an instance of the profile
cache to work with.
You will easily see from the unit tests if anything breaks. I will also
do extensive tests when reviewing your patch. Since it probably needs
some additional work afterwards, we will probably put it in a branch
until it's ready to be merged back into Trunk. Don't be too afraid to
change some method signatures. What needs to be done, needs to be done.
On 11.10.2006 14:07:51 Peter wrote:
> Some more information....found during the last few hours....and finished
> typing in just before your reply came in.
>
> I have been trying to figure out whether it would help to add an instance of
> ColorUtil to the FOUserAgent (and changing some of its methods and members
> to instance level)
>
> Skipping to the conclusion first - in theory it seems possible to make
> ColorUtil#parseColorString an instance method and add a ColorUtil instance
> to the FOUserAgent. In theory, because API wise an FOUserAgent can always be
> made available (given enough API changes) but I have no idea whether it will
> actually be there at runtime (could be null).
>
> Actually there might a problem with one or more static function of one of
> the calling classes/methods I just realize.
>
> Anyway, changes are rather extensive and I am not sure whether they will
> work or break anything I overlooked.
>
> Please advice - I am willing to give it a try but need to decide asap (I am
> running out of my time slot that was made available for fop dev work for the
> coming weeks).
>
> Thanks,
>
> Peter
>
>
> What I found out, ColorUtil is referenced from
>
> 1/ colorEqualTest
> ==> Not an issue I guess (test)
>
> 2/ AreaTreeParser.Handler#setTraits
> ==> Not an issue as an FOUserAgent is available
>
> 3/ Trait.Background#toString ==> FOUserAgent not needed
> ==> Not an issue as an FOUserAgent is not needed (only colorToString is
> called)
>
> 4/ NCNameProperty#getColor
> ==> NO FOUserAgent ==> ISSUE
>
> 5/ ColorProperty#ColorProperty
> ==> NO FOUserAgent ==> ISSUE
>
> 6/ ColorProperty#toString ==> FOUserAgent not needed
> ==> Not an issue as an FOUserAgent is not needed (only colorToString is
> called)
>
> 7/ XMLRenderer#addTraitAttributes ==> FOUserAgent not needed
> ==> Not an issue as an FOUserAgent is not needed (only colorToString is
> called)
>
> 8/ BorderProps#toString ==> FOUserAgent not needed
> ==> Not an issue as an FOUserAgent is not needed (only colorToString is
> called)
>
> 9/ BorderProps#valueOf
> ==> NO FOUserAgent ==> ISSUE
>
> To summarize three invocations of ColorUtil#parseColorString give problems
>
> I went a level further
>
> 4/ NCNameProperty#getColor
> ==> NO FOUserAgent ==> But all callers of getColor seem to have access to
> something that in theory should be able to return the FOUserAgent
> ==> No longer an issue
>
>
> 5/ ColorProperty#ColorProperty
> ==> NO FOUserAgent ==> But all callers of ColorProperty constructor seem to
> have access to something that in theory should be able to return the
> FOUserAgent ==> No longer an issue
>
> 9/ BorderProps#valueOf
> ==> NO FOUserAgent ==> ==> But all callers of valueOf (one :)) seem to have
> access to something that in theory should be able to return the FOUserAgent
> ==> No longer an issue
>
>
>
>
> > -----Original Message-----
> > From: Jeremias Maerki [mailto:dev@jeremias-maerki.ch]
> > Sent: Wednesday, October 11, 2006 2:05 PM
> > To: fop-dev@xmlgraphics.apache.org
> > Subject: Re: Including an sRGB color profile?
> >
> > Ok for me, as long as we track the outstanding issues.
> >
> > On 11.10.2006 12:01:19 Peter wrote:
> > > >
> > > > Would you please try to run URI resolution through
> > > > FOUserAgent.resolveURI()? That way we'll have a uniform URI resolution
> > > > everywhere.
> > >
> > > I understand your concern. I will look into it but the issue is that
> > > ColorUtil is really a bunch of static methods that at this stage have no
> > > access to any instance objects. I am sure that can be changed but I am
> > > concerned this is going to ripple down to a lot of files and I would
> > rather
> > > start out by leaving as much code as possible untouched.
> > >
> > >
> > > > Uhm, that's not so good. We were trying to avoid statics where
> > possible.
> > > > I'd prefer to keep that Map in FOUserAgent (per rendering run), or if
> > > > you want to cache the profiles, we should make a cache class with
> > > > SoftReferences similar to what is implemented in ImageFactory and
> > attach
> > > > that to the FopFactory. But I can look into this. I don't want to put
> > > > too much on your shoulders if you don't want to. It's cool enough that
> > > > you're putting so much energy into this.
> > >
> > > Basically the same issue here. ColorUtil is static....and as a (lousy)
> > > excuse, I mainly just duplicated the colorMap cache "idea"....but I
> > agree
> > > one should avoid those static beasts. Not caching the ColorProfiles on
> > the
> > > other hand seems not a good idea either, from a memory consumption
> > > perspective.
> > >
> > > Again (sorry for repeating myself) I would rather see this included and
> > > continue from there...building up fop-dev experience step by step.
> >
> >
> >
> > Jeremias Maerki
Jeremias Maerki
RE: Including an sRGB color profile?
Posted by Peter <pc...@gmail.com>.
Some more information....found during the last few hours....and finished
typing in just before your reply came in.
I have been trying to figure out whether it would help to add an instance of
ColorUtil to the FOUserAgent (and changing some of its methods and members
to instance level)
Skipping to the conclusion first - in theory it seems possible to make
ColorUtil#parseColorString an instance method and add a ColorUtil instance
to the FOUserAgent. In theory, because API wise an FOUserAgent can always be
made available (given enough API changes) but I have no idea whether it will
actually be there at runtime (could be null).
Actually there might a problem with one or more static function of one of
the calling classes/methods I just realize.
Anyway, changes are rather extensive and I am not sure whether they will
work or break anything I overlooked.
Please advice - I am willing to give it a try but need to decide asap (I am
running out of my time slot that was made available for fop dev work for the
coming weeks).
Thanks,
Peter
What I found out, ColorUtil is referenced from
1/ colorEqualTest
==> Not an issue I guess (test)
2/ AreaTreeParser.Handler#setTraits
==> Not an issue as an FOUserAgent is available
3/ Trait.Background#toString ==> FOUserAgent not needed
==> Not an issue as an FOUserAgent is not needed (only colorToString is
called)
4/ NCNameProperty#getColor
==> NO FOUserAgent ==> ISSUE
5/ ColorProperty#ColorProperty
==> NO FOUserAgent ==> ISSUE
6/ ColorProperty#toString ==> FOUserAgent not needed
==> Not an issue as an FOUserAgent is not needed (only colorToString is
called)
7/ XMLRenderer#addTraitAttributes ==> FOUserAgent not needed
==> Not an issue as an FOUserAgent is not needed (only colorToString is
called)
8/ BorderProps#toString ==> FOUserAgent not needed
==> Not an issue as an FOUserAgent is not needed (only colorToString is
called)
9/ BorderProps#valueOf
==> NO FOUserAgent ==> ISSUE
To summarize three invocations of ColorUtil#parseColorString give problems
I went a level further
4/ NCNameProperty#getColor
==> NO FOUserAgent ==> But all callers of getColor seem to have access to
something that in theory should be able to return the FOUserAgent
==> No longer an issue
5/ ColorProperty#ColorProperty
==> NO FOUserAgent ==> But all callers of ColorProperty constructor seem to
have access to something that in theory should be able to return the
FOUserAgent ==> No longer an issue
9/ BorderProps#valueOf
==> NO FOUserAgent ==> ==> But all callers of valueOf (one :)) seem to have
access to something that in theory should be able to return the FOUserAgent
==> No longer an issue
> -----Original Message-----
> From: Jeremias Maerki [mailto:dev@jeremias-maerki.ch]
> Sent: Wednesday, October 11, 2006 2:05 PM
> To: fop-dev@xmlgraphics.apache.org
> Subject: Re: Including an sRGB color profile?
>
> Ok for me, as long as we track the outstanding issues.
>
> On 11.10.2006 12:01:19 Peter wrote:
> > >
> > > Would you please try to run URI resolution through
> > > FOUserAgent.resolveURI()? That way we'll have a uniform URI resolution
> > > everywhere.
> >
> > I understand your concern. I will look into it but the issue is that
> > ColorUtil is really a bunch of static methods that at this stage have no
> > access to any instance objects. I am sure that can be changed but I am
> > concerned this is going to ripple down to a lot of files and I would
> rather
> > start out by leaving as much code as possible untouched.
> >
> >
> > > Uhm, that's not so good. We were trying to avoid statics where
> possible.
> > > I'd prefer to keep that Map in FOUserAgent (per rendering run), or if
> > > you want to cache the profiles, we should make a cache class with
> > > SoftReferences similar to what is implemented in ImageFactory and
> attach
> > > that to the FopFactory. But I can look into this. I don't want to put
> > > too much on your shoulders if you don't want to. It's cool enough that
> > > you're putting so much energy into this.
> >
> > Basically the same issue here. ColorUtil is static....and as a (lousy)
> > excuse, I mainly just duplicated the colorMap cache "idea"....but I
> agree
> > one should avoid those static beasts. Not caching the ColorProfiles on
> the
> > other hand seems not a good idea either, from a memory consumption
> > perspective.
> >
> > Again (sorry for repeating myself) I would rather see this included and
> > continue from there...building up fop-dev experience step by step.
>
>
>
> Jeremias Maerki
Re: Including an sRGB color profile?
Posted by Jeremias Maerki <de...@jeremias-maerki.ch>.
Ok for me, as long as we track the outstanding issues.
On 11.10.2006 12:01:19 Peter wrote:
> >
> > Would you please try to run URI resolution through
> > FOUserAgent.resolveURI()? That way we'll have a uniform URI resolution
> > everywhere.
>
> I understand your concern. I will look into it but the issue is that
> ColorUtil is really a bunch of static methods that at this stage have no
> access to any instance objects. I am sure that can be changed but I am
> concerned this is going to ripple down to a lot of files and I would rather
> start out by leaving as much code as possible untouched.
>
>
> > Uhm, that's not so good. We were trying to avoid statics where possible.
> > I'd prefer to keep that Map in FOUserAgent (per rendering run), or if
> > you want to cache the profiles, we should make a cache class with
> > SoftReferences similar to what is implemented in ImageFactory and attach
> > that to the FopFactory. But I can look into this. I don't want to put
> > too much on your shoulders if you don't want to. It's cool enough that
> > you're putting so much energy into this.
>
> Basically the same issue here. ColorUtil is static....and as a (lousy)
> excuse, I mainly just duplicated the colorMap cache "idea"....but I agree
> one should avoid those static beasts. Not caching the ColorProfiles on the
> other hand seems not a good idea either, from a memory consumption
> perspective.
>
> Again (sorry for repeating myself) I would rather see this included and
> continue from there...building up fop-dev experience step by step.
Jeremias Maerki
RE: Including an sRGB color profile?
Posted by Peter <pc...@gmail.com>.
>
> Would you please try to run URI resolution through
> FOUserAgent.resolveURI()? That way we'll have a uniform URI resolution
> everywhere.
I understand your concern. I will look into it but the issue is that
ColorUtil is really a bunch of static methods that at this stage have no
access to any instance objects. I am sure that can be changed but I am
concerned this is going to ripple down to a lot of files and I would rather
start out by leaving as much code as possible untouched.
> Uhm, that's not so good. We were trying to avoid statics where possible.
> I'd prefer to keep that Map in FOUserAgent (per rendering run), or if
> you want to cache the profiles, we should make a cache class with
> SoftReferences similar to what is implemented in ImageFactory and attach
> that to the FopFactory. But I can look into this. I don't want to put
> too much on your shoulders if you don't want to. It's cool enough that
> you're putting so much energy into this.
Basically the same issue here. ColorUtil is static....and as a (lousy)
excuse, I mainly just duplicated the colorMap cache "idea"....but I agree
one should avoid those static beasts. Not caching the ColorProfiles on the
other hand seems not a good idea either, from a memory consumption
perspective.
Again (sorry for repeating myself) I would rather see this included and
continue from there...building up fop-dev experience step by step.
RE: Including an sRGB color profile?
Posted by Peter <pc...@gmail.com>.
>
> Would you please try to run URI resolution through
> FOUserAgent.resolveURI()? That way we'll have a uniform URI resolution
> everywhere.
>
I am trying, but have a question - does that mean a new base uri config
setting has to be introduced, equivalent to e.g. the fontBaseURL ?
Re: Including an sRGB color profile?
Posted by Jeremias Maerki <de...@jeremias-maerki.ch>.
On 10.10.2006 21:31:49 Peter Coppens wrote:
>
> 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 :))
It's not that difficult. :-)
> 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.
Would you please try to run URI resolution through
FOUserAgent.resolveURI()? That way we'll have a uniform URI resolution
everywhere.
> 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
Clever.
> 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)
I like your idea. Quite creative!
>
> 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.
Uhm, that's not so good. We were trying to avoid statics where possible.
I'd prefer to keep that Map in FOUserAgent (per rendering run), or if
you want to cache the profiles, we should make a cache class with
SoftReferences similar to what is implemented in ImageFactory and attach
that to the FopFactory. But I can look into this. I don't want to put
too much on your shoulders if you don't want to. It's cool enough that
you're putting so much energy into this.
> 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?
Please do so. This stuff is only used internally so we don't have to
worry about backwards-compatibility.
>
>
> 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.
I think that approach is ok. The color space handling in the PDF library
is indeed a little strange. It was mostly because of inability of the
Java classlib to map some of the cases (like DeviceCMYK).
> 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
I'm impressed! Looks like I had the right feeling about you. Thank you
very much for your detailed information. It helps a lot to understand
what you're doing and I think it is going exactly in the right direction.
Sorry that I can't help more but it looks like you have everything under
control.
<snip/>
Jeremias Maerki
Re: Including an sRGB color profile?
Posted by Peter Coppens <pc...@gmail.com>.
>I don't think this will go without changing some method signatures.
>Given that not in every context (see AreaTreeParser example above) you
>have the FO tree available. So it may make sense to define a
>ColorContext interface which allows access to the available color
>profiles for the document. There would be an implementation for the FO
>tree context and one for the AreaTreeParser context, maybe some
>additional implementation if necessary. But I can see that there will
>need to be some extensive changes. I currently don't see a way around
>that. But maybe someone else does.
>
Trying to trim down the amount of code I will have to touch (this is my
first attempt to contribute to an open source project and I'd rather start
as small as possible)
Perhaps the following could work?
(*) I add a second rgb-icc function, rgb-icc-internal or whatever that does
not take an NCNAME for its colorprofile parameter, but the src of the
matching element from the declarations element.
(*) The user specifies rgb-icc (of course) which will always, I hope, be
parsed through a call to PropertyParser@parsePrimaryExpr -> ? ->
ColorUtil#parseColorString. The result of this is a class derived from
java.awt.Color which registers rgb replacement values, icc values, color
profile ncname and also the color profile src (setting the src happens in
the new ICCColorFunction#eval method which has access to the fo tree)
(*) If later ColorUtil#colorTOsRGBString is called, the ColorUtil returns an
rgb-icc-internal iso rgb-icc call where relevant (I guess the name should be
changed)
(*) Obviously parsing of rgb-icc-internal will also be added, but at this
stage the map is no longer needed.
Thoughts on (1) this could work (2) you guys would buy into this rather
awkward approach?
Thanks,
Peter
--
View this message in context: http://www.nabble.com/Including-an-sRGB-color-profile--tf1373500.html#a6716163
Sent from the FOP - Dev mailing list archive at Nabble.com.
Re: Including an sRGB color profile?
Posted by Jeremias Maerki <de...@jeremias-maerki.ch>.
On 09.10.2006 11:49:13 Peter Coppens wrote:
>
> >> 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>
> >> )
>
> >Hmm, yes, I guess that will also have to be implemented. Take a look at
> >org.apache.fop.fo.pagination.ColorProfile. Something is already there
> >but with TODO flags. The color profiles will be stored in the
> >Declarations object. You will then have to extend
> >org.apache.fop.fo.pagination.Declarations with methods for accessing
> >individual ColorProfiles. The Declarations object is accessible through
> >the Root object.
>
> I am struggling with the fact that the Color object is created in the
> ColorUtil#parseColorString method which does not have access to the FO tree
> (I think).
Indeed, ColorUtil.parseColorString() is used in various places in
various contexts. For this to work as needed, every such call has to
have some context information about the ICC profiles available. For
example, the AreaTreeParser should equally be able to build up the color
instances again from the serialized area tree. There, no FO tree is
available. With the switch to use java.awt.Color you have to specify the
color space when instantiating the color.
> I see two approaches. Either the signature of parseColorString has to change
> to take an extra argument that gives access to the tree or creating the
> java.awt.Color derived class has to be postponed. Perhaps there are other
> solutions as well.
>
> At first sight I would think extending parseColorString makes the most
> sense, but I am not sure all callers of parseColorString have access to the
> tree and I'd rather not see function signature changes ripple up/down
> further.
I don't think this will go without changing some method signatures.
Given that not in every context (see AreaTreeParser example above) you
have the FO tree available. So it may make sense to define a
ColorContext interface which allows access to the available color
profiles for the document. There would be an implementation for the FO
tree context and one for the AreaTreeParser context, maybe some
additional implementation if necessary. But I can see that there will
need to be some extensive changes. I currently don't see a way around
that. But maybe someone else does.
> Any thoughts?
>
> Thanks!
>
> Peter
>
> PS Apologies for the 101 nature of my questions - not sure they are actually
> suited for this list.
No, that's absolutely ok. I prefer having close contact with
contributors because it minimizes the risk of late surprises for both
sides.
Jeremias Maerki
Re: Including an sRGB color profile?
Posted by Peter Coppens <pc...@gmail.com>.
>> 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>
>> )
>Hmm, yes, I guess that will also have to be implemented. Take a look at
>org.apache.fop.fo.pagination.ColorProfile. Something is already there
>but with TODO flags. The color profiles will be stored in the
>Declarations object. You will then have to extend
>org.apache.fop.fo.pagination.Declarations with methods for accessing
>individual ColorProfiles. The Declarations object is accessible through
>the Root object.
I am struggling with the fact that the Color object is created in the
ColorUtil#parseColorString method which does not have access to the FO tree
(I think).
I see two approaches. Either the signature of parseColorString has to change
to take an extra argument that gives access to the tree or creating the
java.awt.Color derived class has to be postponed. Perhaps there are other
solutions as well.
At first sight I would think extending parseColorString makes the most
sense, but I am not sure all callers of parseColorString have access to the
tree and I'd rather not see function signature changes ripple up/down
further.
Any thoughts?
Thanks!
Peter
PS Apologies for the 101 nature of my questions - not sure they are actually
suited for this list.
--
View this message in context: http://www.nabble.com/Including-an-sRGB-color-profile--tf1373500.html#a6714607
Sent from the FOP - Dev mailing list archive at Nabble.com.
Re: Including an sRGB color profile?
Posted by Jeremias Maerki <de...@jeremias-maerki.ch>.
Sorry for the delay, Peter.
On 05.10.2006 13:40:33 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
Cool
> 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>
> )
Hmm, yes, I guess that will also have to be implemented. Take a look at
org.apache.fop.fo.pagination.ColorProfile. Something is already there
but with TODO flags. The color profiles will be stored in the
Declarations object. You will then have to extend
org.apache.fop.fo.pagination.Declarations with methods for accessing
individual ColorProfiles. The Declarations object is accessible through
the Root object.
>
> 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
You can probably get to the Root object through the PropertyInfo
object: pInfo.getFO().getRoot().
> Any guidances would be appreciated.
<snip/>
Jeremias Maerki
Re: Including an sRGB color profile?
Posted by Jeremias Maerki <de...@jeremias-maerki.ch>.
Ah, ok. In your message you talked about "unequality" which is not the
same as "identity". The first test (!=) test for identity. This can be
removed. The second tests for equality (equals()).
On 11.10.2006 11:42:56 Peter wrote:
> The test fails on
>
> assertTrue(col1 != col2);
>
> Before the change I made that was ok as the Color object was cloned just
> before being returned
>
> The code in ColorUtil was
>
> // TODO: Check if this is really necessary
> return new Color(parsedColor.getRed(), parsedColor.getGreen(),
> parsedColor.getBlue(), parsedColor.getAlpha());
>
> As a side remark, actually kind of weird to cache the Color objects in the
> static colorMap member and then cloning them anyway.
>
> I removed that clone, because now e.g. an RgbIccColor or CMYK based color
> can be returned. Therefore the Color objects can be the same (cached)
> objects and the assert fires in the test.
>
> I can of course make sure that all returned objects, including RgbIccColor
> and CMYK based Color objects are unique but I honestly think that in that
> case it also makes sense to remove the static colorMap cache.
>
>
> > -----Original Message-----
> > From: Jeremias Maerki [mailto:dev@jeremias-maerki.ch]
> > Sent: Wednesday, October 11, 2006 11:33 AM
> > To: fop-dev@xmlgraphics.apache.org
> > Subject: Re: Including an sRGB color profile?
> >
> > I think the test is fine. Can you tell why the two Color instances
> > cannot be compared anymore? Do you have to override the equals() method
> > of your Color subclasses?
> >
> > On 11.10.2006 11:22:13 Peter wrote:
> > > 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?
> >
> > <snip/>
> >
> >
> > Jeremias Maerki
Jeremias Maerki
RE: Including an sRGB color profile?
Posted by Peter <pc...@gmail.com>.
The test fails on
assertTrue(col1 != col2);
Before the change I made that was ok as the Color object was cloned just
before being returned
The code in ColorUtil was
// TODO: Check if this is really necessary
return new Color(parsedColor.getRed(), parsedColor.getGreen(),
parsedColor.getBlue(), parsedColor.getAlpha());
As a side remark, actually kind of weird to cache the Color objects in the
static colorMap member and then cloning them anyway.
I removed that clone, because now e.g. an RgbIccColor or CMYK based color
can be returned. Therefore the Color objects can be the same (cached)
objects and the assert fires in the test.
I can of course make sure that all returned objects, including RgbIccColor
and CMYK based Color objects are unique but I honestly think that in that
case it also makes sense to remove the static colorMap cache.
> -----Original Message-----
> From: Jeremias Maerki [mailto:dev@jeremias-maerki.ch]
> Sent: Wednesday, October 11, 2006 11:33 AM
> To: fop-dev@xmlgraphics.apache.org
> Subject: Re: Including an sRGB color profile?
>
> I think the test is fine. Can you tell why the two Color instances
> cannot be compared anymore? Do you have to override the equals() method
> of your Color subclasses?
>
> On 11.10.2006 11:22:13 Peter wrote:
> > 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?
>
> <snip/>
>
>
> Jeremias Maerki
Re: Including an sRGB color profile?
Posted by Jeremias Maerki <de...@jeremias-maerki.ch>.
I think the test is fine. Can you tell why the two Color instances
cannot be compared anymore? Do you have to override the equals() method
of your Color subclasses?
On 11.10.2006 11:22:13 Peter wrote:
> 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?
<snip/>
Jeremias Maerki
RE: Including an sRGB color profile?
Posted by Peter <pc...@gmail.com>.
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:pc.subscriptions@gmail.com]
> 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.
Re: Including an sRGB color profile?
Posted by Peter Coppens <pc...@gmail.com>.
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.
Re: Including an sRGB color profile?
Posted by Jeremias Maerki <de...@jeremias-maerki.ch>.
Hey, we're all constantly learning here and I didn't find anything
confusing or unclear in your questions. From what I can read between the
lines you're well on your way in the right direction. However, I must
excuse myself until Wednesday before I can continue to help you since
it's already very late here and I'm not available tomorrow. Maybe
someone else might jump in and help in the meantime.
On 09.10.2006 23:35:08 Peter Coppens wrote:
>
> On second thought, having the conversion based on the profile might be the
> right thing to do after all. Either the renderer knows how to deal with
> color profiles and will do the necessary, or it does not in which case it
> will ask the color for its rgb values. The profile based converted values
> might be the best bet then.
>
> Also the xsl spec says the replacement values are used when the color
> profile is not available (not when the renderer does not know how to deal
> with it). When the profile can not be loaded, an rgb Color based on the
> replacement values can be created and returned.
>
> Leaves the CMYK case....not sure what to do there. I guess converting
> device/default cmyk to (device/default?) rgb is also easy so in that case
> replacement values are not needed either. That would mean that the
> cmyk(c,m,y,k) approach could work just as well as the perhaps more awkward
> rgb-icc(r,g,b,#CMYK,c,m,y,k) hack. It does seem necessary to create a CMYK
> color space class though (or complete the one in org.apache.fop.util).
>
> Apologies for all the confusion and unclear questions...this is (obviously)
> all very new for me and I am far from confident I grasp all the details or
> consequences of possible decisions made
>
>
> Jeremias Maerki-2 wrote:
> >
> > Uh yeah, right. I didn't think about that. No way around subclassing
> > Color then.
> >
> > On 09.10.2006 09:54:31 Peter Coppens wrote:
> >>
> >>
> >> >Do you really have to extend the Color class? I think it already
> >> >provides methods to access the fallback sRGB value which is actually
> >> >what the FO spec wants (getRed(), getGreen(), getBlue()).
> >>
> >> Not sure....all pretty new for me, but would the get<RGB>() functions not
> >> return the profile based converted values rather than the ones the user
> >> specified as first arguments to the rgb-icc function?
> >
> >
> > Jeremias Maerki
Jeremias Maerki
Re: Including an sRGB color profile?
Posted by Peter Coppens <pc...@gmail.com>.
On second thought, having the conversion based on the profile might be the
right thing to do after all. Either the renderer knows how to deal with
color profiles and will do the necessary, or it does not in which case it
will ask the color for its rgb values. The profile based converted values
might be the best bet then.
Also the xsl spec says the replacement values are used when the color
profile is not available (not when the renderer does not know how to deal
with it). When the profile can not be loaded, an rgb Color based on the
replacement values can be created and returned.
Leaves the CMYK case....not sure what to do there. I guess converting
device/default cmyk to (device/default?) rgb is also easy so in that case
replacement values are not needed either. That would mean that the
cmyk(c,m,y,k) approach could work just as well as the perhaps more awkward
rgb-icc(r,g,b,#CMYK,c,m,y,k) hack. It does seem necessary to create a CMYK
color space class though (or complete the one in org.apache.fop.util).
Apologies for all the confusion and unclear questions...this is (obviously)
all very new for me and I am far from confident I grasp all the details or
consequences of possible decisions made
Jeremias Maerki-2 wrote:
>
> Uh yeah, right. I didn't think about that. No way around subclassing
> Color then.
>
> On 09.10.2006 09:54:31 Peter Coppens wrote:
>>
>>
>> >Do you really have to extend the Color class? I think it already
>> >provides methods to access the fallback sRGB value which is actually
>> >what the FO spec wants (getRed(), getGreen(), getBlue()).
>>
>> Not sure....all pretty new for me, but would the get<RGB>() functions not
>> return the profile based converted values rather than the ones the user
>> specified as first arguments to the rgb-icc function?
>
>
> Jeremias Maerki
>
>
>
--
View this message in context: http://www.nabble.com/Including-an-sRGB-color-profile--tf1373500.html#a6726105
Sent from the FOP - Dev mailing list archive at Nabble.com.
Re: Including an sRGB color profile?
Posted by Jeremias Maerki <de...@jeremias-maerki.ch>.
Uh yeah, right. I didn't think about that. No way around subclassing
Color then.
On 09.10.2006 09:54:31 Peter Coppens wrote:
>
>
> >Do you really have to extend the Color class? I think it already
> >provides methods to access the fallback sRGB value which is actually
> >what the FO spec wants (getRed(), getGreen(), getBlue()).
>
> Not sure....all pretty new for me, but would the get<RGB>() functions not
> return the profile based converted values rather than the ones the user
> specified as first arguments to the rgb-icc function?
Jeremias Maerki
Re: Including an sRGB color profile?
Posted by Peter Coppens <pc...@gmail.com>.
>Do you really have to extend the Color class? I think it already
>provides methods to access the fallback sRGB value which is actually
>what the FO spec wants (getRed(), getGreen(), getBlue()).
Not sure....all pretty new for me, but would the get<RGB>() functions not
return the profile based converted values rather than the ones the user
specified as first arguments to the rgb-icc function?
--
View this message in context: http://www.nabble.com/Including-an-sRGB-color-profile--tf1373500.html#a6713134
Sent from the FOP - Dev mailing list archive at Nabble.com.
Re: Including an sRGB color profile?
Posted by Jeremias Maerki <de...@jeremias-maerki.ch>.
On 06.10.2006 15:58:34 Peter Coppens wrote:
>
> 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.
Do you really have to extend the Color class? I think it already
provides methods to access the fallback sRGB value which is actually
what the FO spec wants (getRed(), getGreen(), getBlue()).
> 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).
Yes, I agree. I think that's the only point where you have to extend the
Color class to handle basic device-dependant CMYK. Or maybe it is
sufficient to implement a ColorSpace subclass. Actually, that's probably
the better approach though I don't know if it's easier. I still know too
little about all this color handling stuff to have a clear answer here.
> 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?
That's the easy part. :-) You just create a patch according to:
http://xmlgraphics.apache.org/fop/dev/index.html#patches
We will then review the patch and include it in the repository if
everything is ok.
One nit, though: In case you add new classes while developing this or if
you make extensive changes in some classes we will need an ICLA (and if
appropriate an CCLA) on file with the Apache Software Foundation. More
info here: http://www.apache.org/licenses/#clas
> 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.
Jeremias Maerki
Re: Including an sRGB color profile?
Posted by Peter Coppens <pc...@gmail.com>.
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.
Re: Including an sRGB color profile?
Posted by Peter Coppens <pc...@gmail.com>.
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.
Re: Including an sRGB color profile?
Posted by Peter Coppens <pc...@gmail.com>.
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#a6459632
Sent from the FOP - Dev mailing list archive at Nabble.com.
Re: Including an sRGB color profile?
Posted by Jeremias Maerki <de...@jeremias-maerki.ch>.
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
Re: Including an sRGB color profile?
Posted by Peter Coppens <pc...@gmail.com>.
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.
Re: Including an sRGB color profile?
Posted by Jeremias Maerki <de...@jeremias-maerki.ch>.
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
Re: Including an sRGB color profile?
Posted by Max Berger <ma...@berger.name>.
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1
Jeremias,
Fop-dev,
I know I have no vote in this, but I do disagree.
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.
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.
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
>
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.2 (MingW32)
Comment: Using GnuPG with Thunderbird - http://enigmail.mozdev.org
iD4DBQFELYebxVFyWbWycjQRApxpAJj4kFIHwFpEnbsoKcGeCOMjsfT7AJ99OHsD
0iDcqGbsIpj5oNN/GAUsXg==
=pX/E
-----END PGP SIGNATURE-----
Re: Including an sRGB color profile?
Posted by Clay Leeds <we...@mac.com>.
On Mar 31, 2006, at 1:09 AM, Jeremias Maerki wrote:
> Anyone against me including this color profile (3144 bytes,
> uncompressed)
> in the org.apache.fop.pdf package?
+1
Clay Leeds
webmaestro@mac.com
My religion is simple. My religion is kindness.
-- HH Dalai Lama of Tibet