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 <matthias8283 <at> 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 <med1985 <at> gmail.com

<mailto:med1985 <at> 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 <matthias8283 <at> gmx.at

    <mailto:matthias8283 <at> 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 <at> __xmlgraphics.apache.org
        <mailto:fop-users-unsubscribe <at> xmlgraphics.apache.org>
        For additional commands, e-mail:
        fop-users-help <at> xmlgraphics.__apache.org
        <mailto:fop-users-help <at> xmlgraphics.apache.org>

---------------------------------------------------------------------
To unsubscribe, e-mail: fop-users-unsubscribe <at> xmlgraphics.apache.org
For additional commands, e-mail: fop-users-help <at> xmlgraphics.apache.org