You are viewing a plain text version of this content. The canonical link for it is here.
Posted to general@xmlgraphics.apache.org by Jeremias Maerki <de...@jeremias-maerki.ch> on 2010/06/30 16:08:36 UTC
Status of the new color infrastructure
As a heads-up since Simon seems to be back to preparing the XGC release:
The new basic color infrastructure stands in the dev branch. And it
seems to cover everything necessary for XSL-FO. There are two tricky
things around this:
1. I don't really like getting the current ColorExt from Trunk into the
XGC release. The ColorExt in the color branch isn't compatible, but
is clearer and more flexible. Merging the color branch into Trunk now
(i.e. before the release) would avoid a backwards-incompatible change
later. Or I have to find a better name for the new ColorExt and then
deprecate the old ColorExt. The thing is: The FOP color branch is not
very well tested right now but could essentially be merged into Trunk at
least after some additional testing. We could also restore the ColorExt
from FOP and switch back to that in FOP. The only point where ColorExt
from XGC is used in XGC is ColorUtil.toCMYKGrayColor() which is used by
the GrayScaleColorConverter. That would require only a smaller change in
FOP to deal with the "other" ColorExt (the new one in XGC).
2. I'm not sure, yet, if the new color infrastructure will cover Batik's
requirements, too. That's my next step, after testing the output formats
other than PDF in the color branch (mainly AFP and PS).
Thoughts are most welcome.
Thanks,
Jeremias Maerki
---------------------------------------------------------------------
To unsubscribe, e-mail: general-unsubscribe@xmlgraphics.apache.org
For additional commands, e-mail: general-help@xmlgraphics.apache.org
Re: Status of the new color infrastructure
Posted by Jeremias Maerki <de...@jeremias-maerki.ch>.
No, this can't be addressed, since java.awt.Color only checks its sRGB
values, but not the actual color components if it's based on a non-sRGB
color space. And we can't change java.awt.Color. I've had to change FOP
in a few places in the color branch to test equals() in both directions
to detect color state changes. These collisions will not happen very
often but they are possible even in today's code. One thing that can be
done is to make sure FOP always uses a subclass of Color with a better
equals() method but that may not always work, for example, when barcodes,
PDF or WMF files are painted via Graphics2D.
I mentioned the equals() problem here:
http://wiki.apache.org/xmlgraphics/ColorHandling
On 01.07.2010 16:09:08 Peter Hancock wrote:
> I have noticed that the equals method of ColorExt is not reflexive, e.g.:
>
> Color c = ..
> ColorExt ce = ColorExt.createFromFoRgbIcc(.. ,c.getColorSpace(),
> c.getColorComponents(), ..)
>
> c.equals(ce) == true != ce.equals(c)
>
> Could this be addressed now?
>
> Pete
>
> On Thu, Jul 1, 2010 at 2:00 PM, Jeremias Maerki <de...@jeremias-maerki.ch> wrote:
> > OK, I see. As you can see, I feel the pretty much way but the current
> > ColorExt is an abomination when it comes to extending it with additional
> > functionality. I guess, Simon can just cut the release and I'll replace
> > ColorExt with ColorWithAlternatives (or so). I just think it's a shame
> > to release something we know has to change drastically anyway for the
> > next release.
> >
> > On 01.07.2010 13:39:36 Peter Hancock wrote:
> >> > Not sure I understand what you wanted to say.
> >> I was trying to say that I felt that moving color utility code up to
> >> XGC was generally desirable and having to reverting back was a shame.
> >> By 'water down' I really meant reduce, which actually means the
> >> opposite! Sorry :-) .
> >>
> >> On Thu, Jul 1, 2010 at 12:19 PM, Jeremias Maerki <de...@jeremias-maerki.ch> wrote:
> >> >
> >> > On 01.07.2010 13:03:43 Peter Hancock wrote:
> >> > > Hi guys,
> >> > >
> >> > > > But I've just thought of a better alternative:
> >> > > > Moving (!) ColorExt back to FOP where it was and moving
> >> > > > GrayScaleConverter to FOP solves the whole problem with minimal effort
> >> > > > in FOP Trunk.
> >> > > Do you intend to refactor the static ColorUtil.toCMYKGrayColor method
> >> > > to a member of GrayScaleConverter?
> >> >
> >> > I planned to move the toCMYKGrayColor method back to FOP's ColorUtil
> >> > until things are resolved.
> >> >
> >> > > I think this move makes sense for this release but it is a shame to
> >> > > water down the color package in XGC.
> >> >
> >> > Not sure I understand what you wanted to say.
> >> >
> >> > > Pete
> >> > <snip/>
> >> >
> >> >
> >> > Jeremias Maerki
> >> >
> >
> >
> > Jeremias Maerki
> >
> >
> > ---------------------------------------------------------------------
> > To unsubscribe, e-mail: general-unsubscribe@xmlgraphics.apache.org
> > For additional commands, e-mail: general-help@xmlgraphics.apache.org
> >
> >
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: general-unsubscribe@xmlgraphics.apache.org
> For additional commands, e-mail: general-help@xmlgraphics.apache.org
>
Jeremias Maerki
---------------------------------------------------------------------
To unsubscribe, e-mail: general-unsubscribe@xmlgraphics.apache.org
For additional commands, e-mail: general-help@xmlgraphics.apache.org
Re: Status of the new color infrastructure
Posted by Peter Hancock <pe...@gmail.com>.
I have noticed that the equals method of ColorExt is not reflexive, e.g.:
Color c = ..
ColorExt ce = ColorExt.createFromFoRgbIcc(.. ,c.getColorSpace(),
c.getColorComponents(), ..)
c.equals(ce) == true != ce.equals(c)
Could this be addressed now?
Pete
On Thu, Jul 1, 2010 at 2:00 PM, Jeremias Maerki <de...@jeremias-maerki.ch> wrote:
> OK, I see. As you can see, I feel the pretty much way but the current
> ColorExt is an abomination when it comes to extending it with additional
> functionality. I guess, Simon can just cut the release and I'll replace
> ColorExt with ColorWithAlternatives (or so). I just think it's a shame
> to release something we know has to change drastically anyway for the
> next release.
>
> On 01.07.2010 13:39:36 Peter Hancock wrote:
>> > Not sure I understand what you wanted to say.
>> I was trying to say that I felt that moving color utility code up to
>> XGC was generally desirable and having to reverting back was a shame.
>> By 'water down' I really meant reduce, which actually means the
>> opposite! Sorry :-) .
>>
>> On Thu, Jul 1, 2010 at 12:19 PM, Jeremias Maerki <de...@jeremias-maerki.ch> wrote:
>> >
>> > On 01.07.2010 13:03:43 Peter Hancock wrote:
>> > > Hi guys,
>> > >
>> > > > But I've just thought of a better alternative:
>> > > > Moving (!) ColorExt back to FOP where it was and moving
>> > > > GrayScaleConverter to FOP solves the whole problem with minimal effort
>> > > > in FOP Trunk.
>> > > Do you intend to refactor the static ColorUtil.toCMYKGrayColor method
>> > > to a member of GrayScaleConverter?
>> >
>> > I planned to move the toCMYKGrayColor method back to FOP's ColorUtil
>> > until things are resolved.
>> >
>> > > I think this move makes sense for this release but it is a shame to
>> > > water down the color package in XGC.
>> >
>> > Not sure I understand what you wanted to say.
>> >
>> > > Pete
>> > <snip/>
>> >
>> >
>> > Jeremias Maerki
>> >
>
>
> Jeremias Maerki
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: general-unsubscribe@xmlgraphics.apache.org
> For additional commands, e-mail: general-help@xmlgraphics.apache.org
>
>
---------------------------------------------------------------------
To unsubscribe, e-mail: general-unsubscribe@xmlgraphics.apache.org
For additional commands, e-mail: general-help@xmlgraphics.apache.org
Re: Status of the new color infrastructure
Posted by Jeremias Maerki <de...@jeremias-maerki.ch>.
OK, I see. As you can see, I feel the pretty much way but the current
ColorExt is an abomination when it comes to extending it with additional
functionality. I guess, Simon can just cut the release and I'll replace
ColorExt with ColorWithAlternatives (or so). I just think it's a shame
to release something we know has to change drastically anyway for the
next release.
On 01.07.2010 13:39:36 Peter Hancock wrote:
> > Not sure I understand what you wanted to say.
> I was trying to say that I felt that moving color utility code up to
> XGC was generally desirable and having to reverting back was a shame.
> By 'water down' I really meant reduce, which actually means the
> opposite! Sorry :-) .
>
> On Thu, Jul 1, 2010 at 12:19 PM, Jeremias Maerki <de...@jeremias-maerki.ch> wrote:
> >
> > On 01.07.2010 13:03:43 Peter Hancock wrote:
> > > Hi guys,
> > >
> > > > But I've just thought of a better alternative:
> > > > Moving (!) ColorExt back to FOP where it was and moving
> > > > GrayScaleConverter to FOP solves the whole problem with minimal effort
> > > > in FOP Trunk.
> > > Do you intend to refactor the static ColorUtil.toCMYKGrayColor method
> > > to a member of GrayScaleConverter?
> >
> > I planned to move the toCMYKGrayColor method back to FOP's ColorUtil
> > until things are resolved.
> >
> > > I think this move makes sense for this release but it is a shame to
> > > water down the color package in XGC.
> >
> > Not sure I understand what you wanted to say.
> >
> > > Pete
> > <snip/>
> >
> >
> > Jeremias Maerki
> >
Jeremias Maerki
---------------------------------------------------------------------
To unsubscribe, e-mail: general-unsubscribe@xmlgraphics.apache.org
For additional commands, e-mail: general-help@xmlgraphics.apache.org
Re: Status of the new color infrastructure
Posted by Peter Hancock <pe...@gmail.com>.
> Not sure I understand what you wanted to say.
I was trying to say that I felt that moving color utility code up to
XGC was generally desirable and having to reverting back was a shame.
By 'water down' I really meant reduce, which actually means the
opposite! Sorry :-) .
On Thu, Jul 1, 2010 at 12:19 PM, Jeremias Maerki <de...@jeremias-maerki.ch> wrote:
>
> On 01.07.2010 13:03:43 Peter Hancock wrote:
> > Hi guys,
> >
> > > But I've just thought of a better alternative:
> > > Moving (!) ColorExt back to FOP where it was and moving
> > > GrayScaleConverter to FOP solves the whole problem with minimal effort
> > > in FOP Trunk.
> > Do you intend to refactor the static ColorUtil.toCMYKGrayColor method
> > to a member of GrayScaleConverter?
>
> I planned to move the toCMYKGrayColor method back to FOP's ColorUtil
> until things are resolved.
>
> > I think this move makes sense for this release but it is a shame to
> > water down the color package in XGC.
>
> Not sure I understand what you wanted to say.
>
> > Pete
> <snip/>
>
>
> Jeremias Maerki
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: general-unsubscribe@xmlgraphics.apache.org
> For additional commands, e-mail: general-help@xmlgraphics.apache.org
>
---------------------------------------------------------------------
To unsubscribe, e-mail: general-unsubscribe@xmlgraphics.apache.org
For additional commands, e-mail: general-help@xmlgraphics.apache.org
Re: Status of the new color infrastructure
Posted by Jeremias Maerki <de...@jeremias-maerki.ch>.
On 01.07.2010 13:03:43 Peter Hancock wrote:
> Hi guys,
>
> > But I've just thought of a better alternative:
> > Moving (!) ColorExt back to FOP where it was and moving
> > GrayScaleConverter to FOP solves the whole problem with minimal effort
> > in FOP Trunk.
> Do you intend to refactor the static ColorUtil.toCMYKGrayColor method
> to a member of GrayScaleConverter?
I planned to move the toCMYKGrayColor method back to FOP's ColorUtil
until things are resolved.
> I think this move makes sense for this release but it is a shame to
> water down the color package in XGC.
Not sure I understand what you wanted to say.
> Pete
<snip/>
Jeremias Maerki
---------------------------------------------------------------------
To unsubscribe, e-mail: general-unsubscribe@xmlgraphics.apache.org
For additional commands, e-mail: general-help@xmlgraphics.apache.org
Re: Status of the new color infrastructure
Posted by Jeremias Maerki <de...@jeremias-maerki.ch>.
Thanks, Simon. Done:
XGC: http://svn.apache.org/viewvc?rev=959944&view=rev
FOP: http://svn.apache.org/viewvc?rev=959945&view=rev
On 02.07.2010 11:53:40 Simon Pepping wrote:
> On Fri, Jul 02, 2010 at 11:04:20AM +0200, Jeremias Maerki wrote:
> > In the end, I think we have two valid choices:
> >
> > 1. Leave everything as is and do the release right now without the new
> > color infrastructure and deprecate XGC's ColorExt immediately in the
> > color branch. This will mean that ColorExt in XGC will have lived only
> > in the XGC 1.4 release but be deprecated in the next.
> >
> > 2. Move ColorExt back to FOP as I proposed. Batik does not use XGC right
> > now anyway so there's no real benefit of rushing ColorExt into XGC.
> > Furthermore, Batik would never use ColorExt as is. It's just too ugly
> > IMO. FOP will later move from using it's ColorExt to XGC's
> > ColorWithAlternatives.
> >
> > I'm strongly in favor of option 2. As I mentioned, I could make this
> > happen in less than an hour.
>
> I understand option 2 better now. That sounds good. I will continue
> with the release after you commit.
>
> Simon
>
Jeremias Maerki
---------------------------------------------------------------------
To unsubscribe, e-mail: general-unsubscribe@xmlgraphics.apache.org
For additional commands, e-mail: general-help@xmlgraphics.apache.org
Re: Status of the new color infrastructure
Posted by Simon Pepping <sp...@leverkruid.eu>.
On Fri, Jul 02, 2010 at 11:04:20AM +0200, Jeremias Maerki wrote:
> In the end, I think we have two valid choices:
>
> 1. Leave everything as is and do the release right now without the new
> color infrastructure and deprecate XGC's ColorExt immediately in the
> color branch. This will mean that ColorExt in XGC will have lived only
> in the XGC 1.4 release but be deprecated in the next.
>
> 2. Move ColorExt back to FOP as I proposed. Batik does not use XGC right
> now anyway so there's no real benefit of rushing ColorExt into XGC.
> Furthermore, Batik would never use ColorExt as is. It's just too ugly
> IMO. FOP will later move from using it's ColorExt to XGC's
> ColorWithAlternatives.
>
> I'm strongly in favor of option 2. As I mentioned, I could make this
> happen in less than an hour.
I understand option 2 better now. That sounds good. I will continue
with the release after you commit.
Simon
--
Simon Pepping
home page: http://www.leverkruid.eu
---------------------------------------------------------------------
To unsubscribe, e-mail: general-unsubscribe@xmlgraphics.apache.org
For additional commands, e-mail: general-help@xmlgraphics.apache.org
Re: Status of the new color infrastructure
Posted by Jeremias Maerki <de...@jeremias-maerki.ch>.
On 02.07.2010 10:12:09 Simon Pepping wrote:
> On Wed, Jun 30, 2010 at 10:48:26PM +0200, Jeremias Maerki wrote:
> > On 30.06.2010 21:13:10 Simon Pepping wrote:
> > Except for the little thing called backwards-compatibility. ColorExt is
> > new in XGC and we already know it has to change in an incompatible way
> > before its first release. The problem is that this has ripples into FOP.
> > That's why we have to at least shortly discuss it.
>
> That is not a good situation indeed.
>
> > But I've just thought of a better alternative:
> > Moving (!) ColorExt back to FOP where it was and moving
> > GrayScaleConverter to FOP solves the whole problem with minimal effort
> > in FOP Trunk. The ColorConverter interface is fine as it is and can stay
> > there. This will also restore backwards-compatibility for FOP's ColorExt
> > and CMYKColorSpace classes which were already present in 0.95 but
> > removed instead of deprecated. That would take half an hour at most
> > tomorrow morning.
>
> I do not know the details of the color work, so I only have some
> general considerations. Moving functionality back to FOP, why is that
> not a bad thing?
Because it avoids the short life-time of ColorExt in XGC (as it would be
deprecated in XGC 1.5). I see no necessity for ColorExt to be in XGC
right now. It came over as a side-effect of the ColorConverter idea
(which is a good one). Moving color functionality to XGC is not a bad
thing per se, but the current ColorExt in XGC even contains FOP-specific
code (toFunctionCall()) which Batik will never use. The current ColorExt
is not a class that is well thought through which became apparent only
since I've had a concentrated look at colors in general and the upcoming
SVG Color 1.2 and XSL-FO 2.0 specs.
> When do you want to merge your color work into fop
> trunk, before or after the release?
To be on the safe side: after the release. I don't mind working off
unreleased code and the new additions might require some fine-tuning
when I've added SVG Color 1.2 support to Batik.
> If after, can things stay as they
> are now in both xgc and fop?
Yes, in which case I would deprecate ColorExt in XGC and introduce
ColorWithAlternatives instead. But I'd prefer not putting XGC's ColorExt
in XGC 1.4.
> Will you use an upgraded xgc for your
> color work?
Yes. I want a common color infrastructure for both Batik and FOP. That's
why I made color branches for both XGC and FOP. This won't collide with
anything until it's finished and properly tested.
********************
In the end, I think we have two valid choices:
1. Leave everything as is and do the release right now without the new
color infrastructure and deprecate XGC's ColorExt immediately in the
color branch. This will mean that ColorExt in XGC will have lived only
in the XGC 1.4 release but be deprecated in the next.
2. Move ColorExt back to FOP as I proposed. Batik does not use XGC right
now anyway so there's no real benefit of rushing ColorExt into XGC.
Furthermore, Batik would never use ColorExt as is. It's just too ugly
IMO. FOP will later move from using it's ColorExt to XGC's
ColorWithAlternatives.
I'm strongly in favor of option 2. As I mentioned, I could make this
happen in less than an hour.
Jeremias Maerki
---------------------------------------------------------------------
To unsubscribe, e-mail: general-unsubscribe@xmlgraphics.apache.org
For additional commands, e-mail: general-help@xmlgraphics.apache.org
Re: Status of the new color infrastructure
Posted by Jeremias Maerki <de...@jeremias-maerki.ch>.
On 07.07.2010 20:26:15 Vincent Hennebert wrote:
> Jeremias Maerki wrote:
> > On 01.07.2010 13:22:35 Vincent Hennebert wrote:
> <snip/>
> >> Also, I very much doubt that that class should extend Color, but this
> >> is
> >> another topic.
> >
> > IMO, there's one very VERY good reason for extending it from Color: An
> > implementation that doesn't support any of the color alternatives can
> > just live with the sRGB fallback which is also the color that both
> > XSL-FO and SVG specify to be the general fallback. No special code is
> > needed to support basic sRGB colors. I believe it would make the code a
> > lot more complicated if it were not descended from Color. Imagine only
> > our Graphics2D implementations which receive Color instances. I can't
> > even begin to imagine how this would be solved with a non-Color-based
> > color container.
>
> I may be wrong, but it seems to me that XGC defines its own Graphics2D
> implementation (o.a.x.java2d.AbstractGraphics2D) that is passed all over
> the XGC and FOP code. Couldn’t we imagine to associate to it a custom
> Color class that suits the need for a more elaborate colour handling?
It wouldn't be the Graphics2D contract anymore. I'd have to change Batik
in a number of places to support special colors so it calls the special
methods instead of the normal setColor(Color)/setPaint(Paint). I
definitely don't like that.
> Implementations that don’t support elaborate colours would simply call
> some getFallBack method returning a java.awt.Color. Implementations that
> do support them wouldn’t have to do ugly instanceof tests.
The fallback is already in place: Color.getRGB() returns the sRGB value
for every Color subclass. Working around instanceof tests in some places
will not be avoidable. Every output format knows which kinds of color it
supports and has to handle special colors it supports differently.
IMO, adding a parallel class hierarchy for colors only increases
complexity and adds a lot more code and effort. And all that potentially
only because of Color.equals()? Naaaaah.
> AFAIK, three of the major output formats supported by FOP do support
> elaborate colours: PDF, PostScript, AFP. Maybe also PCL.
Right. PCL only if we start implementing color support.
> Also, Peter has a point when pointing out that the equals method is not
> symmetric. The fundamental contract of the equals method is broken, and
> that can only result into hacky workarounds and subtle, hard to find
> bugs. IMO, if the equals method of Color doesn’t do what we want, then
> the whole class is not what we want, and relying on it will only result
> into a wobbly architecture.
Ok, that the Color.equals() contract is broken and the symmetry is lost,
that is right. The Javadocs say that a color is equal if the red, green,
blue and alpha component (sRGB is implied) are equal, it's the same
color. Not so in our case, where we also have to inspect the class and
some of the values added by subclasses. So it would actually be easy to
add a ColorUtil.equals(Color col1, Color col2) which first compares the
Class, the compares the Color's native components (because Color.equals
() doesn't) and finally calls col1's equals() method only if the Class
is the same for both. That reestablishes the symmetry and the required
functionality. How about that?
I don't think you can easily establish such an equals() symmetry as soon
as you compare different classes to each other which have the same
superclass. That's basically what happens here.
At any rate, calling equals() in both directions may be slightly
inefficient but already does the job right now.
What I have now in the branches works fine and is now much clearer (I
just have to update the Wiki). I even implemented the cielab() function
for Batik in 20 minutes after that and got the right color in PDF. That
tells me that at least some things are not as bad.
Jeremias Maerki
---------------------------------------------------------------------
To unsubscribe, e-mail: general-unsubscribe@xmlgraphics.apache.org
For additional commands, e-mail: general-help@xmlgraphics.apache.org
Re: Status of the new color infrastructure
Posted by Vincent Hennebert <vh...@gmail.com>.
Jeremias Maerki wrote:
> On 01.07.2010 13:22:35 Vincent Hennebert wrote:
<snip/>
>> Also, I very much doubt that that class should extend Color, but this
>> is
>> another topic.
>
> IMO, there's one very VERY good reason for extending it from Color: An
> implementation that doesn't support any of the color alternatives can
> just live with the sRGB fallback which is also the color that both
> XSL-FO and SVG specify to be the general fallback. No special code is
> needed to support basic sRGB colors. I believe it would make the code a
> lot more complicated if it were not descended from Color. Imagine only
> our Graphics2D implementations which receive Color instances. I can't
> even begin to imagine how this would be solved with a non-Color-based
> color container.
I may be wrong, but it seems to me that XGC defines its own Graphics2D
implementation (o.a.x.java2d.AbstractGraphics2D) that is passed all over
the XGC and FOP code. Couldn’t we imagine to associate to it a custom
Color class that suits the need for a more elaborate colour handling?
Implementations that don’t support elaborate colours would simply call
some getFallBack method returning a java.awt.Color. Implementations that
do support them wouldn’t have to do ugly instanceof tests.
AFAIK, three of the major output formats supported by FOP do support
elaborate colours: PDF, PostScript, AFP. Maybe also PCL.
Also, Peter has a point when pointing out that the equals method is not
symmetric. The fundamental contract of the equals method is broken, and
that can only result into hacky workarounds and subtle, hard to find
bugs. IMO, if the equals method of Color doesn’t do what we want, then
the whole class is not what we want, and relying on it will only result
into a wobbly architecture.
Vincent
---------------------------------------------------------------------
To unsubscribe, e-mail: general-unsubscribe@xmlgraphics.apache.org
For additional commands, e-mail: general-help@xmlgraphics.apache.org
Re: Status of the new color infrastructure
Posted by Jeremias Maerki <de...@jeremias-maerki.ch>.
On 01.07.2010 13:22:35 Vincent Hennebert wrote:
<snip/>
> ColorExt is meaningless anyway. I don’t know what the old version was
> supposed to do but the new one looks much clearer: ColorAlternatives;
> AlternateColors; FallbackColor; ColorList;
> ColorWithAPrioritizedListOfPreferredVersionsAndAFallbackIfNoneOfThemIsSupported.
I like the last one. ;-) IMO, ColorExt is not that bad since it's short
and says that it's an extended color, but yeah, it's a little lame.
ColorAlternatives is not that bad but like ColorList it may send the
wrong message. For example, ColorList suggests a list of colors, but the
class itself is actually a color. Maybe it has to be
"ColorWithAlternatives". That basically says exactly what it is although
it's a bit longer than ColorExt.
> Also, I very much doubt that that class should extend Color, but this is
> another topic.
IMO, there's one very VERY good reason for extending it from Color: An
implementation that doesn't support any of the color alternatives can
just live with the sRGB fallback which is also the color that both
XSL-FO and SVG specify to be the general fallback. No special code is
needed to support basic sRGB colors. I believe it would make the code a
lot more complicated if it were not descended from Color. Imagine only
our Graphics2D implementations which receive Color instances. I can't
even begin to imagine how this would be solved with a non-Color-based
color container.
Jeremias Maerki
---------------------------------------------------------------------
To unsubscribe, e-mail: general-unsubscribe@xmlgraphics.apache.org
For additional commands, e-mail: general-help@xmlgraphics.apache.org
Re: Status of the new color infrastructure
Posted by Simon Pepping <sp...@leverkruid.eu>.
On Wed, Jun 30, 2010 at 10:48:26PM +0200, Jeremias Maerki wrote:
> On 30.06.2010 21:13:10 Simon Pepping wrote:
> Except for the little thing called backwards-compatibility. ColorExt is
> new in XGC and we already know it has to change in an incompatible way
> before its first release. The problem is that this has ripples into FOP.
> That's why we have to at least shortly discuss it.
That is not a good situation indeed.
> But I've just thought of a better alternative:
> Moving (!) ColorExt back to FOP where it was and moving
> GrayScaleConverter to FOP solves the whole problem with minimal effort
> in FOP Trunk. The ColorConverter interface is fine as it is and can stay
> there. This will also restore backwards-compatibility for FOP's ColorExt
> and CMYKColorSpace classes which were already present in 0.95 but
> removed instead of deprecated. That would take half an hour at most
> tomorrow morning.
I do not know the details of the color work, so I only have some
general considerations. Moving functionality back to FOP, why is that
not a bad thing? When do you want to merge your color work into fop
trunk, before or after the release? If after, can things stay as they
are now in both xgc and fop? Will you use an upgraded xgc for your
color work?
Simon
--
Simon Pepping
home page: http://www.leverkruid.eu
---------------------------------------------------------------------
To unsubscribe, e-mail: general-unsubscribe@xmlgraphics.apache.org
For additional commands, e-mail: general-help@xmlgraphics.apache.org
Re: Status of the new color infrastructure
Posted by Vincent Hennebert <vh...@gmail.com>.
Hi,
Jeremias Maerki wrote:
> On 30.06.2010 21:13:10 Simon Pepping wrote:
>> Does this mean that you want to finish your color work and merge it
>> into trunk before a release?
>
> No, not necessarily. I wanted to discuss what the best course of action
> is concerning the new color infrastructure. Releasing XGC as is causes
> ColorExt to become unusable as a name for the new extended Color class
> since my changes are not backwards-compatible except if we accept a lot
> of memory overhead for the compatibility (which I don't want to). I'll
> have to find a different catchy and short name for that class
> (suggestions welcome BTW) and deprecate ColorExt later.
>
>> I am not happy with that from a project management point of view. It
>> is best to take the decision to make a release, and do that. There is
>> always a nice addition tomorrow, but there is also always a next
>> release.
>
> Except for the little thing called backwards-compatibility. ColorExt is
> new in XGC and we already know it has to change in an incompatible way
> before its first release. The problem is that this has ripples into FOP.
> That's why we have to at least shortly discuss it.
>
>> Many users want a FOP release, so they can use two years of
>> improvements and bug fixes without having to deal with subversion
>> check-outs and build tools.
>
> I know, and I also know that you spend your free time and energy on this.
> And I'm sorry I didn't have this finished earlier.
>
> If you want to do the release now, that's fine. I just need a new class
> name for the new ColorExt class. And I need people to know the
> consequences of a release right now.
ColorExt is meaningless anyway. I don’t know what the old version was
supposed to do but the new one looks much clearer: ColorAlternatives;
AlternateColors; FallbackColor; ColorList;
ColorWithAPrioritizedListOfPreferredVersionsAndAFallbackIfNoneOfThemIsSupported.
Also, I very much doubt that that class should extend Color, but this is
another topic.
> But I've just thought of a better alternative:
> Moving (!) ColorExt back to FOP where it was and moving
> GrayScaleConverter to FOP solves the whole problem with minimal effort
> in FOP Trunk. The ColorConverter interface is fine as it is and can stay
> there. This will also restore backwards-compatibility for FOP's ColorExt
> and CMYKColorSpace classes which were already present in 0.95 but
> removed instead of deprecated. That would take half an hour at most
> tomorrow morning.
>
> WDYT?
>
>> Simon
>>
>> On Wed, Jun 30, 2010 at 04:08:36PM +0200, Jeremias Maerki wrote:
>>> As a heads-up since Simon seems to be back to preparing the XGC release:
>>>
>>> The new basic color infrastructure stands in the dev branch. And it
>>> seems to cover everything necessary for XSL-FO. There are two tricky
>>> things around this:
>>>
>>> 1. I don't really like getting the current ColorExt from Trunk into the
>>> XGC release. The ColorExt in the color branch isn't compatible, but
>> --
>> Simon Pepping
>> home page: http://www.leverkruid.eu
>>
>
>
> Jeremias Maerki
Vincent
---------------------------------------------------------------------
To unsubscribe, e-mail: general-unsubscribe@xmlgraphics.apache.org
For additional commands, e-mail: general-help@xmlgraphics.apache.org
Re: Status of the new color infrastructure
Posted by Peter Hancock <pe...@gmail.com>.
Hi guys,
> But I've just thought of a better alternative:
> Moving (!) ColorExt back to FOP where it was and moving
> GrayScaleConverter to FOP solves the whole problem with minimal effort
> in FOP Trunk.
Do you intend to refactor the static ColorUtil.toCMYKGrayColor method
to a member of GrayScaleConverter?
I think this move makes sense for this release but it is a shame to
water down the color package in XGC.
Pete
On Wed, Jun 30, 2010 at 9:48 PM, Jeremias Maerki <de...@jeremias-maerki.ch> wrote:
> On 30.06.2010 21:13:10 Simon Pepping wrote:
>> Does this mean that you want to finish your color work and merge it
>> into trunk before a release?
>
> No, not necessarily. I wanted to discuss what the best course of action
> is concerning the new color infrastructure. Releasing XGC as is causes
> ColorExt to become unusable as a name for the new extended Color class
> since my changes are not backwards-compatible except if we accept a lot
> of memory overhead for the compatibility (which I don't want to). I'll
> have to find a different catchy and short name for that class
> (suggestions welcome BTW) and deprecate ColorExt later.
>
>> I am not happy with that from a project management point of view. It
>> is best to take the decision to make a release, and do that. There is
>> always a nice addition tomorrow, but there is also always a next
>> release.
>
> Except for the little thing called backwards-compatibility. ColorExt is
> new in XGC and we already know it has to change in an incompatible way
> before its first release. The problem is that this has ripples into FOP.
> That's why we have to at least shortly discuss it.
>
>> Many users want a FOP release, so they can use two years of
>> improvements and bug fixes without having to deal with subversion
>> check-outs and build tools.
>
> I know, and I also know that you spend your free time and energy on this.
> And I'm sorry I didn't have this finished earlier.
>
> If you want to do the release now, that's fine. I just need a new class
> name for the new ColorExt class. And I need people to know the
> consequences of a release right now.
>
> But I've just thought of a better alternative:
> Moving (!) ColorExt back to FOP where it was and moving
> GrayScaleConverter to FOP solves the whole problem with minimal effort
> in FOP Trunk. The ColorConverter interface is fine as it is and can stay
> there. This will also restore backwards-compatibility for FOP's ColorExt
> and CMYKColorSpace classes which were already present in 0.95 but
> removed instead of deprecated. That would take half an hour at most
> tomorrow morning.
>
> WDYT?
>
>> Simon
>>
>> On Wed, Jun 30, 2010 at 04:08:36PM +0200, Jeremias Maerki wrote:
>> > As a heads-up since Simon seems to be back to preparing the XGC release:
>> >
>> > The new basic color infrastructure stands in the dev branch. And it
>> > seems to cover everything necessary for XSL-FO. There are two tricky
>> > things around this:
>> >
>> > 1. I don't really like getting the current ColorExt from Trunk into the
>> > XGC release. The ColorExt in the color branch isn't compatible, but
>>
>> --
>> Simon Pepping
>> home page: http://www.leverkruid.eu
>>
>
>
> Jeremias Maerki
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: general-unsubscribe@xmlgraphics.apache.org
> For additional commands, e-mail: general-help@xmlgraphics.apache.org
>
>
---------------------------------------------------------------------
To unsubscribe, e-mail: general-unsubscribe@xmlgraphics.apache.org
For additional commands, e-mail: general-help@xmlgraphics.apache.org
Re: Status of the new color infrastructure
Posted by Jeremias Maerki <de...@jeremias-maerki.ch>.
On 30.06.2010 21:13:10 Simon Pepping wrote:
> Does this mean that you want to finish your color work and merge it
> into trunk before a release?
No, not necessarily. I wanted to discuss what the best course of action
is concerning the new color infrastructure. Releasing XGC as is causes
ColorExt to become unusable as a name for the new extended Color class
since my changes are not backwards-compatible except if we accept a lot
of memory overhead for the compatibility (which I don't want to). I'll
have to find a different catchy and short name for that class
(suggestions welcome BTW) and deprecate ColorExt later.
> I am not happy with that from a project management point of view. It
> is best to take the decision to make a release, and do that. There is
> always a nice addition tomorrow, but there is also always a next
> release.
Except for the little thing called backwards-compatibility. ColorExt is
new in XGC and we already know it has to change in an incompatible way
before its first release. The problem is that this has ripples into FOP.
That's why we have to at least shortly discuss it.
> Many users want a FOP release, so they can use two years of
> improvements and bug fixes without having to deal with subversion
> check-outs and build tools.
I know, and I also know that you spend your free time and energy on this.
And I'm sorry I didn't have this finished earlier.
If you want to do the release now, that's fine. I just need a new class
name for the new ColorExt class. And I need people to know the
consequences of a release right now.
But I've just thought of a better alternative:
Moving (!) ColorExt back to FOP where it was and moving
GrayScaleConverter to FOP solves the whole problem with minimal effort
in FOP Trunk. The ColorConverter interface is fine as it is and can stay
there. This will also restore backwards-compatibility for FOP's ColorExt
and CMYKColorSpace classes which were already present in 0.95 but
removed instead of deprecated. That would take half an hour at most
tomorrow morning.
WDYT?
> Simon
>
> On Wed, Jun 30, 2010 at 04:08:36PM +0200, Jeremias Maerki wrote:
> > As a heads-up since Simon seems to be back to preparing the XGC release:
> >
> > The new basic color infrastructure stands in the dev branch. And it
> > seems to cover everything necessary for XSL-FO. There are two tricky
> > things around this:
> >
> > 1. I don't really like getting the current ColorExt from Trunk into the
> > XGC release. The ColorExt in the color branch isn't compatible, but
>
> --
> Simon Pepping
> home page: http://www.leverkruid.eu
>
Jeremias Maerki
---------------------------------------------------------------------
To unsubscribe, e-mail: general-unsubscribe@xmlgraphics.apache.org
For additional commands, e-mail: general-help@xmlgraphics.apache.org
Re: Status of the new color infrastructure
Posted by Simon Pepping <sp...@leverkruid.eu>.
Does this mean that you want to finish your color work and merge it
into trunk before a release?
I am not happy with that from a project management point of view. It
is best to take the decision to make a release, and do that. There is
always a nice addition tomorrow, but there is also always a next
release.
Many users want a FOP release, so they can use two years of
improvements and bug fixes without having to deal with subversion
check-outs and build tools.
Simon
On Wed, Jun 30, 2010 at 04:08:36PM +0200, Jeremias Maerki wrote:
> As a heads-up since Simon seems to be back to preparing the XGC release:
>
> The new basic color infrastructure stands in the dev branch. And it
> seems to cover everything necessary for XSL-FO. There are two tricky
> things around this:
>
> 1. I don't really like getting the current ColorExt from Trunk into the
> XGC release. The ColorExt in the color branch isn't compatible, but
--
Simon Pepping
home page: http://www.leverkruid.eu
---------------------------------------------------------------------
To unsubscribe, e-mail: general-unsubscribe@xmlgraphics.apache.org
For additional commands, e-mail: general-help@xmlgraphics.apache.org