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.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 <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>
[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>
<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>>
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
<mailto: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
<mailto:fop-users-h...@xmlgraphics.apache.org>>
------------------------------__------------------------------__---------
To unsubscribe, e-mail:
fop-users-unsubscribe@__xmlgraphics.apache.org
<mailto:fop-users-unsubscr...@xmlgraphics.apache.org>
For additional commands, e-mail:
fop-users-help@xmlgraphics.__apache.org
<mailto:fop-users-h...@xmlgraphics.apache.org>
---------------------------------------------------------------------
To unsubscribe, e-mail: fop-users-unsubscr...@xmlgraphics.apache.org
For additional commands, e-mail: fop-users-h...@xmlgraphics.apache.org
