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.
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.
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.
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;.
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?
For the usage examples I think there needs to be something for configuration,
renderers and image resolving.
Certainly. I'll add a new wiki page in order not to clutter the proposal
too much.
J.Pietschmann
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, email: [EMAIL PROTECTED]
