Re: FOP's new image package in Commons?
On 20.12.2007 22:40:54 J.Pietschmann wrote: Jeremias Maerki wrote: image loading and processing library in Java Can you give some of the more promising links? I have taken a look myself and haven't found anything closely resembling what we have now. Most only seem to support bitmap formats. Indeed, with the possible exception of PostScript which is occasionally supported by rasterizing by an external interpreter (ghostscript). Which is something that can now easily be integrated into the framework. If only the license was a different one so we could bundle the implementation... I'll try to get more comprehensive data next month. Thanks, I appreciate it. Jeremias Maerki - Apache XML Graphics Project URL: http://xmlgraphics.apache.org/ To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: FOP's new image package in Commons?
Andreas, what I was talking about was exlusively logging targeted at the developer, not the user. User feedback is a different topic, one that I want to address early next year for FOP (see [1]), but I've mentioned that before. [1] http://wiki.apache.org/xmlgraphics-fop/ProcessingFeedback I agree with what Max said. I really don't want to build an abstraction for an abstraction. JCL is good enough and I can't remember any calls from users asking us to find a different solution because they ran into serious problems. Mostly it's just about configuring JCL which is usually no problem. And the other problem is that we don't currently have an answer for processing/user feedback, at least since we switched from Avalon Logging to JCL. But before that we mixed the two aspects which was bad also. On 16.12.2007 10:51:22 Andreas L Delmelle wrote: On Dec 16, 2007, at 10:25, Max Berger wrote: Andreas, How about using a very basic message handling system, to which users can plug in any bridge (like JCL) or specific implementation (like log4j) of their choosing? On the Commons side, this would mean at most a handful of proprietary classes/interfaces, one to which all messages are routed. Users can subclass/implement that interface to decide what to do with them in their particular context. Commons' own default implementation would simply send the messages to System.out or System.err, thereby removing any dependency on a specific logging framework whatsoever. What you are describing is exactly commons-logging :). Not really what I had in mind, or IOW: Yes, with a big BUT... There is a difference between a Logger.warn() message, which I take to be meant for developers to help debug certain issues, and ErrorListener.warning(), which is specifically meant for the external application and the end-user. I see JCL only as an abstraction for the former, not the latter. The only addition that commons-logging has is a very sophisticated (and highly criticized) auto-detection mechanism which detects the type of logging framework currently in use and will auto-plugin is specific handler. OK, and users could still opt for this solution. Only difference is: we would not be forcing the dependency on JCL down their throat, so to speak. Andreas Jeremias Maerki - Apache XML Graphics Project URL: http://xmlgraphics.apache.org/ To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: FOP's new image package in Commons?
On Dec 17, 2007, at 10:48, Jeremias Maerki wrote: Andreas, what I was talking about was exlusively logging targeted at the developer, not the user. User feedback is a different topic, one that I want to address early next year for FOP (see [1]), but I've mentioned that before. OK, just thought I'd try to kill two birds with one stone... Cheers Andreas - Apache XML Graphics Project URL: http://xmlgraphics.apache.org/ To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: FOP's new image package in Commons?
On 18.12.2007 02:21:38 thomas.deweese wrote: Hi Cameron, Jeremias, This is written pretty quickly just to get potential ideas comments out. The Image package sounds nice in general. Jeremias Maerki: I could move the new image package from org.apache.fop.image2 [2] (in the temporary branch) to Commons. The new package name needs to be discussed as there is already an org.apache.xmlgraphics.image. My proposal: org.apache.xmlgraphics.image.loader (in analogy to the writers) Cameron McCormack [EMAIL PROTECTED] wrote on 12/12/2007 07:32:42 PM: Would this be a replacement for Batik?s org.apache.batik.ext.awt.image.spi.* classes? They currently use an SPI interface to provide access to codecs, which take a stream/URL and return a org.apache.batik.ext.awt.image.renderable.Filter. I?m all for rationalising the image handling code between Batik and FOP so that as much commonality as possible can be factored out. Right this would be good. However there are bits that are needed for spec conformance. In particular for PNG we need to be able to override gamma correction for PNG images in order to apply ICC Color profiles. I've noticed that. For FOP, the requirements are (usually) not that high although I would like to improve FOP color-wise. The big problem is lack of knowledge in the color area. I'm also still learning. I'm sure it is absolutely doable to include the features necessary for Batik. FOP will also profit from that. Key features of the package: - Image preloading: format detection and reading the intrinsic size of the image without loading the whole image into memory (works for most images). This is nice. - Image consumers can simply tell the package what kind of images it supports and the image library tries to provide the image in the best possible format (possibly using automatic image conversion). Are we talking about in memory formats (RGB, 8bit, 16bit, Grey, etc.) or disk formats? In-memory representation, although at this time not in such a detailed manner. You can only say: I need a BufferedImage and then you get a BufferedImage. Whether that's 16bit or Grey or whatever currently just depends on the image's original format and the components used to load the image (i.e. the codecs). I'm pretty sure that at some point the use of the ImageFlavor class has to be refined. At the moment, it's just a String indicating what kind of images are supported by a renderer. The PCL renderer, for example, currently just supports bi-level images directly. It does some conversion from color to gray and gray to bi-level by itself. That is something that the image package could also do as part of the conversion pipeline if the ImageFlavor concept is refined. Is it 'push' oriented? I ask because of the mention of Image consumer. This can make filtering complex (basically you would have to cache the entire image in memory). I tried to avoid buffering where possible, exactly because I wanted to keep memory consumption low. But I've worked with RenderedImage for bitmap images, not with Renderable. But the RenderedImage is contructed only when the caller is asking for it. I've looked into Batik's image loading code when I constructed the package in order not to be too far away from the requirements there. - Currently supported: All bitmap formats supported by ImageIO codecs, SVG/WMF through Batik, EPS (only usable for PostScript output without a PostScript interpreter in the back) Does the interface support tiling? Not at the moment, no, because we don't need that functionality for FOP. However, FOP could still profit at some point because large images might consume less memory when processed in tiles. - Custom image loaders and converters can be dynamically plugged in. - Image cache (using soft references) This is a needed feature however it often needs to be overridden to fetch an image that has been rewritten/updated in place. So the ability to flush the cache on an individual and/or group basis is important. I'm sure this can be refined. Thanks for asking these questions. It shows that Batik has quite different requirements in some areas. I'm pretty confident that there is room for improvement in this package so Batik's requirements can be met. FOP simply has a different set. For FOP, it's important to provide more image formats and conversions between them because we also have more different output formats. And that's why the current focus is mostly on that. For Batik it doesn't go to a deep-enough detail level, yet. I guess we simply need to make a few experiments when I've moved the package into Commons. It will quickly show what needs to be improved and how this could be done. Jeremias Maerki - Apache XML Graphics Project URL: http://xmlgraphics.apache.org/ To unsubscribe, e-mail: [EMAIL
Re: FOP's new image package in Commons?
Hi, On Dec 13, 2007 6:21 PM, Jeremias Maerki [EMAIL PROTECTED] wrote: H. What with the people who prefer Log4J and want everything logged there? Commons Logging at least provides a switching central to route the log traffic where you want it. I don't think that's so easy (and readily available) with java.util.logging as with Commons Logging. I do not know how complex the things is, another way is dropping the logging requirement, so there will be no logging introduced at all, just simply java throw exceptions and lets the wrapper / wrapping application handle that exceptions in its own preferred logging mechanism Cheers Tonny Kohar -- Sketsa SVG Editor imagine, design, create ... http://www.kiyut.com - Apache XML Graphics Project URL: http://xmlgraphics.apache.org/ To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: FOP's new image package in Commons?
Thanks for your feedback! Passing additional information to an image converter (like font info) is not a problem. This is already available in the package by passing a Map of key/value pairs through the image pipeline. But carrying the font information from the FO stage all the way to the renderer where the MathML docs are finally processed is a different topic and does not touch the image package. On 12.12.2007 11:41:27 Max Berger wrote: Jeremias, IMO XMLGraphics is definitely the place to be. I would very much like to see the API here, as it should be generic - in this case the jeuclid-fop-plugin would become a jeuclid-xmlgraphics-plugin (which would allow us to mix svg / mathml, an interesting thought). However, this would make some tasks more difficult - for example inheriting the font style / size from the environment (still a tbd for the jeuclid plugin), which is something that would have to be generalized enough. If the size is an issue: Maybe the xmlgraphics commons can be split up into multiple jars? this could be done depending on the actual use, e.g. what batik actually uses and what fop uses. my c2 cts Max On Mit, 2007-12-12 at 11:20 +0100, Jeremias Maerki wrote: Most of you may know that I'm working on a new image loading package for FOP. FOP needs to load all sorts of different image (bitmap, EPS, SVG, MathML and others we don't even need to know about). I'm soon finished with it so it can be merged into FOP Trunk (it's currently in a branch at [1]). The image package itself is basically ready. I'm only finishing the integration in FOP. A month ago, I told Tonny Kohar of Kiyut about the new package, after I've seen their Ekspos Image Viewer [3]. He showed quite some interest and now asked me if I could provide the package as a separate library (i.e. without FOP balast). I've already decoupled the package from FOP as far as possible. Only some nits are left. While working on the integration in the PDFTranscoder (for optimized JPEG embedding using a specialized ImageElementBridge, for example), I noticed that Batik could actually profit from this library, too, i.e. Batik could support additional image formats. When the PDFTranscoder moves to Batik, we would need to move the image library to Commons anyway (or remove the optimized image functionality) as there are dependencies. My proposal now would be: I could move the new image package from org.apache.fop.image2 [2] (in the temporary branch) to Commons. The new package name needs to be discussed as there is already an org.apache.xmlgraphics.image. My proposal: org.apache.xmlgraphics.image.loader (in analogy to the writers) I see various points speaking for this approach: - Clear decoupling from FOP promoting a clean design - Easy reuse by other interested parties (such as Batik, Kiyut) - therefore a bigger chance for additional help from outside our project - Some work for the Transcoder move is already done - Value improvement for Commons Downsides: - Commons JAR grows in size (if Batik doesn't adopt it, more unused code for them in the JAR) Notes: - Some helper classes from FOP will also immediately have to migrate to Commons. But that would happen eventually, when I really have time to move the transcoders. And I will have time next year. That's for sure. :-) Can I get opinions, please (I'm particularly interested what the Batik committers think)? If I need to explain anything in more detail, just ask. - Key features of the package: - Image preloading: format detection and reading the intrinsic size of the image without loading the whole image into memory (works for most images). - Unified API for all kinds of images. - Image conversion facility: bitmap-Java2D, Java2D-bitmap, bitmap-PNG, WMF-Java2D, SVG-Java2D - Image consumers can simply tell the package what kind of images it supports and the image library tries to provide the image in the best possible format (possibly using automatic image conversion). - Currently supported: All bitmap formats supported by ImageIO codecs, SVG/WMF through Batik, EPS (only usable for PostScript output without a PostScript interpreter in the back) - Custom image loaders and converters can be dynamically plugged in. - Image cache (using soft references) [1] https://svn.apache.org/repos/asf/xmlgraphics/fop/branches/Temp_ImagePackageRedesign [2] http://svn.apache.org/viewvc/xmlgraphics/fop/branches/Temp_ImagePackageRedesign/src/java/org/apache/fop/image2/ [3] http://www.kiyut.com/products/ekspos/index.html Jeremias Maerki Jeremias Maerki - Apache XML Graphics Project URL: http://xmlgraphics.apache.org/ To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: FOP's new image package in Commons?
Jeremias, IMO XMLGraphics is definitely the place to be. I would very much like to see the API here, as it should be generic - in this case the jeuclid-fop-plugin would become a jeuclid-xmlgraphics-plugin (which would allow us to mix svg / mathml, an interesting thought). However, this would make some tasks more difficult - for example inheriting the font style / size from the environment (still a tbd for the jeuclid plugin), which is something that would have to be generalized enough. If the size is an issue: Maybe the xmlgraphics commons can be split up into multiple jars? this could be done depending on the actual use, e.g. what batik actually uses and what fop uses. my c2 cts Max On Mit, 2007-12-12 at 11:20 +0100, Jeremias Maerki wrote: Most of you may know that I'm working on a new image loading package for FOP. FOP needs to load all sorts of different image (bitmap, EPS, SVG, MathML and others we don't even need to know about). I'm soon finished with it so it can be merged into FOP Trunk (it's currently in a branch at [1]). The image package itself is basically ready. I'm only finishing the integration in FOP. A month ago, I told Tonny Kohar of Kiyut about the new package, after I've seen their Ekspos Image Viewer [3]. He showed quite some interest and now asked me if I could provide the package as a separate library (i.e. without FOP balast). I've already decoupled the package from FOP as far as possible. Only some nits are left. While working on the integration in the PDFTranscoder (for optimized JPEG embedding using a specialized ImageElementBridge, for example), I noticed that Batik could actually profit from this library, too, i.e. Batik could support additional image formats. When the PDFTranscoder moves to Batik, we would need to move the image library to Commons anyway (or remove the optimized image functionality) as there are dependencies. My proposal now would be: I could move the new image package from org.apache.fop.image2 [2] (in the temporary branch) to Commons. The new package name needs to be discussed as there is already an org.apache.xmlgraphics.image. My proposal: org.apache.xmlgraphics.image.loader (in analogy to the writers) I see various points speaking for this approach: - Clear decoupling from FOP promoting a clean design - Easy reuse by other interested parties (such as Batik, Kiyut) - therefore a bigger chance for additional help from outside our project - Some work for the Transcoder move is already done - Value improvement for Commons Downsides: - Commons JAR grows in size (if Batik doesn't adopt it, more unused code for them in the JAR) Notes: - Some helper classes from FOP will also immediately have to migrate to Commons. But that would happen eventually, when I really have time to move the transcoders. And I will have time next year. That's for sure. :-) Can I get opinions, please (I'm particularly interested what the Batik committers think)? If I need to explain anything in more detail, just ask. - Key features of the package: - Image preloading: format detection and reading the intrinsic size of the image without loading the whole image into memory (works for most images). - Unified API for all kinds of images. - Image conversion facility: bitmap-Java2D, Java2D-bitmap, bitmap-PNG, WMF-Java2D, SVG-Java2D - Image consumers can simply tell the package what kind of images it supports and the image library tries to provide the image in the best possible format (possibly using automatic image conversion). - Currently supported: All bitmap formats supported by ImageIO codecs, SVG/WMF through Batik, EPS (only usable for PostScript output without a PostScript interpreter in the back) - Custom image loaders and converters can be dynamically plugged in. - Image cache (using soft references) [1] https://svn.apache.org/repos/asf/xmlgraphics/fop/branches/Temp_ImagePackageRedesign [2] http://svn.apache.org/viewvc/xmlgraphics/fop/branches/Temp_ImagePackageRedesign/src/java/org/apache/fop/image2/ [3] http://www.kiyut.com/products/ekspos/index.html Jeremias Maerki - Apache XML Graphics Project URL: http://xmlgraphics.apache.org/ To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] signature.asc Description: Dies ist ein digital signierter Nachrichtenteil
Re: FOP's new image package in Commons?
Another important point to consider here: The image package currently makes extensive use of Apache Commons Logging like the rest of FOP. XML Graphics Commons still doesn't use Commons Logging. With the migration of the PDF and EPS transcoders to Batik a lot more code with references to Commons Logging will be affected. Seems to me the right time to talk again about this dependency. Would it be so bad if Commons (and, as a consequence, Batik) added this new dependency? Is there some room for discussion and reevaluation? On 12.12.2007 11:20:12 Jeremias Maerki wrote: Most of you may know that I'm working on a new image loading package for FOP. FOP needs to load all sorts of different image (bitmap, EPS, SVG, MathML and others we don't even need to know about). I'm soon finished with it so it can be merged into FOP Trunk (it's currently in a branch at [1]). The image package itself is basically ready. I'm only finishing the integration in FOP. A month ago, I told Tonny Kohar of Kiyut about the new package, after I've seen their Ekspos Image Viewer [3]. He showed quite some interest and now asked me if I could provide the package as a separate library (i.e. without FOP balast). I've already decoupled the package from FOP as far as possible. Only some nits are left. While working on the integration in the PDFTranscoder (for optimized JPEG embedding using a specialized ImageElementBridge, for example), I noticed that Batik could actually profit from this library, too, i.e. Batik could support additional image formats. When the PDFTranscoder moves to Batik, we would need to move the image library to Commons anyway (or remove the optimized image functionality) as there are dependencies. My proposal now would be: I could move the new image package from org.apache.fop.image2 [2] (in the temporary branch) to Commons. The new package name needs to be discussed as there is already an org.apache.xmlgraphics.image. My proposal: org.apache.xmlgraphics.image.loader (in analogy to the writers) I see various points speaking for this approach: - Clear decoupling from FOP promoting a clean design - Easy reuse by other interested parties (such as Batik, Kiyut) - therefore a bigger chance for additional help from outside our project - Some work for the Transcoder move is already done - Value improvement for Commons Downsides: - Commons JAR grows in size (if Batik doesn't adopt it, more unused code for them in the JAR) Notes: - Some helper classes from FOP will also immediately have to migrate to Commons. But that would happen eventually, when I really have time to move the transcoders. And I will have time next year. That's for sure. :-) Can I get opinions, please (I'm particularly interested what the Batik committers think)? If I need to explain anything in more detail, just ask. - Key features of the package: - Image preloading: format detection and reading the intrinsic size of the image without loading the whole image into memory (works for most images). - Unified API for all kinds of images. - Image conversion facility: bitmap-Java2D, Java2D-bitmap, bitmap-PNG, WMF-Java2D, SVG-Java2D - Image consumers can simply tell the package what kind of images it supports and the image library tries to provide the image in the best possible format (possibly using automatic image conversion). - Currently supported: All bitmap formats supported by ImageIO codecs, SVG/WMF through Batik, EPS (only usable for PostScript output without a PostScript interpreter in the back) - Custom image loaders and converters can be dynamically plugged in. - Image cache (using soft references) [1] https://svn.apache.org/repos/asf/xmlgraphics/fop/branches/Temp_ImagePackageRedesign [2] http://svn.apache.org/viewvc/xmlgraphics/fop/branches/Temp_ImagePackageRedesign/src/java/org/apache/fop/image2/ [3] http://www.kiyut.com/products/ekspos/index.html Jeremias Maerki - Apache XML Graphics Project URL: http://xmlgraphics.apache.org/ To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] Jeremias Maerki - Apache XML Graphics Project URL: http://xmlgraphics.apache.org/ To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: FOP's new image package in Commons?
Jeremias Maerki wrote: Another important point to consider here: The image package currently makes extensive use of Apache Commons Logging like the rest of FOP. XML Graphics Commons still doesn't use Commons Logging. With the migration of the PDF and EPS transcoders to Batik a lot more code with references to Commons Logging will be affected. Seems to me the right time to talk again about this dependency. Would it be so bad if Commons (and, as a consequence, Batik) added this new dependency? Is there some room for discussion and reevaluation? Good point. I would hate to lose logging from these areas of code in addition to the bits we've already compromised on. Logging really helps to debug awkward issues AND is currently used for user feedback (although that should be changed at some point!) snip/ Key features of the package: - Image preloading: format detection and reading the intrinsic size of the image without loading the whole image into memory (works for most images). - Unified API for all kinds of images. - Image conversion facility: bitmap-Java2D, Java2D-bitmap, bitmap-PNG, WMF-Java2D, SVG-Java2D - Image consumers can simply tell the package what kind of images it supports and the image library tries to provide the image in the best possible format (possibly using automatic image conversion). - Currently supported: All bitmap formats supported by ImageIO codecs, SVG/WMF through Batik, EPS (only usable for PostScript output without a PostScript interpreter in the back) If the image package uses Batik does that mean a dependency on Batik from commons? - Custom image loaders and converters can be dynamically plugged in. - Image cache (using soft references) Good work Jeremias. The new image package is very comprehensive and the idea of using it in other packages is a good one and therefore I would vote +1 for such a change (pending a positive answer to my question above :)) Thanks, Chris - Apache XML Graphics Project URL: http://xmlgraphics.apache.org/ To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: FOP's new image package in Commons?
On 12.12.2007 16:45:13 Chris Bowditch wrote: Jeremias Maerki wrote: Another important point to consider here: The image package currently makes extensive use of Apache Commons Logging like the rest of FOP. XML Graphics Commons still doesn't use Commons Logging. With the migration of the PDF and EPS transcoders to Batik a lot more code with references to Commons Logging will be affected. Seems to me the right time to talk again about this dependency. Would it be so bad if Commons (and, as a consequence, Batik) added this new dependency? Is there some room for discussion and reevaluation? Good point. I would hate to lose logging from these areas of code in addition to the bits we've already compromised on. Logging really helps to debug awkward issues AND is currently used for user feedback (although that should be changed at some point!) snip/ Key features of the package: - Image preloading: format detection and reading the intrinsic size of the image without loading the whole image into memory (works for most images). - Unified API for all kinds of images. - Image conversion facility: bitmap-Java2D, Java2D-bitmap, bitmap-PNG, WMF-Java2D, SVG-Java2D - Image consumers can simply tell the package what kind of images it supports and the image library tries to provide the image in the best possible format (possibly using automatic image conversion). - Currently supported: All bitmap formats supported by ImageIO codecs, SVG/WMF through Batik, EPS (only usable for PostScript output without a PostScript interpreter in the back) If the image package uses Batik does that mean a dependency on Batik from commons? Sorry, I wasn't clear enough. No, I don't plan to move the SVG and WMF plugins. When the transcoders are moved to Batik, these plugins will go with them (or sooner if desired). Until then, they remain in FOP. - Custom image loaders and converters can be dynamically plugged in. - Image cache (using soft references) Good work Jeremias. The new image package is very comprehensive and the idea of using it in other packages is a good one and therefore I would vote +1 for such a change (pending a positive answer to my question above :)) Thanks, Chris Jeremias Maerki - Apache XML Graphics Project URL: http://xmlgraphics.apache.org/ To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: FOP's new image package in Commons?
Jeremias Maerki wrote: Most of you may know that I'm working on a new image loading package for FOP. [snip] Good work BTW. I'm quite impressed. A month ago, I told Tonny Kohar of Kiyut about the new package, after I've seen their Ekspos Image Viewer [3]. He showed quite some interest and now asked me if I could provide the package as a separate library (i.e. without FOP balast). I've already decoupled the package from FOP as far as possible. Only some nits are left. I'm all for re-use of code solving common problems. Moving the image loading package into a position more neutral than the FOP project is certainly a good idea. I hope the font related code can be shared with Batik also. As a side note: digging around sf.net and various other code repositories turned up more than one hundred (!!!) attempts at an image loading and processing library in Java. Most of them are abandoned, but there are some thriving projects. I haven't evaluated them in detail, but it might be worth doing this, and possibly seek cooperation. J.Pietschmann - Apache XML Graphics Project URL: http://xmlgraphics.apache.org/ To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: FOP's new image package in Commons?
Jeremias Maerki: Another important point to consider here: The image package currently makes extensive use of Apache Commons Logging like the rest of FOP. XML Graphics Commons still doesn't use Commons Logging. With the migration of the PDF and EPS transcoders to Batik a lot more code with references to Commons Logging will be affected. Seems to me the right time to talk again about this dependency. Would it be so bad if Commons (and, as a consequence, Batik) added this new dependency? Is there some room for discussion and reevaluation? I don’t mind so much. I can’t talk for the other committers, though. -- Cameron McCormack, http://mcc.id.au/ xmpp:[EMAIL PROTECTED] ▪ ICQ 26955922 ▪ MSN [EMAIL PROTECTED] - Apache XML Graphics Project URL: http://xmlgraphics.apache.org/ To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: FOP's new image package in Commons?
J.Pietschmann: I'm all for re-use of code solving common problems. Moving the image loading package into a position more neutral than the FOP project is certainly a good idea. I hope the font related code can be shared with Batik also. Yes, I’d like to re-work the font handling after the 1.7 release, so that might be a good time to converge that functionality. -- Cameron McCormack, http://mcc.id.au/ xmpp:[EMAIL PROTECTED] ▪ ICQ 26955922 ▪ MSN [EMAIL PROTECTED] - Apache XML Graphics Project URL: http://xmlgraphics.apache.org/ To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: FOP's new image package in Commons?
Hi, On Dec 12, 2007 5:41 PM, Max Berger [EMAIL PROTECTED] wrote: If the size is an issue: Maybe the xmlgraphics commons can be split up into multiple jars? this could be done depending on the actual use, e.g. what batik actually uses and what fop uses. Yup, agree with Max regarding using multiple jar, to reduce the size. Cheers Tonny Kohar -- Sketsa SVG Editor imagine, design, create ... http://www.kiyut.com - Apache XML Graphics Project URL: http://xmlgraphics.apache.org/ To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
