Re: Upgrade to fop trunk and URI resolving
That was supposed to say RESOLVER FOR GIVEN SCHEMA. On 26 July 2012 08:46, mehdi houshmand 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.atwrote: 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 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?
Re: Upgrade to fop trunk and URI resolving
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 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 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
Re: How to set hyphen base url in config file
Hi,
You have to set it in config file with the hyphenation-base element (see [1]).
Then from the command line script, you should use the -c option (see [{2])
[1] http://xmlgraphics.apache.org/fop/1.0/configuration.html#general-elements
[2] http://xmlgraphics.apache.org/fop/1.0/running.html#fop-script
2012/7/25 Rob Sargent rsarg...@xmission.com:
Such that I can enable hyphenation when running fop (1.0) from the command
line. We're currently calling factory.setHyphenBaseUrl() in our programme
and I need the same when running tests from the command line
Thanks,
rjs
--
pascal
-
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
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 wrote: That was supposed to say RESOLVER FOR GIVEN SCHEMA. On 26 July 2012 08:46, mehdi houshmand 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.atwrote: 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 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
Re: Upgrade to fop trunk and URI resolving
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: snip/ 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! snip/ - 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
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 d...@jeremias-maerki.ch 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: snip/ 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! snip/ - 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
(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 d...@jeremias-maerki.ch 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: snip/ 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! snip/ - 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
