> Keiron Liddle wrote:
> > For the configuration with the FOProcessor and the Renderer how does it
work.
>
> Actually there are two approaches which at least appear to be in
> conflict.
> The Avalon approach: implement Configurable and perhaps Composable
> and use an Avalon container which takes care of reading a configuration
> and do the right things.
> However, *forcing* Avalon on everybody is usually not appreciated, the
> Cocoon list has now and then violent rants, and nobody knows how many
> users walked away silently. We can't tell users to create certain
> Avalon Configuration objects, or even read an XML file (once or each
> time they need a processor). For such users there is the Factory
> Pattern approach: the processor has a method for processing and a
> bunch of Bean-style methods to get and set various properties. The
> factory has similar methods and a method to create a preconfigured
> throw-away processor. For the renderer there are two variants:
> 1. Interpret the renderer as abstraction of the processor's output,
> like javax.xml.transform.Result. Currently, renderers don't use
> much configuration data, compared to the processor itself, so you
> can usually get away with a simple new FooRenderer(outputstream).
> 2. Define a factory for each renderer class.
> Actually it is debatable whether even for the processor a factory is
> needed. The criterum is how complicated the configuration is on
> average (in terms of method calls and data to set up before). The
> current proposal has 4 methods, one of them requires a filled data
> structure, this might still be tolerable without a factory.
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.
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.
> > Is the renderer configuration inside the FOP configuration and therefore done
> > inside the FOProcessor.
> The idae was that the renderer is configured separately. This
> assumes extended configuration of a renderer is very rare, i.e.
> default values fit the vast majority of use cases.
Okay.
> > With the image resolver. Why do we need to have an ImageResolver and how
> > does this relate to the other SourceResolver.
>
> The SourceResolver resolves a base+href combo into stream source.
> The default implementation just creates an URI(base,haref) and
> if this is malformed, try to get something from the local file
> system. Use cases:
> - Cope with empty base URIs.
> - General redirection for URIs, in particular for remote http: URLs
> to more local URLs and retrieving stuff from jars.
> - Intelligent fallback mechanisms in case the ressource is not found.
> - Caching at the stream level.
> - Implementing URI schemes and protocols which can't be hooked
> into a lower level, for example the cocoon: scheme.
> The ImageResolver and the FontResolver are for similar purposes, but
> at another level. The default implementation for ImageResolver is
> basically the FOPImageFactory without most of the static bits (i.e.
> caching only for a single rendering run). Use cases:
> - Caching at the image level: peeking into the stream and preparing
> a FOPImage object is expensive enough that there are (may be)
> advantages compared to caching the source stream only.
> - Implement more image formats.
> - Implement sources which are not stream sources, for example
> a SAX source for SVG. There is an overlap with
> fo:instream-foreign-object, however it might be easier to
> hook into a resolver and redirect to the default implementation
> than to implement foreign object stuff.
> Similar for fonts:
> - Implement looking up font data from auxilary font files
> - Retrieving fonts from odd archives.
> The SourceResolver will be used for *everything* which is a stream,
> this includes FO stream sources.
Okay.
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.
> > With the api.Renderer, is that a type of renderer factory.
> No. It is the renderer itself, basically the same we have now.
>
> > I don't understand why you need the getXXXRenderer methods.
> That's because I've seen code like the following in the Driver:
> if (renderer instanceof MIFRenderer) {
> structureRenderer = new StructureRenderer(renderer);
> ...
> I think the renderer object should take care to create specific
> interfaces which sit between the layout processor and the renderer.
> Therefore the MIFREnderer could have
> StructureRenderer getStructureRenderer() {
> return new StructureRenderer(this);
> }
> while the PDF renderer has a return null;.
I see, that makes sense.
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.
> > With the api.Source you will need to cast it to the implementation in the render
> > method.
> Well, we could look how the TrAX implementations handle this.
>
> > Would it be possible to have a common method that can be used as a
> > source in the Render method.
> Can you elaborate?
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.
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, email: [EMAIL PROTECTED]
