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 org.apache.excalibur.store.Store
with the TRANSIENT_STORE using in cocoon.
I don't think this kind of internals is exposed to the user.
[resolver]
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
transformer.transform().
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.
J.Pietschmann
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, email: [EMAIL PROTECTED]
