Hi Matthias,
Don't be so quick to thank us for this work, you may retract that once you
start using it ;).
1. Good question. The way it works is that you give the FopFactory (either
in a constructor or via the EnvironmentProfile) a base-URI, this will
become the default base URI should a "<font-base>" not be given.
2. Yes, you can use a relative URI and it resolves against the default base
URI described in 1). What I've tried to do is make all URIs resolve to
against single base URI that is given in the constructor of the FopFactory.
Interestingly though, I just noticed something we didn't consider. What if
the URI given to the FopFactory isn't an absolute URI? We don't check at
any point to ensure it is absolute... I think it would resolve against "new
URI(".")" where-ever that may be. Maybe we want throw an
IllegalArgumentException? I don't know.
3. There is some documentation as to how to do this, though I think we
could have probably done better in publishing more detailed explanation as
to what we've done here. So we have created a mechanism for handling URI
schemes, since it's an integral part of the URI spec, and it's almost the
raison d'etre. Look at the o.a.f.apps.io.ResourceResolverFactory and its
unit test (o.a.f.apps.io.ResourceResolverFactoryTestCase) the static inner
class "TestCreateSchemaAwareResourceResolverBuilderHelper" (say that
quickly 20 times) does what you're looking for.
Essentially do the following:
ResourceResolverFactory.SchemaAwareResourceResolverBuilder builder =
ResourceResolverFactory.createSchemaAwareResourceResolverBuilder(<DEFAULT
RESOLVER>);
builder.registerResourceResolverForSchema(<SCHEMA>, <RESOLVER GIVEN
SCEHMA>);
... // you can add any number of schemas with their corresponding resolvers
ResourceResolver resolver = builder.build();
// resolver is then used as the resolver given to either the
FopFactoryBuilder or FopConfParser, either directly or via the
EnvironmentProfile.
I'd play around with this mechanism, it can be very powerful once you play
around with URIs. You can define the the font-base as "font://" and use
"font" as the schema and thus have much finer control as to where the fonts
are. This brings the full power of the URI spec to all resource
acquisition. All you have to do is implement the ResourceResolver interface.
Also, an FYI for you and anyone else that uses FOP in systems that require
fine-grained control over I/O and file access; you can now control where
FOP writes/reads from temporary files (scratch files used to save on
memory.) By implementing the o.a.f.apps.io.TempResourceResolver, you can
mitigate any security risks from leaking information or any worries one may
have. (Though realistically, the way FOP uses scratch files, that's not
very likely, but it's always better safe than sorry.)
I hope all that makes sense, if not, please feel free to ask me to clarify.
Mehdi
On 25 July 2012 21:25, Matthias Reischenbacher <matthias8...@gmx.at> wrote:
> 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 <med1...@gmail.com
>> <mailto: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<http://wiki.apache.org/xmlgraphics-fop/URIResolution>
>> [2] http://wiki.apache.org/**xmlgraphics-fop/**
>> FopFactoryConfiguration<http://wiki.apache.org/xmlgraphics-fop/FopFactoryConfiguration>
>>
>> Hope that helps,
>>
>> Mehdi
>>
>>
>> On 24 July 2012 00:01, Matthias Reischenbacher <matthias8...@gmx.at
>> <mailto: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>
>>
>> <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@__xmlgra**phics.apache.org<http://xmlgraphics.apache.org>
>>
>> <mailto:fop-users-unsubscribe@**xmlgraphics.apache.org<fop-users-unsubscr...@xmlgraphics.apache.org>
>> >
>> For additional commands, e-mail:
>> fop-users-help@xmlgraphics.__a**pache.org <http://apache.org>
>>
>> <mailto:fop-users-help@**xmlgraphics.apache.org<fop-users-h...@xmlgraphics.apache.org>
>> >
>>
>>
>>
>>
>
> ------------------------------**------------------------------**---------
> 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>
>
>
