Hi Mehdi,
thanks for your explanation. Some questions:
1. What's the default font base directory? The same as the normal base
directory?
2. Can I use a path relative to the normal base directory for the font
base directory?
3. Back to URI resolving: I'm a bit afraid of breaking something if I
implement my own URI resolver. What does the default resolver do? It
would be nice if the default resolver would be part of the public API so
that I can sub class it and just inject the authentication params (like
before).
Btw... it's really nice that all data is loaded now through the new URI
resolver. In the near future I'd like to use a custom scheme (e.g.
myscheme://imageid) in order to load images instead of using HTTP. That
wouldn't be possible without your change. So thanks!
Best regards,
Matthias
On 24.07.2012 04:23, mehdi houshmand wrote:
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 <[email protected]
<mailto:[email protected]>> 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 <[email protected]
<mailto:[email protected]>> 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
<mailto:[email protected]>
For additional commands, e-mail:
fop-users-help@xmlgraphics.__apache.org
<mailto:[email protected]>
---------------------------------------------------------------------
To unsubscribe, e-mail: [email protected]
For additional commands, e-mail: [email protected]
