For either my suggestion or Andreas' further proposal we would certainly need to do a little bit of refactoring, abstracting out all those member config variables in FopFactory into a base configuration object. This base configuration object would be a singleton and *unmodifiable* and would only serve the function of providing the default fallback configuration settings A second user agent configuration object would be created per user agent, this configuration would be modifiable. The user agent configuration would derive configuration values from the base configuration when values were not provided programmatically through API on the fly. A third configuration object could represent the document level configuration. This would be created on construction of the FO tree and it would derive its default values from the user agent configuration which in turn would derive its values (in their absence) from the base configuration. Hope I explained how that would work clearly enough, does that make sense?


Jeremias Maerki wrote:
I'm not sure I like this whole thing, yet. Of course, your suggestion is
fine. But there's one thing that needs to be figured out: The
configuration is applied to the FopFactory. Having the configuration on
this level provides a multi-threading problem as multiple rendering runs
might simultaneously modify the configuration of the shared FopFactory.

On 26.02.2008 22:17:59 Andreas Delmelle wrote:
Hi all

Some time ago, Adrian posted an interesting suggestion on fop-users@ for an extension that would basically allow a configuration to be bound to a single document: a fox:configuration node that could be specified as a descendant of the fo:declarations.

Now, I just wondered about the following: instead of making it an extension, maybe we could dedicate a special namespace to FOP's configuration. The nodes that are now present in the sample fop.xconf could then appear anywhere in the document. For some options the appearances should probably best be restricted, but imagine something like:

<fo:root xmlns:fo="";
   <fo:external-graphic src="relative/path/to/image.png" />
   <fo:external-graphic src="relative/path/to/another/image.png" />
</fo:block> <!-- end of scope for the cfg:* settings -->

An author would be able to override default configuration settings on a per-FO basis, with an implied scope of the entire document if the settings are specified as direct descendants of the fo:root.

Just a thought...



Jeremias Maerki

Reply via email to