You are viewing a plain text version of this content. The canonical link for it is here.

Posted to fop-users@xmlgraphics.apache.org by Matthias Reischenbacher <ma...@gmx.at> on 2012/08/02 03:14:30 UTC

Re: Upgrade to fop trunk and URI resolving

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
> <ma...@gmail.com>> wrote:
>
>     That was supposed to say "<RESOLVER FOR GIVEN SCHEMA".
>
>
>     On 26 July 2012 08:46, mehdi houshmand <med1985@gmail.com
>     <ma...@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
>         <matthias8283@gmx.at <ma...@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 <ma...@gmail.com>
>                 <mailto:med1985@gmail.com <ma...@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>
>                      [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
>                 <matthias8283@gmx.at <ma...@gmx.at>
>                      <mailto:matthias8283@gmx.at
>                 <ma...@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
>                 <ma...@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
>                 <ma...@xmlgraphics.apache.org>>
>
>
>
>
>
>             ------------------------------__------------------------------__---------
>             To unsubscribe, e-mail:
>             fop-users-unsubscribe@__xmlgraphics.apache.org
>             <ma...@xmlgraphics.apache.org>
>             For additional commands, e-mail:
>             fop-users-help@xmlgraphics.__apache.org
>             <ma...@xmlgraphics.apache.org>
>
>
>
>


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