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]

Reply via email to