Hi Mehdi,
ok, no problem. While you are at it, please also check why the font
cache file isn't re-generated automatically. Since there has been some
change regarding font loading an exception is thrown (sorry I have no
stack trace right now, but I think it is caused by LazyFont.fontEmbedURI
being null). Deleting the cache file, fixes this behavior.
Thanks,
Matthias
On 07.08.2012 04:04, mehdi houshmand wrote:
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 <[email protected]
<mailto:[email protected]>> 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 <tel:26.07.2012%2011>: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 <[email protected]
<mailto:[email protected]>
<mailto:[email protected] <mailto:[email protected]>>> wrote:
That was supposed to say "<RESOLVER FOR GIVEN SCHEMA".
On 26 July 2012 08:46, mehdi houshmand <[email protected]
<mailto:[email protected]>
<mailto:[email protected] <mailto:[email protected]>>> 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
<http://o.a.f.apps.io>.__ResourceResolverFactory and
its unit test (o.a.f.apps.io
<http://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 <http://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
<[email protected] <mailto:[email protected]>
<mailto:[email protected] <mailto:[email protected]>>> 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>
<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
<[email protected] <mailto:[email protected]>
<mailto:[email protected] <mailto:[email protected]>>
<mailto:[email protected]
<mailto:[email protected]> <mailto:[email protected]
<mailto:[email protected]>>>>
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>
<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
<[email protected]
<mailto:[email protected]> <mailto:[email protected]
<mailto:[email protected]>>
<mailto:[email protected]
<mailto:[email protected]>
<mailto:[email protected]
<mailto:[email protected]>>>> 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@
<mailto:fop-users-unsubscribe@>____xmlgraphics.apache.org
<http://xmlgraphics.apache.org>
<mailto:fop-users-unsubscribe@__xmlgraphics.apache.org
<mailto:[email protected]>>>
For additional commands, e-mail:
fop-users-help@xmlgraphics.__a____pache.org <http://a__pache.org>
<http://apache.org>
<mailto:fop-users-help@
<mailto:fop-users-help@>__xmlgr__aphics.apache.org
<http://xmlgraphics.apache.org>
<mailto:fop-users-help@__xmlgraphics.apache.org
<mailto:[email protected]>>>
------------------------------____----------------------------__--__---------
To unsubscribe, e-mail:
fop-users-unsubscribe@__xmlgra__phics.apache.org
<http://xmlgraphics.apache.org>
<mailto:fop-users-unsubscribe@__xmlgraphics.apache.org
<mailto:[email protected]>>
For additional commands, e-mail:
fop-users-help@xmlgraphics.__a__pache.org
<http://apache.org>
<mailto:fop-users-help@__xmlgraphics.apache.org
<mailto:[email protected]>>
------------------------------__------------------------------__---------
To unsubscribe, e-mail:
fop-users-unsubscribe@__xmlgraphics.apache.org
<mailto:[email protected]>
For additional commands, e-mail:
fop-users-help@xmlgraphics.__apache.org
<mailto:[email protected]>
---------------------------------------------------------------------
To unsubscribe, e-mail: [email protected]
For additional commands, e-mail: [email protected]
