Mailing-List: contact general-help@xmlgraphics.apache.org; run by ezmlm
Precedence: bulk
Reply-To: general@xmlgraphics.apache.org
Received-SPF: neutral (athena.apache.org: local policy)
Date: Fri, 10 Sep 2010 14:34:37 +0200
From: Simon Pepping <spepping@leverkruid.eu>
To: general@xmlgraphics.apache.org
Subject: Re: Brainstorming: AFP subproject?
Message-ID: <20100910123437.GA3822@leverkruid.eu>
Mail-Followup-To: general@xmlgraphics.apache.org
References: <AANLkTin_dHgaSSyf5V_cvyiuvSdnXN1-amQB-nO2Lud4@mail.gmail.com>
 <4C8A0628.9030305@gmail.com>
 <20100910133636.0C53.60BA733C@jeremias-maerki.ch>
MIME-Version: 1.0
Content-Type: text/plain; charset=iso-8859-1
Content-Disposition: inline
Content-Transfer-Encoding: 8bit
In-Reply-To: <20100910133636.0C53.60BA733C@jeremias-maerki.ch>
User-Agent: Mutt/1.5.20 (2009-06-14)

For completeness, I note that I have no opinion on this topic.

I am though a bit reluctant to define a new ideal restructuring
goal. Is this one of our high priorities? Of course, it depends on the
size of the work, and if someone sees this as his ideal work for the
coming time, he is welcome to do it.

Simon

On Fri, Sep 10, 2010 at 01:45:10PM +0200, Jeremias Maerki wrote:
> Re-reading you earlier comment (2010-08-25), I realize I misunderstood
> you back then. I thought you suggested XGC as target for the AFP parser
> when you actually proposed an additional subproject. So I'll move the
> AFP parser back to FOP for the moment. It doesn't really make much sense
> in XGC right now.
> 
> That said, I believe RTF is used more intensively than you think. It's
> just that not much effort goes into further improving it, lately.
> 
> Splitting up FOP into multiple JARs is basically OK with me, although I
> prefer having separate source trees to make the dependencies better
> thought through. I've had to fix a number of not so good dependencies
> between packages in the past. Batik has a single source tree and I think
> it's a difficult situation to keep dependencies clear although it's
> easier to set up in the IDE, of course.
> 
> On 10.09.2010 12:19:20 Vincent Hennebert wrote:
> > Ideally every output format should be optional and shipped in its own
> > jar. I???m not sure the RTF library currently included in FOP is any more
> > used than the AFP output. That doesn???t prevent us, anyway, from
> > delivering some fop-all.jar that would contain all the common output
> > formats.
> > 
> > In the case of AFP there now is this AFP parser that has nothing to do
> > with FOP???s or XGC???s primary functions. So I think a dedicated
> > sub-project is most definitely appropriate.
> > 
> > +1 for creating a sub-project.
> > 
> > Vincent
> > 
> > 
> > On 09/09/10 15:08, Julien Aym� wrote:
> > > Hi,
> > > 
> > > As Eric already said, the new format should be split into a separate jar,
> > > but there is no need to create a new subproject.
> > > A dedicated ant task to create the new jar should suffice.
> > > 
> > > Julien
> > > 
> > > 
> > > 2010/9/9 Eric Douglas <edouglas@blockhouse.com>:
> > >> Not only have I never used AFP I don't believe I've heard of it.  I had
> > >> to look it up, which found multiple definitions.  Is this the one you're
> > >> referring to?
> > >> http://en.wikipedia.org/wiki/IBM_Advanced_Function_Printing_(AFP)
> > >>
> > >> I think any output format which adds considerable overhead should be
> > >> split into a separate jar if at all possible, to minimize the amount of
> > >> code to load for anyone not using that format.
> > >>
> > >>
> > >> -----Original Message-----
> > >> From: Jeremias Maerki [mailto:dev@jeremias-maerki.ch]
> > >> Sent: Thursday, September 09, 2010 9:52 AM
> > >> To: general@xmlgraphics.apache.org
> > >> Subject: Brainstorming: AFP subproject?
> > >>
> > >> I've just committed a basic AFP parser to XGC as discussed on fop-dev
> > >> some time ago. While doing that I've started to think that AFP is really
> > >> something not many people know about or need. I wonder if it would make
> > >> sense to actually create an XML Graphics subproject dedicated to AFP. It
> > >> would include the AFP generation library from FOP and the AFP parser
> > >> I've started, maybe even the FOP output plug-in. A dream of mine is to
> > >> have an actual AFP viewer/converter at some point.
> > >>
> > >> The rationale behind it is that the AFP library alone increases the FOP
> > >> JAR size considerably and only relatively few people actually need AFP
> > >> support.
> > >>
> > >> WDYT?

-- 
Simon Pepping
home page: http://www.leverkruid.eu

---------------------------------------------------------------------
To unsubscribe, e-mail: general-unsubscribe@xmlgraphics.apache.org
For additional commands, e-mail: general-help@xmlgraphics.apache.org