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 classes?"
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,
Mehdi
On 24 July 2012 07:35, mehdi houshmand <med1...@gmail.com> wrote:
> Hi Matthias,
>
> The way we've implemented the interface, you can be completely in control
> of how HTTP is authenticated by implementing
> o.a.f.apps.io.ResourceResolver[1] and giving it to the
> FopFactoryBuilder/FopConfParser[2].
>
> As for the base URI for fonts, you can set this in the fop-conf, we
> haven't created a way to set this programmatically, that was an oversight
> on our end. I'll enable a way to do this and get back to you.
>
> [1] http://wiki.apache.org/xmlgraphics-fop/URIResolution
> [2] http://wiki.apache.org/xmlgraphics-fop/FopFactoryConfiguration
>
> Hope that helps,
>
> Mehdi
>
>
> On 24 July 2012 00:01, Matthias Reischenbacher <matthias8...@gmx.at>wrote:
>
>> Hi,
>>
>> I just tried to upgrade to latest trunk and noticed two compatibility
>> issues with my application which I couldn't fix on my own:
>>
>> * The fontManager has no setBaseURL method anymore. How is the base URL
>> set now?
>>
>> * The FOURIResolver class doesn't exist anymore. Sub classing it for
>> applying HTTP basic authentication parameters is therefore not possible.
>> See also: http://wiki.apache.org/**xmlgraphics-fop/HowTo/**
>> BasicHttpAuthentication<http://wiki.apache.org/xmlgraphics-fop/HowTo/BasicHttpAuthentication>
>> How is HTTP authentication handled now?
>>
>> Thanks for your help,
>> Matthias
>>
>> ------------------------------**------------------------------**---------
>> To unsubscribe, e-mail:
>> fop-users-unsubscribe@**xmlgraphics.apache.org<fop-users-unsubscr...@xmlgraphics.apache.org>
>> For additional commands, e-mail:
>> fop-users-help@xmlgraphics.**apache.org<fop-users-h...@xmlgraphics.apache.org>
>>
>>
>
