You are viewing a plain text version of this content. The canonical link for it is here.
Posted to fop-dev@xmlgraphics.apache.org by Peter <pc...@gmail.com> on 2006/10/18 21:11:43 UTC
Dealing with fop-batik dependencies
Fop fans,
I just added a new version of the cmyk/rgb-icc patch to
http://issues.apache.org/bugzilla/show_bug.cgi?id=40729
The changes compared to the previous patch are related to the fact that in
order to add equivalent features to batik it made more sense to restructure
some things.
What is not clear to me is how the dependencies between the Batik and Fop
are managed.
I added a ColorExt class that would also be used in a future Batik change. I
therefore changed fop's build.xml to add that the class to the transcoder
jar assuming Batik would eventually take it from there, but to be honest, I
am far from sure that is the correct way to deal with this.
Let me know if something else is needed.
Thanks,
Peter
Re: Dealing with fop-batik dependencies
Posted by Jeremias Maerki <de...@jeremias-maerki.ch>.
On 18.10.2006 23:32:15 Peter wrote:
> > If the class is to be used by both Batik and FOP it should go into XML
> > Graphics Commons [1] and but for that, Batik should start using Commons
> > in the first place.
> >
> > [1] http://xmlgraphics.apache.org/commons/
> >
> Ok. So should I make commons patch (if I find out how to do that) and update
> the cmyk/icc fop patch? Note that I am not convinced the Batik gang will buy
> any of the changes that I made for cmyk/icc support. There is a thread on
> batik-dev.
I haven't had time to read that part, yet. :-(
> > BTW, since you've created a substantial patch which even contains at
> > least one new file, would you please sign and submit an ICLA (more info,
> > see
> > [2])?
> I can submit that tomorrow.
>
> > And would you please try to mimic the Java style that you find in
> > existing Java files in the future? You seem to be used to working with 2
> > space indents. We use 4 spaces (see [3]). No need to change the current
> > patch. I'll handle that. Just for future work. Thanks.
> Sorry for that (old habits die hard). I will try to remember.
>
> >
> > One final question: Do you expect ColorExt to be stable? If yes and you
> can submit the ICLA soon, I can see to it that it goes into the XML Graphics
> Commons 1.1 release.
>
> I have not run the Batik unit tests but will hopefully do that soon (biggest
> part will probably be to find out how they work). Perhaps something comes
> out of that and/or perhaps the Batik developers have other thoughts that
> could trigger changes. It is kind of difficult working on things that touch
> two (or three) related but independent projects for a beginner like me.
I know. The beginning is always hard. But I think you're already doing a
good job. And you're doing something important. For example, today at
the XSL-FO 2.0 workshop the color topic also came up and we were asked
who implements everything and what the experiences are.
I'll read the thread on batik-dev first, then, so I know everything
that's going on. Hopefully some time on Friday.
>
> > -----Original Message-----
> > From: Jeremias Maerki [mailto:dev@jeremias-maerki.ch]
> > Sent: Wednesday, October 18, 2006 11:13 PM
> > To: fop-dev@xmlgraphics.apache.org
> > Subject: Re: Dealing with fop-batik dependencies
> >
> > If the class is to be used by both Batik and FOP it should go into XML
> > Graphics Commons [1] and but for that, Batik should start using Commons
> > in the first place.
> >
> > [1] http://xmlgraphics.apache.org/commons/
> >
> > BTW, since you've created a substantial patch which even contains at
> > least one new file, would you please sign and submit an ICLA (more info,
> > see
> > [2])? And would you please try to mimic the Java style that you find in
> > existing Java files in the future? You seem to be used to working with 2
> > space indents. We use 4 spaces (see [3]). No need to change the current
> > patch. I'll handle that. Just for future work. Thanks.
> >
> > [2] http://www.apache.org/licenses/#clas
> > [3] http://xmlgraphics.apache.org/fop/dev/conventions.html
> >
> > I hope I can look into your patch ASAP. One final question: Do you
> > expect ColorExt to be stable? If yes and you can submit the ICLA soon, I
> > can see to it that it goes into the XML Graphics Commons 1.1 release.
> >
> > On 18.10.2006 21:11:43 Peter wrote:
> > > Fop fans,
> > >
> > > I just added a new version of the cmyk/rgb-icc patch to
> > > http://issues.apache.org/bugzilla/show_bug.cgi?id=40729
> > >
> > > The changes compared to the previous patch are related to the fact that
> > in
> > > order to add equivalent features to batik it made more sense to
> > restructure
> > > some things.
> > >
> > > What is not clear to me is how the dependencies between the Batik and
> > Fop
> > > are managed.
> > >
> > > I added a ColorExt class that would also be used in a future Batik
> > change. I
> > > therefore changed fop's build.xml to add that the class to the
> > transcoder
> > > jar assuming Batik would eventually take it from there, but to be
> > honest, I
> > > am far from sure that is the correct way to deal with this.
> > >
> > > Let me know if something else is needed.
> > >
> > > Thanks,
> > >
> > > Peter
> >
> >
> >
> > Jeremias Maerki
Jeremias Maerki
RE: Dealing with fop-batik dependencies
Posted by Peter <pc...@gmail.com>.
> If the class is to be used by both Batik and FOP it should go into XML
> Graphics Commons [1] and but for that, Batik should start using Commons
> in the first place.
>
> [1] http://xmlgraphics.apache.org/commons/
>
Ok. So should I make commons patch (if I find out how to do that) and update
the cmyk/icc fop patch? Note that I am not convinced the Batik gang will buy
any of the changes that I made for cmyk/icc support. There is a thread on
batik-dev.
> BTW, since you've created a substantial patch which even contains at
> least one new file, would you please sign and submit an ICLA (more info,
> see
> [2])?
I can submit that tomorrow.
> And would you please try to mimic the Java style that you find in
> existing Java files in the future? You seem to be used to working with 2
> space indents. We use 4 spaces (see [3]). No need to change the current
> patch. I'll handle that. Just for future work. Thanks.
Sorry for that (old habits die hard). I will try to remember.
>
> One final question: Do you expect ColorExt to be stable? If yes and you
can submit the ICLA soon, I can see to it that it goes into the XML Graphics
Commons 1.1 release.
I have not run the Batik unit tests but will hopefully do that soon (biggest
part will probably be to find out how they work). Perhaps something comes
out of that and/or perhaps the Batik developers have other thoughts that
could trigger changes. It is kind of difficult working on things that touch
two (or three) related but independent projects for a beginner like me.
> -----Original Message-----
> From: Jeremias Maerki [mailto:dev@jeremias-maerki.ch]
> Sent: Wednesday, October 18, 2006 11:13 PM
> To: fop-dev@xmlgraphics.apache.org
> Subject: Re: Dealing with fop-batik dependencies
>
> If the class is to be used by both Batik and FOP it should go into XML
> Graphics Commons [1] and but for that, Batik should start using Commons
> in the first place.
>
> [1] http://xmlgraphics.apache.org/commons/
>
> BTW, since you've created a substantial patch which even contains at
> least one new file, would you please sign and submit an ICLA (more info,
> see
> [2])? And would you please try to mimic the Java style that you find in
> existing Java files in the future? You seem to be used to working with 2
> space indents. We use 4 spaces (see [3]). No need to change the current
> patch. I'll handle that. Just for future work. Thanks.
>
> [2] http://www.apache.org/licenses/#clas
> [3] http://xmlgraphics.apache.org/fop/dev/conventions.html
>
> I hope I can look into your patch ASAP. One final question: Do you
> expect ColorExt to be stable? If yes and you can submit the ICLA soon, I
> can see to it that it goes into the XML Graphics Commons 1.1 release.
>
> On 18.10.2006 21:11:43 Peter wrote:
> > Fop fans,
> >
> > I just added a new version of the cmyk/rgb-icc patch to
> > http://issues.apache.org/bugzilla/show_bug.cgi?id=40729
> >
> > The changes compared to the previous patch are related to the fact that
> in
> > order to add equivalent features to batik it made more sense to
> restructure
> > some things.
> >
> > What is not clear to me is how the dependencies between the Batik and
> Fop
> > are managed.
> >
> > I added a ColorExt class that would also be used in a future Batik
> change. I
> > therefore changed fop's build.xml to add that the class to the
> transcoder
> > jar assuming Batik would eventually take it from there, but to be
> honest, I
> > am far from sure that is the correct way to deal with this.
> >
> > Let me know if something else is needed.
> >
> > Thanks,
> >
> > Peter
>
>
>
> Jeremias Maerki
Re: Dealing with fop-batik dependencies
Posted by Jeremias Maerki <de...@jeremias-maerki.ch>.
If the class is to be used by both Batik and FOP it should go into XML
Graphics Commons [1] and but for that, Batik should start using Commons
in the first place.
[1] http://xmlgraphics.apache.org/commons/
BTW, since you've created a substantial patch which even contains at
least one new file, would you please sign and submit an ICLA (more info, see
[2])? And would you please try to mimic the Java style that you find in
existing Java files in the future? You seem to be used to working with 2
space indents. We use 4 spaces (see [3]). No need to change the current
patch. I'll handle that. Just for future work. Thanks.
[2] http://www.apache.org/licenses/#clas
[3] http://xmlgraphics.apache.org/fop/dev/conventions.html
I hope I can look into your patch ASAP. One final question: Do you
expect ColorExt to be stable? If yes and you can submit the ICLA soon, I
can see to it that it goes into the XML Graphics Commons 1.1 release.
On 18.10.2006 21:11:43 Peter wrote:
> Fop fans,
>
> I just added a new version of the cmyk/rgb-icc patch to
> http://issues.apache.org/bugzilla/show_bug.cgi?id=40729
>
> The changes compared to the previous patch are related to the fact that in
> order to add equivalent features to batik it made more sense to restructure
> some things.
>
> What is not clear to me is how the dependencies between the Batik and Fop
> are managed.
>
> I added a ColorExt class that would also be used in a future Batik change. I
> therefore changed fop's build.xml to add that the class to the transcoder
> jar assuming Batik would eventually take it from there, but to be honest, I
> am far from sure that is the correct way to deal with this.
>
> Let me know if something else is needed.
>
> Thanks,
>
> Peter
Jeremias Maerki