On Wed, 2002-09-04 at 14:53, Thomas E Deweese wrote: > KL> On Wed, 2002-07-24 at 11:29, Keiron Liddle wrote: > >> I was wondering if it might be a good idea to either have a > >> separate pdf transcoder release with docs packaging etc. or to have > >> it with the batik release. The jar size is about 240kb. There are > >> also some pdf specific tests that go with the transcoder. > > The problem here is that the PDF transcoder (which is really the > PDF Graphics2D, right?). Is something that both Batik and FOP find > really useful. If you are suggesting a PDF Graphics2D apache project > (i.e. split PDF Graphics2D development out of FOP) then this might be > a good idea. > > I'm not against moving the PDF Graphics2D into Batik either but it > is a little 'off topic', of course then you could perhaps leverage > more of the Batik Graphics2D infrastructure (especially for raster > images).
I think I need to choose my words better :) What I am talking about is the distribution of jars. The code should stay exactly where it is (for the forseeable future). > >> There is one problem. The current pdf transcoder cannot be used in > >> the same classpath as a FOP release (due to changed classes). The > >> advantages would be that it is a smaller jar, can have independant > >> releases. > >> > >> What do you think? What is the best way to do this. > > If we do the Services based restructuring of the Transcoders then > things could be pretty completely seperated out, if the PDF jar is on > the classpath you get PDF output, if not you don't. Yes this is a good part of making it easier for users. > I'm nervous about replicating the PDF Graphics2D codebase between > FOP and Batik. Although I don't think this is what you are > suggesting. No :) --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]