On 09.02.2007 10:21:23 Vincent Hennebert wrote:
> > Going further along this train of thought..  IMO, in an ideal world all
> > this config stuff should be abstracted in a separate class such as
> > FopConfig - so code dependencies on the avalon Configurable interface
> > would be minimised and configuration would be centrally managed.
> Interesting. I'm not a specialist of the config area, so I hope someone
> who has more insight in this area will be able to give comments. If you
> want to give it a try, please do. Anything that goes towards simplifying
> the code base is a good thing, IMO.

A central config class is probably not a bad idea. Some people have
asked how fonts could be configured programmatically. That's not so easy
at the moment. Something like that could simplify it with the nice
side-effect to make FopFactory and FOUserAgent a little smaller.

OTOH, the use of Avalon Framework allows for a big amount of flexibility.
The renderers can be configured from the central configuration without
knowing how the particular configuration layout for the renderer looks
like (Configurable interface). This is handy if you use custom renderers,
for example. If the configuration were limited to a central object
structure it would limit extensibility quite a bit. Maybe we need
something in between: A "strongly coupled" base config for FOP core and
"loosly coupled" configuration for the plug-ins (renderers, XML handlers
etc.). Not sure how best to solve this dilemma. Flexibility vs.
user-friendlyness. Hmm.

Thinking about configuration I end up each time being a little unhappy
how fonts are configured: per renderer. Especially now that we've
decided not to pursue the FOrayFont road at this time, we have to think
about the direction we want to take. I'm still thinking around a "font
source" concept (discussed in 2003): FOP provides a number of font
sources and each renderer can choose fonts from the set of font sources
it supports. Font sources would be: Java2D subsystem, Type 1 fonts,
TrueType/OpenType fonts, PCL fonts, AFP fonts etc. Something like that
would allow a proper one-time configuration of all fonts and lets the
renderers use whatever they need. But that's another story/thread.

Jeremias Maerki

Reply via email to