Hi Matthias
I haven't had a chance to look at this, I will do so in the next few days.
Sorry for the slow response, I will address this issue shortly.
Mehdi
On 2 August 2012 02:14, Matthias Reischenbacher <matthias8...@gmx.at> wrote:
> Hi Mehdi,
>
> thanks for updating the javadoc.
>
> I've been experimenting with the new API and I've found a minor bug about
> font configuration. Please have a look at the following piece of code of
> the ParserHelper inside DefaultFontConfig:
>
> private ParserHelper(Configuration cfg, boolean strict) throws
> FOPException {
> if (cfg == null || cfg.getChild("fonts", false) == null) {
> instance = null;
> } else {
> this.strict = strict;
> this.fontInfoCfg = cfg.getChild("fonts", false);
> instance = new DefaultFontConfig(cfg.**getChild("auto-detect",
> false) != null);
> parse();
> }
> }
>
> The auto-detect element is not read from the this.fontInfoCfg element as
> it should be. Could you please fix that?
>
> Thanks,
> Matthias
>
>
> On 26.07.2012 11:03, mehdi houshmand wrote:
>
>> Hi Matthias,
>>
>> I've added some javadocs that may help to enlighten devs about how to do
>> some of the URI schema features you were asking about. As a potential
>> user, if you could take a look and let me know whether it's clear
>> enough, I'd be very grateful. I always find hard to know how much
>> information to put in a javadoc...
>>
>> Thanks
>>
>> Mehdi
>>
>> On 26 July 2012 08:48, mehdi houshmand <med1...@gmail.com
>> <mailto:med1...@gmail.com>> wrote:
>>
>> That was supposed to say "<RESOLVER FOR GIVEN SCHEMA".
>>
>>
>> On 26 July 2012 08:46, mehdi houshmand <med1...@gmail.com
>> <mailto: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.**ResourceResolverFactoryTestCas**e)
>> the static inner class
>> "**TestCreateSchemaAwareResourceR**esolverBuilderHelper" (say
>> that
>> quickly 20 times) does what you're looking for.
>>
>> Essentially do the following:
>> ResourceResolverFactory.**SchemaAwareResourceResolverBui**lder
>> builder =
>> ResourceResolverFactory.**createSchemaAwareResourceResol**
>> verBuilder(<DEFAULT
>> RESOLVER>);
>> builder.**registerResourceResolverForSch**ema(<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 <mailto: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 <tel:24.07.2012%2004>: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>
>> <mailto: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
>> <http://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>
>>
>> <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>
>>
>> <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>
>> <mailto: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>
>> >
>>
>>
>>
>> <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://xmlgra__phics.apache.org>
>> <http://xmlgraphics.apache.org**>
>>
>> <mailto:fop-users-unsubscribe@**__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://a__pache.org>
>> <http://apache.org>
>> <mailto:fop-users-help@__xmlgr**
>> aphics.apache.org <http://xmlgraphics.apache.org>
>>
>> <mailto:fop-users-help@**xmlgraphics.apache.org<fop-users-h...@xmlgraphics.apache.org>
>> >>
>>
>>
>>
>>
>>
>>
>> ------------------------------**
>> __----------------------------**--__---------
>> 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>
>
>
