Mailing-List: contact general-help@xmlgraphics.apache.org; run by ezmlm
Precedence: bulk
Reply-To: general@xmlgraphics.apache.org
Received-SPF: pass (nike.apache.org: local policy)
Date: Fri, 02 Jul 2010 11:04:20 +0200
From: Jeremias Maerki <dev@jeremias-maerki.ch>
To: general@xmlgraphics.apache.org
Subject: Re: Status of the new color infrastructure
In-Reply-To: <20100702081209.GA3474@leverkruid.eu>
References: <20100630222431.8A24.60BA733C@jeremias-maerki.ch>
 <20100702081209.GA3474@leverkruid.eu>
Message-Id: <20100702104436.034F.60BA733C@jeremias-maerki.ch>
MIME-Version: 1.0
Content-Type: text/plain; charset="US-ASCII"
Content-Transfer-Encoding: quoted-printable

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.
>=20
> That is not a good situation indeed.
> =20
> > 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 sta=
y
> > there. This will also restore backwards-compatibility for FOP's ColorEx=
t
> > 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.
>=20
> 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