RE: Dealing with fop-batik dependencies
I can submit that tomorrow. A little later than expected but I faxed it today -Original Message- From: Peter [mailto:[EMAIL PROTECTED] Sent: Wednesday, October 18, 2006 11:32 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/ 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:[EMAIL PROTECTED] 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
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
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:[EMAIL PROTECTED] 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
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:[EMAIL PROTECTED] 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
