You are viewing a plain text version of this content. The canonical link for it is here.
Posted to batik-dev@xmlgraphics.apache.org by Thomas E Deweese <th...@kodak.com> on 2002/09/04 14:53:32 UTC
[RE] Re: pdf transcoder packaging?
>>>>> "KL" == Keiron Liddle <ke...@aftexsw.com> writes:
KL> Has anyone thought about this?
Yes. :)
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).
>> 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.
I'm nervous about replicating the PDF Graphics2D codebase between
FOP and Batik. Although I don't think this is what you are
suggesting.
---------------------------------------------------------------------
To unsubscribe, e-mail: batik-dev-unsubscribe@xml.apache.org
For additional commands, e-mail: batik-dev-help@xml.apache.org
Re: [RE] Re: pdf transcoder packaging?
Posted by Keiron Liddle <ke...@aftexsw.com>.
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: batik-dev-unsubscribe@xml.apache.org
For additional commands, e-mail: batik-dev-help@xml.apache.org