In my vision of the API, the servlet programmer would not need useThisRenderer(), but would need something like setOutputType(OUTPUT_PDF), which would ultimately cause the correct renderer to be selected.
This has already been discussed up and down. There is still the problem that renderers may need a lot of renderer specific confiuguration data. Take for example PDF encryption. I don't think it is a good idea to always pass this in some generic way through the Driver (or whatever the replacement) to the renderer. The other problem is the output. There are renderers writing to a byte stream, there is the AWT and the print renderer which don't write to a stream like object at all, there may be renderers like an SVG renderer which write a SAX event stream. Again, I don't think the output should always be passed through the driver. It seems quite natural to solve these problems by using separate renderer objects processor = new FOProcessor() // configure processor renderer = new PDFRenderer(output); // configure renderer processor.setRenderer(renderer); If there is no complicated configuration (use all defaults) you can still write with another constructor processor = new FOProcessor(); processor.format(input,new PDFRenderer(output)); which should be easy enough to servlet programmers.
Note that TrAX uses a similar pattern, with Source and Result abstracting a variety of input and output mechanisms to the XSLT processor.
[big snip] Discussing the API may be fun, but IMO fixing bugs like the broken text justification should get some attention too. The best API is useless if the code inside doesn't work.
J.Pietschmann
--------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, email: [EMAIL PROTECTED]
