J.Pietschmann wrote: > Victor Mote wrote: > > 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.
I don't understand. The setOutputType() would be in the RenderType class, which is one of the four classes that Driver would be split into. So there might also be, for example, a setEncryptionKey() method to handle this. The whole point of creating the three extra classes is to make the granularity fine enough to properly control this kind of stuff. I'm sorry if I have missed your point. > 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. I think we are in agreement here, except that it looks like you are thinking single Document, and I have added a mechanism (the Document class) that will allow multiple Documents to be queued up and/or multithreaded. > 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. I assume you are talking about trunk here. If so, my reasoning for trying to get API resolved (or really Control, from my perspective) is so that I can continue with getting the layout cleanly separated and pluggable, which I view as being the critical path toward project sanity. I have been trying for a year now to work on fonts, and I can't get there from here. Victor Mote --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, email: [EMAIL PROTECTED]
