Re: Upgrade to fop trunk and URI resolving
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 d...@jeremias-maerki.ch 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 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
Re: Upgrade to fop trunk and URI resolving
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 med1...@gmail.com 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 d...@jeremias-maerki.ch 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 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 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
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 med1...@gmail.com 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 d...@jeremias-maerki.ch 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 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:
Force Page Break in fo:list-item
Hi all, I am using FOP 1.0 and 0.95. How can I force a Page Break in a fo:list-item? I've tried break-before which drops the content and keep-with-next on the list-block or list-item. Neither work. Thx -- View this message in context: http://apache-fop.1065347.n5.nabble.com/Force-Page-Break-in-fo-list-item-tp36554.html Sent from the FOP - Users mailing list archive at Nabble.com. - To unsubscribe, e-mail: fop-users-unsubscr...@xmlgraphics.apache.org For additional commands, e-mail: fop-users-h...@xmlgraphics.apache.org
Re: Force Page Break in fo:list-item
You probably need to upgrade to trunk. I know this works in trunk: list-block list-item . /list-item list-item break-before=page list-item-labellabel/list-item-label list-item-bodybody/list-item-body /list-item /list-block and it also works if you put the break inside the body. if you are stuck with 1.0 and it doesn't work you can always create two lists and put the break in between. On 7/30/12 11:50 PM, Bonekrusher wrote: Hi all, I am using FOP 1.0 and 0.95. How can I force a Page Break in a fo:list-item? I've tried break-before which drops the content and keep-with-next on the list-block or list-item. Neither work. Thx -- View this message in context: http://apache-fop.1065347.n5.nabble.com/Force-Page-Break-in-fo-list-item-tp36554.html Sent from the FOP - Users mailing list archive at Nabble.com. - 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
