xmlgraphics-general mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Thomas DeWeese <Thomas.DeWe...@Kodak.com>
Subject Re: Opinion poll
Date Tue, 08 Mar 2005 03:12:37 GMT
Hi Jeremias,

 >>>2. Do you prefer the transfer of the transcoders to the Batik
 >>>   subproject as Thomas suggested or do you think that the
 >>>   transcoders should be in a separate area that is easily accessible
 >>>   by both teams? Or is that particular question not so important for
 >>>   you?

    As I have stated before I think there is a real build
issue with the PDF transcoder not being in the Batik source
base.  Starting an opinion poll without noting that individuals
involved have raised technical issues is not very friendly.
Given the wording of the question one could hardly vote
against splitting it out.

    There are classes in Batik that the transcoder depends
on (all of GVT) and classes in Batik that will depend on
it (rasterizer app). It is not just a matter of making it
harder for people to find things, the build processes will
involve jumping through hoops in many cases (copying jar
files back and forth).  I gave specific examples of the impact
of this the last time you raised this issue, you seemed to
have ignored that response, and in your response actively
downplayed my issues!

    Take a look at the code, it's dealing with internal
structures of Batik (like replacing the standard text and
image bridges for example), the fact that it is currently
external is due to history and the fact that it has been
just as impossible for the PDF code to be split out of FOP.

Jeremias Maerki wrote:

>>>2. Do you prefer the transfer of the transcoders to the Batik subproject
>>>as Thomas suggested or do you think that the transcoders should be in a
>>>separate area that is easily accessible by both teams? Or is that
>>>particular question not so important for you?
>>
>>I think Transcoders should be accessible to both sets of committers. So 
>>therefore in their own separate area. I seem to remember from previous 
>>discussions that this was difficult to achieve for technical reasons.
> 
> Not really technical, rather organizational. It could be difficult for
> people to find what they need. The Batik build would be more scattered.

   A build that involves the PDF code would in the general case involve
building Batik (without any of the modifications that depend on
the new PDF code, but including modifications needed by the PDF code),
copying the Batik jar file to the PDF build tree, building the PDF code
with it's modifications, moving the PDF jar file back to the Batik tree,
making modifications that rely on the new PDF code and rebuilding the
Batik project again.  This is hardly a good work flow.

   Please let me know what _technical_ advantage we get by having it
in a separate package I have already pointed out the technical
disadvantage.

---------------------------------------------------------------------
Apache XML Graphics Project URL: http://xmlgraphics.apache.org/
To unsubscribe, e-mail: general-unsubscribe@xmlgraphics.apache.org
For additional commands, e-mail: general-help@xmlgraphics.apache.org


Mime
View raw message