RE: Including an sRGB color profile?

[Peter]

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 guessbut 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:[EMAIL PROTECTED]
> 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:[EMAIL PROTECTED]
> > > 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

Re: Including an sRGB color profile?

[Jeremias Maerki]

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:[EMAIL PROTECTED]
> > 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 informationfound during the last few hoursand 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) b

RE: Including an sRGB color profile?

[Peter]

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:[EMAIL PROTECTED]
> 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 informationfound during the last few hoursand 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
>

Re: Including an sRGB color profile?

[Jeremias Maerki]

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?

[Peter]

> 
> 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?

[Jeremias Maerki]

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 informationfound during the last few hoursand 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:[EMAIL PROTECTED]
> > 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.
> >

RE: Including an sRGB color profile?

[Peter]

Some more informationfound during the last few hoursand 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:[EMAIL PROTECTED]
> 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 staticand 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?

[Jeremias Maerki]

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 staticand 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?

[Jeremias Maerki]

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:[EMAIL PROTECTED]
> > 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?
> > 
> > 
> > 
> > 
> > Jeremias Maerki



Jeremias Maerki

RE: Including an sRGB color profile?

[Peter]

> 
> 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 staticand 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?

[Peter]

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:[EMAIL PROTECTED]
> 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?
> 
> 
> 
> 
> Jeremias Maerki

Re: Including an sRGB color profile?

[Jeremias Maerki]

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?




Jeremias Maerki

Re: Including an sRGB color profile?

[Jeremias Maerki]

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.CMYKCo

RE: Including an sRGB color profile?

[Peter]

I ran the unit tests and I am getting a failure in StandardTestSuite -
testEquals. 

The reason for the failure is a change in ColorUtil (see 4/ lower).

Would changing the test to no longer check for unequality between two
returned Color objects be an option?

Thanks,

Peter

> -Original Message-
> From: Peter Coppens [mailto:[EMAIL PROTECTED]
> Sent: Tuesday, October 10, 2006 9:32 PM
> To: fop-dev@xmlgraphics.apache.org
> Subject: Re: Including an sRGB color profile?
> 
> 
> I finished(?) working on the somewhat modified items (1), (2) and (4) of
> Jerememias' list.
> 
> I plan to clean up to code a bit and then try to submit a patch (there
> should be a first time for everything I guess :))
> 
> Here is an overview of what has been done - probably belongs in the patch
> as
> well, but if someone, despite the length of this post, decides to go
> through
> it anyway, an upfront red flag can be waved if needed, keeping me from
> going
> through the patch process.
> 
> 
> From the users point of view.
> 
> The rgb-icc function is accepted as input for color properties of fo
> elements and the generated PDF will include and refer to those color
> profiles. Other renderers will use profile based converted sRGB values.
> The
> ICC profiles are loaded using the src attribute from the color-profile
> element. The uri resolution relies on how the Java VM resolves color
> profiles.
> 
> A cmyk function accepting 4 arguments (values ranging from 0%-100% or
> 0.0-1.0) is also available. The PDF renderer will generate DeviceCMYK
> colors
> based on the provided values, the other renderers will use a "standard"
> cmyk-rgb conversion and generated rgb colors.
> 
> 
> Implementation wise the following changes were done
> 
> 
> org.apache.fop.fo.expr.PropertyParser
> 
> 1/
> FunctionTable has two new functions, cmyk and rgb-icc linked to two new
> classes CMYKcolorFunction and ICCcolorFunction
> 
> 2/
> parsePrimaryExpr recognizes functions that return a negative number from
> the
> nbArgs as variable argument functions. Those are parsed with a new method,
> parseVarArgs
> 
> org.apache.fop.fo.expr.CMYKColorFunction
> 
> New function class for the cmyk function
> 
> org.apache.fop.fo.expr.ICCColorFunction
> 
> New function class for the rgb-icc function. It is a somewhat peculiar
> function class for two reasons.
> 
> First, it returns an negative number for nbArgs (flagging a variable
> number
> of arguments function).
> 
> Second its eval method returns a string that contains a fop-rgb-icc
> function
> call. The arguments for this new function are the same as the one of rgb-
> icc
> with the exception of the fifth, which is an extra argument that contains
> the src attribute for the color profile (from
> /root/declarations/color-profile/@src)
> 
> An alternative suggested by Jeremias was to introduce a color context
> tracking the mapping between ICC profile name and src. Certainly a more
> elegant approach but it would require more classes to be touched something
> I
> was reluctant to do (this being my first attempt to a fop contribution)
> 
> 
> org.apache.fop.fo.pagination.Declarations
> 
> Added a new method
>   public ColorProfile getColorProfile(String cpName)
> 
> org.apache.fop.fo.pagination.ColorProfile
> 
> Added a new method
>   public String getSrc()
> 
> 
> org.apache.fop.util.ColorUtil
> 
> 1/
> Added a static member referring to a/the Log object
> 
> 2/
> Added a static (synchronized) Map, colorSpaceMap, mapping color profile
> src's to ICC_ColorSpace instances.
> 
> 3/
> parseColorString
> 
> Now also recognizes fop-rgb-icc and cmyk functions invoking
> parseAsFopRgbIcc
> or parseAsCMYK.
> 
> 4/
> Removed cloning of the Color object before returning from parseColorString
> (has a TODO in the current code)
> 
> 5/
> Added
>   private static Color parseAsFopRgbIcc(String value)
>   throws PropertyException
> 
> If the color profile src (5th argument) is not available in the
> colorSpaceMap cache, an attempt is made to create an ICC_Profile and
> associated ICC_ColorSpace based on the src.  If successful, the ColorSpace
> is added to the cache, if not the fallback rgb values are used to create
> an
> rgb based color. If an ICC_ColorSpace is available an RgbIccColor (new
> class) object is created.
> 
> 6/
> Added
>   private static Color parseAsCMYK(String value)
> throws PropertyException
> 
> Parses cmyk arguments and creates a Color from a CMYKColorSpace color
> space.
> 
> 
> 7/
> colorTOsRGBString
> 
> Changed to recogniz

Re: Including an sRGB color profile?

[Peter Coppens]

sn'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?

[Jeremias Maerki]

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 casenot 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 sureall pretty new for me, but would the get() 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?

[Peter Coppens]

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 casenot 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 sureall pretty new for me, but would the get() 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?

[Peter Coppens]

>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 [EMAIL PROTECTED] -> ? ->
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?

[Jeremias Maerki]

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 
> >> 
> >>  ?
> >> 
> >> )
> 
> >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?

[Peter Coppens]

>> What is not clear to me is how I can get hold of the color-profile
>> information (as in 
>> 
>>  ?
>> 
>> )

>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?

[Jeremias Maerki]

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 sureall pretty new for me, but would the get() 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?

[Peter Coppens]

>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 sureall pretty new for me, but would the get() 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?

[Jeremias Maerki]

t;>>> >> 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?

[Jeremias Maerki]

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 
> 
>  ?
> 
> )

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.




Jeremias Maerki

Re: Including an sRGB color profile?

[Peter Coppens]

gt; 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?

[Peter Coppens]

; 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?

[Peter Coppens]

 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?

[Jeremias Maerki]

eRGB 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?

[Peter Coppens]

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?

[Jeremias Maerki]

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?

[Max Berger]

-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?

[Clay Leeds]

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
[EMAIL PROTECTED]

My religion is simple. My religion is kindness.
-- HH Dalai Lama of Tibet

Including an sRGB color profile?

[Jeremias Maerki]

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