xmlgraphics-fop-users mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From mehdi houshmand <med1...@gmail.com>
Subject Re: Upgrade to fop trunk and URI resolving
Date Tue, 07 Aug 2012 07:04:41 GMT
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 <matthias8283@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 <med1985@gmail.com
>> <mailto:med1985@gmail.com>> wrote:
>>
>>     That was supposed to say "<RESOLVER FOR GIVEN SCHEMA".
>>
>>
>>     On 26 July 2012 08:46, mehdi houshmand <med1985@gmail.com
>>     <mailto:med1985@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
>>         <matthias8283@gmx.at <mailto:matthias8283@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
>>                 <med1985@gmail.com <mailto:med1985@gmail.com>
>>                 <mailto:med1985@gmail.com <mailto:med1985@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
>>                 <matthias8283@gmx.at <mailto:matthias8283@gmx.at>
>>                      <mailto:matthias8283@gmx.at
>>
>>                 <mailto:matthias8283@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-unsubscribe@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-help@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-unsubscribe@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-help@xmlgraphics.apache.org>
>> >
>>
>>
>>
>>
>>
>
> ------------------------------**------------------------------**---------
> To unsubscribe, e-mail: fop-users-unsubscribe@**xmlgraphics.apache.org<fop-users-unsubscribe@xmlgraphics.apache.org>
> For additional commands, e-mail: fop-users-help@xmlgraphics.**apache.org<fop-users-help@xmlgraphics.apache.org>
>
>

Mime
View raw message