Sorry Matthias, I'm an idiot. Not defining a font-base wasn't an over
sight at all; I was just implementing a font-base injection mechanism
and I remembered why we didn't allow this programmatically. You have to
define the font-base using the "<font-base>" element in the fop-conf,
that's the only way to do it and it's intentional.
I'll take this opportunity to explain why we've done what we've done for
the sake of the community, if you're not interested feel free to ignore
the next section:
Some of the problems we were seeing when dealing with a lot of these
configuration classes was that people were adding new parameters and
functionality to them incrementally, as is the case with open-source.
The problem was that there were several ways of doing the same thing and
getters/setters all over the place. So what we did was try and ask "what
would a user want to do? And how do we make that as easy as possible
while still maintaining some encapsulation and immutability in these
How does relate to the font-base? Well, it seems like an abuse of
encapsulation to allow users to set the font-base-URI directly onto the
FontManager. Users shouldn't need to care about these internal
mechanisms, they should be able to just configure it and it works. So we
decided to enforce a single parameter to set the font-base
("<font-base>" in the fop-conf) because th only reason someone would
want to define a font-base-URI would be if they had custom fonts setup,
and in order to do so they'd need a fop-conf anyways. So we might as
well enforce a single point of entry for the font-base-URI, otherwise
you'll have to do "if (x != null)" checks all over the place and how
would you decide which parameter overrides which? Why should a
programmatically set font-base override the one found in the font-base?
How do we document this so that users it's abundantly obvious to users?
We asked ourselves "is there a use case for setting this
programmatically rather than through the fop-conf?" We couldn't see why
anyone would want to do that.
We have tried to reduce the number of entry points for injecting
configuration parameters, for two reasons; 1) because it wasn't
documented and certainly wasn't obvious which parameters overrode which,
when two of the same config parameters were used; 2) for the sake of
developers, so that once the FopFactory hand been created, its state is
mostly immutable (it has mutable members) and we can make certain
assertions on the immutability of the members.
Hope that makes our intentions clear,
On 24 July 2012 07:35, mehdi houshmand <med1985 <at> gmail.com