On 28.10.2003 03:56:27 Glen Mazza wrote:
> Tom DeWeese of Batik made that suggestion a few months
> back--we're tentatively in agreement that once FOP
> gets solidified, the transcoders can move to them for
> their maintenance and documentation.

Looks like I missed that one. I still haven't read everything from when
I was on holidays. Good news, then, although that means that we have to
do something about the PDF lib and the font code because I wouldn't want
that duplicated. It should be somewhere accessible to both projects.

> > The PDF transcoder
> > could probably have long been promoted to 1.0 status
> > already. 
> 
> Sie haben vergessen!  PDF transcoder is distributed up
> with Batik right now--it's one of 1.0's few success
> stories.  We don't even use maintenance for the
> transcoder--there's not a target for it in
> maintenance's build.xml.

I know, but that doesn't count as a release IMO. It's snapshot that has
been integrated in a release from another project. The Batik people
haven't got control over the code they release. Documentation for the
SVG transcoder is practically non-existent except for a few bits on the
FOP and Batik sites.

> As always, our user base's primary concern is to have 
> a product that can generate [absurdly high number of
> huge image-heavy documents] in [ridiculously small
> amount of time].  That is FOP's responsibility to
> Cocoon, Struts programmers, HP PCL users, Adobe PDF,
> etc.

Right, and maybe parts of our user base will suddenly become active
contributing Java code if we can make life for a newbie easier. That way,
you don't have to do it all by yourself.

> I see the way of accomplishing this is by having FOP
> be (1) extremely fast and optimized; (2) extremely
> accurate; and (3) extremely focused on (1) and (2)
> above.

Yep, I target (3) with my comments. Anyway, if FOP is unable to attract
more developers it will never reach 1.0.

> Making a nice framework for others to create a
> FOP-like product is not as big a concern for me.  I
> want to create FOP, not something to be used for
> creating a FOP. 

It is a concern for me. I believe that a lot of components that
originated in FOP can be very interesting to use outside FOP. That's why
it may make sense to talk about separating things off of FOP to make
them available to a new audience and therefore heightening the
possibility to attract new developers. FOP can profit from that, too.
The XSL-FO layout engine is the main concern for this project.
Everything around it (PDF lib, SVG support, font parsers etc.) is only
infrastructure plus goodies.


Jeremias Maerki

Reply via email to