Keiron Liddle wrote:
Then the question seems to be: is the default setup good enough for those who don't want to use avalon for configuration. Then how else should they present the information when avalon is precisely designed for the purpose.
If it is just setting some simple values, okay, but for example embedding fonts is more complex and there is no good reason to create our own data structures just for this.
I don't know what to do. Do you?
Note that an XSLT transformer's output method configuration can also
be fairly elaborate.

On other issue I forgot to mention is the caching, ie saving pages or other data during processing. For example the
with the TRANSIENT_STORE using in cocoon.
I don't think this kind of internals is exposed to the user.

But then why do you need the base URL passed to the image resolver.
Isn't The base a property of the source resolver or image resolver not of the current image.
The base is in general a property of the document which references
the image. It shouldn't change within a rendering run (which is
different for XSLT processors where document() can change it).
Still, the external-graphics src may be a relative URL, and
somehow the base has to be passed down. I'm not fond of static
data for this purpose.

Why not just have createStructureHandler, where this could be a LayoutHandler with the given Renderer or a StructureRenderer. Not sure about the AWT issue though as that has different top level handling.
I can't follow you. Would you please put your suggestion on the
wiki page?

[common method that can be used as a source]
They all aventually go into a set of SAX events that are called onto the FOTree.
But that is a driving process rather than a getting.
Im not sure what you are saying.
I exposed two processing models
1. A model driven by the render() method of the processor. In a naive
  implementation, the input source is cast successively into various
  supported classes, a SAX source is used almost directly, a DOM source
  is traversed and a stream source is parsed. Should work similar to
2. Use getContentHandler() to pipe the FO processor to something else
 and drive it from over there, as in the half a zillion answers to
 "how do I use a <non-file input> with XSLT with FOP?". This is more
 similar to the TrAX TransformerHandler.
Now that I think of it, we could also split this, instead of one
class exposing both render() and getContentHandler(), we also could
use a FOProcessor and a FOProcessorHandler.


To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, email: [EMAIL PROTECTED]

Reply via email to