Re: Upgrade to fop trunk and URI resolving

[Glenn Adams]

Thanks, and no problem!

On Tue, Aug 14, 2012 at 11:28 PM, mehdi houshmand  wrote:

> Glenn, I made the necessary changes. I must admit, I didn't realise the
> consequences of changing the serialized form of the FontCache class so
> thank you for pointing that out.
>
> Mehdi
>
>
> On 10 August 2012 16:14, mehdi houshmand  wrote:
>
>> Hi Matthias,
>>
>> You were, of course, correct and I've made the necessary change as well
>> as some other improvements. Glenn, I'll take a look at this serialization
>> ID next.
>>
>> Mehdi
>>
>>
>> On 8 August 2012 08:30, mehdi houshmand  wrote:
>>
>>> Ok, I'll do that at the same time. Thanks Glenn
>>>
>>>
>>> On 8 August 2012 07:49, Glenn Adams  wrote:
>>>

 On Wed, Aug 8, 2012 at 12:09 AM, mehdi houshmand wrote:

> Do you have any more information than that? o.a.f.fonts.FontCache has
> changed in that URIs, which were previously stored as Strings, are now
> stored as java.net.URI, this means an exception is thrown when trying to
> deserialize the class. I believe this exception is caught somewhere and it
> causes a member of LazyFont to be null, is that what you're talking about?
> Or is there another issue?
>
> This basically means the fonts-cache isn't backwards compatible, you
> have to delete the old one (prior to Temp_URI_res merge) and it should
> regenerate with the new serialization.
>

 If you have changed the serialization for the font cache and haven't
 done so already, you should change the value(s) of serialVersionUID in the
 classes which have changed their serialization.

>>>
>>>
>>
>

Re: Upgrade to fop trunk and URI resolving

[mehdi houshmand]

Glenn, I made the necessary changes. I must admit, I didn't realise the
consequences of changing the serialized form of the FontCache class so
thank you for pointing that out.

Mehdi

On 10 August 2012 16:14, mehdi houshmand  wrote:

> Hi Matthias,
>
> You were, of course, correct and I've made the necessary change as well as
> some other improvements. Glenn, I'll take a look at this serialization ID
> next.
>
> Mehdi
>
>
> On 8 August 2012 08:30, mehdi houshmand  wrote:
>
>> Ok, I'll do that at the same time. Thanks Glenn
>>
>>
>> On 8 August 2012 07:49, Glenn Adams  wrote:
>>
>>>
>>> On Wed, Aug 8, 2012 at 12:09 AM, mehdi houshmand wrote:
>>>
 Do you have any more information than that? o.a.f.fonts.FontCache has
 changed in that URIs, which were previously stored as Strings, are now
 stored as java.net.URI, this means an exception is thrown when trying to
 deserialize the class. I believe this exception is caught somewhere and it
 causes a member of LazyFont to be null, is that what you're talking about?
 Or is there another issue?

 This basically means the fonts-cache isn't backwards compatible, you
 have to delete the old one (prior to Temp_URI_res merge) and it should
 regenerate with the new serialization.

>>>
>>> If you have changed the serialization for the font cache and haven't
>>> done so already, you should change the value(s) of serialVersionUID in the
>>> classes which have changed their serialization.
>>>
>>
>>
>

Re: Upgrade to fop trunk and URI resolving

[mehdi houshmand]

Hi Matthias,

You were, of course, correct and I've made the necessary change as well as
some other improvements. Glenn, I'll take a look at this serialization ID
next.

Mehdi

On 8 August 2012 08:30, mehdi houshmand  wrote:

> Ok, I'll do that at the same time. Thanks Glenn
>
>
> On 8 August 2012 07:49, Glenn Adams  wrote:
>
>>
>> On Wed, Aug 8, 2012 at 12:09 AM, mehdi houshmand wrote:
>>
>>> Do you have any more information than that? o.a.f.fonts.FontCache has
>>> changed in that URIs, which were previously stored as Strings, are now
>>> stored as java.net.URI, this means an exception is thrown when trying to
>>> deserialize the class. I believe this exception is caught somewhere and it
>>> causes a member of LazyFont to be null, is that what you're talking about?
>>> Or is there another issue?
>>>
>>> This basically means the fonts-cache isn't backwards compatible, you
>>> have to delete the old one (prior to Temp_URI_res merge) and it should
>>> regenerate with the new serialization.
>>>
>>
>> If you have changed the serialization for the font cache and haven't done
>> so already, you should change the value(s) of serialVersionUID in the
>> classes which have changed their serialization.
>>
>
>

Re: Upgrade to fop trunk and URI resolving

[mehdi houshmand]

Ok, I'll do that at the same time. Thanks Glenn

On 8 August 2012 07:49, Glenn Adams  wrote:

>
> On Wed, Aug 8, 2012 at 12:09 AM, mehdi houshmand wrote:
>
>> Do you have any more information than that? o.a.f.fonts.FontCache has
>> changed in that URIs, which were previously stored as Strings, are now
>> stored as java.net.URI, this means an exception is thrown when trying to
>> deserialize the class. I believe this exception is caught somewhere and it
>> causes a member of LazyFont to be null, is that what you're talking about?
>> Or is there another issue?
>>
>> This basically means the fonts-cache isn't backwards compatible, you have
>> to delete the old one (prior to Temp_URI_res merge) and it should
>> regenerate with the new serialization.
>>
>
> If you have changed the serialization for the font cache and haven't done
> so already, you should change the value(s) of serialVersionUID in the
> classes which have changed their serialization.
>

Re: Upgrade to fop trunk and URI resolving

[Glenn Adams]

On Wed, Aug 8, 2012 at 12:09 AM, mehdi houshmand  wrote:

> Do you have any more information than that? o.a.f.fonts.FontCache has
> changed in that URIs, which were previously stored as Strings, are now
> stored as java.net.URI, this means an exception is thrown when trying to
> deserialize the class. I believe this exception is caught somewhere and it
> causes a member of LazyFont to be null, is that what you're talking about?
> Or is there another issue?
>
> This basically means the fonts-cache isn't backwards compatible, you have
> to delete the old one (prior to Temp_URI_res merge) and it should
> regenerate with the new serialization.
>

If you have changed the serialization for the font cache and haven't done
so already, you should change the value(s) of serialVersionUID in the
classes which have changed their serialization.

Re: Upgrade to fop trunk and URI resolving

[Matthias Reischenbacher]

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 mailto: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 mailto:med1...@gmail.com>
>> wrote:

 That was supposed to say "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 "" 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();
 builder.__registerResourceResolverForSch__ema(,
);
 ... // 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 

Re: Upgrade to fop trunk and URI resolving

[mehdi houshmand]

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  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 > > wrote:
>>
>> That was supposed to say ">
>>
>> On 26 July 2012 08:46, mehdi houshmand > > 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 "" 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(> RESOLVER>);
>> builder.**registerResourceResolverForSch**ema(, > 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 like

Re: Upgrade to fop trunk and URI resolving

[Matthias Reischenbacher]

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 mailto:med1...@gmail.com>> wrote:

That was supposed to say "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 "" 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();
builder.registerResourceResolverForSchema(, );
... // 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
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 af

Re: Upgrade to fop trunk and URI resolving

[Jeremias Maerki]

Hi Mehdi,
that adapter is the beginning of that convenience adapter I was talking
about. But there are a few issues with it (without having tried to run
the code):
- a StreamSource does not always have an InputStream. Apache XML Commons
Resolver usually returns a StreamSource with just the resolved URL set
as the system ID if I remember correctly. The URL has to be opened via
java.net.URL.
- SAXSource will also need to be handled aside from DOMSource.
- a Source cannot be a StreamResult, so you can't use URIResolver for
URLs that will be written to. URIResolver is strictly on the reading
side.
- TransformerExceptions should probably be re-thrown as
IOException(WithCause) rather than RuntimeException.

At any rate, I'd like to point you to 
http://wiki.apache.org/xmlgraphics-fop/HowTo/XmlCommonsResolver
which contains a working example for using XML catalogs with FOP. I
believe that this is something that more than a handful of people are
using in production so it would be great if this functionality remains
available, even if it's just through that URIResolverAdapter.

The performance loss with DOMSource/SAXSource, I can probably stomach,
but I'm only speaking for myself. But I beg you not to replace
URIResolver by ResourceResolver in the XGC Image Loading Framework. If
your goal is to better control where files are written by FOP, that's
one thing, or not wanting to deal with StreamSource's many accessors
when just loading a font which always requires an InputStream, that's
another. But URIResolver is just more powerful when it comes to provide
read-access to resources that may be a byte stream, character stream,
XML DOM, SAX event source like is the case with images.

Thanks,
Jeremias Maerki


On 30.07.2012 13:02:41 mehdi houshmand wrote:
> Jeremias,
> 
> I was looking into this, and it became abundantly clear that I don't really
> know what you're trying to do with the java.xml.transform.URIResolver...
> Would something like this be appropriate as an adapter between the two
> interfaces? (The exception handling is pretty slap-dash). I don't have a
> great deal of experience with these XML libraries other than the fairly
> basic use-cases.
> 
> I appreciate that the DOMSource serialization would be performance costly,
> but we already knew that...
> 
> Mehdi
> 
> On 30 July 2012 08:52, mehdi houshmand  wrote:
> 
> > Hi Jeremias,
> >
> > I'm sorry for the slow response, I will look at this when I get the chance
> > to do so and get back to you. I would like to come to some sort of
> > compromise on this, one where we're both happy with the acquisition of
> > resources. Failing that, at least come to an agreement where neither of us
> > are particularly happy but begrudgingly accept with a healthy amount of
> > resentment ;)
> >
> > Mehdi
> >
> >
> > On 26 July 2012 22:31, Jeremias Maerki  wrote:
> >
> >> (responded on fop-dev)
> >>
> >>
> >> Jeremias Maerki
> >>
> >>
> >> On 26.07.2012 20:17:17 mehdi houshmand wrote:
> >> > I appreciate that there are inconveniences, but if you're just looking
> >> for
> >> > backwards compatibility, the changes should be, for the most part,
> >> fairly
> >> > minor.
> >> >
> >> > I'm sorry we haven't been able to convince you of the benefits of the
> >> > changes, that's on me as the lead on this. I'm not sure really what
> >> else I
> >> > can do to convince you, if you have specific concerns that we could
> >> address
> >> > then I'd be happy to see if we can come to some sort of compromise. You
> >> > talk about a java.xml.transform.URIResolver interface, are there any
> >> other
> >> > things you'd like to see?
> >> >
> >> > On 26 July 2012 17:15, Jeremias Maerki  wrote:
> >> >
> >> > > That's not quite true. That worked perfectly before by setting your
> >> own
> >> > > JAXP URIResolver. You could even resolve a URI to a DOMSource (or
> >> > > SAXSource) containing an SVG image that you've dynamically built based
> >> > > on some data (think charts). With the new approach, you have to
> >> > > serialize that XML to a stream (buffered in memory or on disk) which
> >> > > costs performance. Not a very common use case, I know, but we're
> >> talking
> >> > > possibilities that are going away with the API changes.
> >> > >
> >> > > Previously, you could use Apache XML Commons Resolver for XML catalog
> >> > > functionality. Now you probably have to write an adapter from
> >> > > URIResolver to ResourceResolver (haven't had time to try that, yet). A
> >> > > convenience adapter is missing.
> >> > >
> >> > >
> >> > > Jeremias Maerki
> >> > >
> >> > >
> >> > > On 25.07.2012 22:25:52 Matthias Reischenbacher wrote:
> >> > > 
> >> > > > 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!
> >> > > 
> >> > >
> >> > > --

Re: Upgrade to fop trunk and URI resolving

[mehdi houshmand]

Jeremias,

I was looking into this, and it became abundantly clear that I don't really
know what you're trying to do with the java.xml.transform.URIResolver...
Would something like this be appropriate as an adapter between the two
interfaces? (The exception handling is pretty slap-dash). I don't have a
great deal of experience with these XML libraries other than the fairly
basic use-cases.

I appreciate that the DOMSource serialization would be performance costly,
but we already knew that...

Mehdi

On 30 July 2012 08:52, mehdi houshmand  wrote:

> Hi Jeremias,
>
> I'm sorry for the slow response, I will look at this when I get the chance
> to do so and get back to you. I would like to come to some sort of
> compromise on this, one where we're both happy with the acquisition of
> resources. Failing that, at least come to an agreement where neither of us
> are particularly happy but begrudgingly accept with a healthy amount of
> resentment ;)
>
> Mehdi
>
>
> On 26 July 2012 22:31, Jeremias Maerki  wrote:
>
>> (responded on fop-dev)
>>
>>
>> Jeremias Maerki
>>
>>
>> On 26.07.2012 20:17:17 mehdi houshmand wrote:
>> > I appreciate that there are inconveniences, but if you're just looking
>> for
>> > backwards compatibility, the changes should be, for the most part,
>> fairly
>> > minor.
>> >
>> > I'm sorry we haven't been able to convince you of the benefits of the
>> > changes, that's on me as the lead on this. I'm not sure really what
>> else I
>> > can do to convince you, if you have specific concerns that we could
>> address
>> > then I'd be happy to see if we can come to some sort of compromise. You
>> > talk about a java.xml.transform.URIResolver interface, are there any
>> other
>> > things you'd like to see?
>> >
>> > On 26 July 2012 17:15, Jeremias Maerki  wrote:
>> >
>> > > That's not quite true. That worked perfectly before by setting your
>> own
>> > > JAXP URIResolver. You could even resolve a URI to a DOMSource (or
>> > > SAXSource) containing an SVG image that you've dynamically built based
>> > > on some data (think charts). With the new approach, you have to
>> > > serialize that XML to a stream (buffered in memory or on disk) which
>> > > costs performance. Not a very common use case, I know, but we're
>> talking
>> > > possibilities that are going away with the API changes.
>> > >
>> > > Previously, you could use Apache XML Commons Resolver for XML catalog
>> > > functionality. Now you probably have to write an adapter from
>> > > URIResolver to ResourceResolver (haven't had time to try that, yet). A
>> > > convenience adapter is missing.
>> > >
>> > >
>> > > Jeremias Maerki
>> > >
>> > >
>> > > On 25.07.2012 22:25:52 Matthias Reischenbacher wrote:
>> > > 
>> > > > 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!
>> > > 
>> > >
>> > > -
>> > > To unsubscribe, e-mail: fop-users-unsubscr...@xmlgraphics.apache.org
>> > > For additional commands, e-mail:
>> 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
>>
>>
>


URIResolverAdapter.java
Description: Binary data

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

Re: Upgrade to fop trunk and URI resolving

[mehdi houshmand]

Hi Jeremias,

I'm sorry for the slow response, I will look at this when I get the chance
to do so and get back to you. I would like to come to some sort of
compromise on this, one where we're both happy with the acquisition of
resources. Failing that, at least come to an agreement where neither of us
are particularly happy but begrudgingly accept with a healthy amount of
resentment ;)

Mehdi

On 26 July 2012 22:31, Jeremias Maerki  wrote:

> (responded on fop-dev)
>
>
> Jeremias Maerki
>
>
> On 26.07.2012 20:17:17 mehdi houshmand wrote:
> > I appreciate that there are inconveniences, but if you're just looking
> for
> > backwards compatibility, the changes should be, for the most part, fairly
> > minor.
> >
> > I'm sorry we haven't been able to convince you of the benefits of the
> > changes, that's on me as the lead on this. I'm not sure really what else
> I
> > can do to convince you, if you have specific concerns that we could
> address
> > then I'd be happy to see if we can come to some sort of compromise. You
> > talk about a java.xml.transform.URIResolver interface, are there any
> other
> > things you'd like to see?
> >
> > On 26 July 2012 17:15, Jeremias Maerki  wrote:
> >
> > > That's not quite true. That worked perfectly before by setting your own
> > > JAXP URIResolver. You could even resolve a URI to a DOMSource (or
> > > SAXSource) containing an SVG image that you've dynamically built based
> > > on some data (think charts). With the new approach, you have to
> > > serialize that XML to a stream (buffered in memory or on disk) which
> > > costs performance. Not a very common use case, I know, but we're
> talking
> > > possibilities that are going away with the API changes.
> > >
> > > Previously, you could use Apache XML Commons Resolver for XML catalog
> > > functionality. Now you probably have to write an adapter from
> > > URIResolver to ResourceResolver (haven't had time to try that, yet). A
> > > convenience adapter is missing.
> > >
> > >
> > > Jeremias Maerki
> > >
> > >
> > > On 25.07.2012 22:25:52 Matthias Reischenbacher wrote:
> > > 
> > > > 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!
> > > 
> > >
> > > -
> > > To unsubscribe, e-mail: fop-users-unsubscr...@xmlgraphics.apache.org
> > > For additional commands, e-mail: 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
>
>

Re: Upgrade to fop trunk and URI resolving

[Jeremias Maerki]

(responded on fop-dev)


Jeremias Maerki


On 26.07.2012 20:17:17 mehdi houshmand wrote:
> I appreciate that there are inconveniences, but if you're just looking for
> backwards compatibility, the changes should be, for the most part, fairly
> minor.
> 
> I'm sorry we haven't been able to convince you of the benefits of the
> changes, that's on me as the lead on this. I'm not sure really what else I
> can do to convince you, if you have specific concerns that we could address
> then I'd be happy to see if we can come to some sort of compromise. You
> talk about a java.xml.transform.URIResolver interface, are there any other
> things you'd like to see?
> 
> On 26 July 2012 17:15, Jeremias Maerki  wrote:
> 
> > That's not quite true. That worked perfectly before by setting your own
> > JAXP URIResolver. You could even resolve a URI to a DOMSource (or
> > SAXSource) containing an SVG image that you've dynamically built based
> > on some data (think charts). With the new approach, you have to
> > serialize that XML to a stream (buffered in memory or on disk) which
> > costs performance. Not a very common use case, I know, but we're talking
> > possibilities that are going away with the API changes.
> >
> > Previously, you could use Apache XML Commons Resolver for XML catalog
> > functionality. Now you probably have to write an adapter from
> > URIResolver to ResourceResolver (haven't had time to try that, yet). A
> > convenience adapter is missing.
> >
> >
> > Jeremias Maerki
> >
> >
> > On 25.07.2012 22:25:52 Matthias Reischenbacher wrote:
> > 
> > > 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!
> > 
> >
> > -
> > To unsubscribe, e-mail: fop-users-unsubscr...@xmlgraphics.apache.org
> > For additional commands, e-mail: 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

Re: Upgrade to fop trunk and URI resolving

[mehdi houshmand]

I appreciate that there are inconveniences, but if you're just looking for
backwards compatibility, the changes should be, for the most part, fairly
minor.

I'm sorry we haven't been able to convince you of the benefits of the
changes, that's on me as the lead on this. I'm not sure really what else I
can do to convince you, if you have specific concerns that we could address
then I'd be happy to see if we can come to some sort of compromise. You
talk about a java.xml.transform.URIResolver interface, are there any other
things you'd like to see?

On 26 July 2012 17:15, Jeremias Maerki  wrote:

> That's not quite true. That worked perfectly before by setting your own
> JAXP URIResolver. You could even resolve a URI to a DOMSource (or
> SAXSource) containing an SVG image that you've dynamically built based
> on some data (think charts). With the new approach, you have to
> serialize that XML to a stream (buffered in memory or on disk) which
> costs performance. Not a very common use case, I know, but we're talking
> possibilities that are going away with the API changes.
>
> Previously, you could use Apache XML Commons Resolver for XML catalog
> functionality. Now you probably have to write an adapter from
> URIResolver to ResourceResolver (haven't had time to try that, yet). A
> convenience adapter is missing.
>
>
> Jeremias Maerki
>
>
> On 25.07.2012 22:25:52 Matthias Reischenbacher wrote:
> 
> > 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!
> 
>
> -
> To unsubscribe, e-mail: fop-users-unsubscr...@xmlgraphics.apache.org
> For additional commands, e-mail: fop-users-h...@xmlgraphics.apache.org
>
>

Re: Upgrade to fop trunk and URI resolving

[Jeremias Maerki]

That's not quite true. That worked perfectly before by setting your own
JAXP URIResolver. You could even resolve a URI to a DOMSource (or
SAXSource) containing an SVG image that you've dynamically built based
on some data (think charts). With the new approach, you have to
serialize that XML to a stream (buffered in memory or on disk) which
costs performance. Not a very common use case, I know, but we're talking
possibilities that are going away with the API changes.

Previously, you could use Apache XML Commons Resolver for XML catalog
functionality. Now you probably have to write an adapter from
URIResolver to ResourceResolver (haven't had time to try that, yet). A
convenience adapter is missing.


Jeremias Maerki


On 25.07.2012 22:25:52 Matthias Reischenbacher wrote:

> 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!


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

Re: Upgrade to fop trunk and URI resolving

[mehdi houshmand]

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  wrote:

> That was supposed to say "
>
> On 26 July 2012 08:46, mehdi houshmand  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 "" 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(> RESOLVER>);
>> builder.registerResourceResolverForSchema(, > 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 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: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 "" 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 i

Re: Upgrade to fop trunk and URI resolving

[mehdi houshmand]

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 "" 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();
builder.registerResourceResolverForSchema(, );
... // 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  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: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 "" 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 s

Re: Upgrade to fop trunk and URI resolving

[mehdi houshmand]

That was supposed to say " 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 "" 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( RESOLVER>);
> builder.registerResourceResolverForSchema(,  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 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: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 "" 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 immutabi

Re: Upgrade to fop trunk and URI resolving

[Matthias Reischenbacher]

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: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 "" 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
("" 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 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.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
[2] http://wiki.apache.org/xmlgraphics-fop/FopFactoryConfiguration

Hope that helps,

Mehdi


On 24 July 2012 00:01, Matthias Reischenbacher 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

How is HTTP authentication handled now?

Thanks for your help,
Matthias


--__--__-
To unsubscr

Re: Upgrade to fop trunk and URI resolving

[mehdi houshmand]

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 "" 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 ("" 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  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.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
> [2] http://wiki.apache.org/xmlgraphics-fop/FopFactoryConfiguration
>
> Hope that helps,
>
> Mehdi
>
>
> On 24 July 2012 00:01, Matthias Reischenbacher 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
>> How is HTTP authentication handled now?
>>
>> Thanks for your help,
>> Matthias
>>
>> --**--**-
>> To unsubscribe, e-mail: 
>> fop-users-unsubscribe@**xmlgraphics.apache.org
>> For additional commands, e-mail: 
>> fop-users-help@xmlgraphics.**apache.org
>>
>>
>

Re: Upgrade to fop trunk and URI resolving

[mehdi houshmand]

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.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
[2] http://wiki.apache.org/xmlgraphics-fop/FopFactoryConfiguration

Hope that helps,

Mehdi

On 24 July 2012 00:01, Matthias Reischenbacher  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
> How is HTTP authentication handled now?
>
> Thanks for your help,
> Matthias
>
> --**--**-
> To unsubscribe, e-mail: 
> fop-users-unsubscribe@**xmlgraphics.apache.org
> For additional commands, e-mail: 
> fop-users-help@xmlgraphics.**apache.org
>
>