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
