That was supposed to say "<RESOLVER FOR GIVEN SCHEMA".
On 26 July 2012 08:46, mehdi houshmand <med1...@gmail.com> wrote:
> 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>
>>
>>
>
