xml-general mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Arved Sandstrom <Arved...@chebucto.ns.ca>
Subject Re: Volunteers: First - cut - Deadline 2nd of March
Date Wed, 28 Feb 2001 03:55:59 GMT
At 08:31 PM 2/27/01 -0700, Kelly Campbell wrote:
>On Tue, Feb 27, 2001 at 10:10:04PM -0500, Sam Ruby wrote:
>> 
>> 1) Would it be possible to move towards replacing the w3c.jar with
>> xml-batik?
>
>I know it's been discussed, but I don't remember what the specifics
>are. On a related thought, why doesn't apache.org provide mailing list
>archives and searchability of those?

Keiron Liddle is FOP's SVG guru, and he's been overseeing FOP's interaction 
with Batik. We can but ask.

>> 2) Version 1 of xml-cocoon is still in active development, but is stuck on
>> a backlevel version of xml-fop due to an incompatible change.  Any
>> suggestions on how to resolve this?  For reference, the issue is the last
>> error you see at:
>> 
>>    http://jakarta.apache.org/builds/gump/2001-02-22/xml-cocoon.html
>> 
>Ahh, that's a simple fix. We had to swap out Writer for OutputStream
>because of the binary nature of output formats such as PDF. Unfortunately,
>there's not way to get an outputstream from a writer, so we couldn't
>nicely deprecate that and maintain functionality. Cocoon just needs to
>call setOutputStream there and pass the servlet response outputstream. I
>thought they had already fixed that, but I guess not.

Similar deal with SAXON, which also has explicit support for FOP. Mike Kay 
had his processor working with FOP for a while, then we managed to break it, 
and then with FOP 0.15 I worked with him to get it back (he actually did the 
work, I just liaised). Then, of course, we broke it again. :-) But as Kelly 
said, we had very good reasons for doing so.

What I think we will do soon is have a FOP pow-wow, and once and for all 
nail down some of our APIs. They have finally settled down enough, I think, 
that we can baseline them and let other parties like Saxon and Cocoon know 
that the input (Driver) and output (Renderer) interfaces are fixed. And 
we'll ensure that any proposed changes to these move up a notch in our 
process (majority vote with no vetos, say).

Regards,
Arved Sandstrom

Fairly Senior Software Type
e-plicity (http://www.e-plicity.com)
Wireless * B2B * J2EE * XML --- Halifax, Nova Scotia


Mime
View raw message