Hi All, I think it is generally quite good and thorough. There are some areas I'm not sure about.
For the configuration with the FOProcessor and the Renderer how does it work. Is the renderer configuration inside the FOP configuration and therefore done inside the FOProcessor. How should it work when the renderer is set on the FOProcessor. That could be done through the Factory but that only works for particular uses. With the image resolver. Why do we need to have an ImageResolver and how does this relate to the other SourceResolver. Does the image resolver take the base, url etc. and then do the resolving, lookup the image type and then create a fop.image.Image. If so how are the various image types handled. The mimeType parameter doesn't seem to be able to do this. Unless you want to open the stream first, find the mime type then call this which will reopen the stream and need to do it's own checking. How can we find the mime type which could be unknown but handled by and external resolver. What about opening a stream using a resolver then we can have the image loader peek for the mime type through the image resolver. Once the mime type is found with other info then it could pass that to the image resolver to create a fop image which defaults to using the fop classes. With the api.Renderer, is that a type of renderer factory. I don't understand why you need the getXXXRenderer methods. With the api.Source you will need to cast it to the implementation in the render method. Would it be possible to have a common method that can be used as a source in the Render method. For the usage examples I think there needs to be something for configuration, renderers and image resolving. Keiron. > Hi all, > I polished the FOP API proposal at > http://nagoya.apache.org/wiki/apachewiki.cgi?FOPAvalonization > a bit. Everybody is invited to review and add content. The discussion > points are after the code near the end. > > I think real discussion, with arguments and counterarguments, should > take place on the mailing list, and the Wiki should be used as a > whiteboard holding the facts and thoughts worth to remember. > If a discussion point from the wiki seems to be somewhat resolved on > the mailing list discussion, reformulate it and the associated > comments into appropriate sections, like code, DTD, renderer config > or rationales, then delete it and all associated comments rather > than keep it indefinitely in the wiki. > > Please bolster arguments for adding stuff with appropriate use > cases, perhaps adding to the usage examples section. > > I hope Keiron, Karen and Arved will surface for this discussion. > I'll also post an announcement on cocoon-dev. > > J.Pietschmann --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, email: [EMAIL PROTECTED]
