Re: Image overflow in FOP
Comments inline... On 05.11.2008 16:49:56 Sebastien wrote: Hi ! I'm using FOP 0.95 to generate a PDF from an XML document. I'm using XSL-FO to make the transformation and i'm having difficulties with images, especially making them to fit within page or to jump over the next one. All these images are SVG (within instream-foreign-object). The SVG is made of a large JPG background imported with svg:image and one or several svg:path or other basic shapes. The only constraint i want for the images is to fit the page width, and conserve aspect ratio. That i managed to achieve it. But the problem is that the image overflow the page height whenever there isn't enough room left at the end of the page. Here is a screenshot of what the problem is: http://img444.imageshack.us/my.php?image=imageoverflowbj6.png What i want to do is making FOP to do a page-break when the image can't fit into the page. I tried every combinations of keep constraints with no luck. I even tried to fix (or remove) the width and the height on the instream-foreign-object but FOP still doesn't want to jump to the next page :'( Here are some screenshots of the result: - without width http://img241.imageshack.us/my.php?image=imageoverflowwidthaz5.png - with smaller height (but still big enough to make the image bigger than the space left at the end of page) http://img504.imageshack.us/my.php?image=imageoverflowheightjs7.png We can see that the image is very well scaled up/down but i can't make FOP to break-page :'( Here is the incriminated piece of code (corresponding to the first screenshot) fo:block fo:instream-foreign-object width=100% content-width=scale-to-fit content-height=scale-to-fit svg:svg viewBox=519025 -6702573 5363 4051 height=2430px width=3219px svg:image height=4051 width=5363 y=-6702573 x=519025 xlink:href=file:///C:\bdd\docs\cartes\Scan25_Georef.jpg / [some paths, rects and texts] /svg:svg /fo:instream-foreign-object /fo:block I think that looks fine. It seems like one of the FOP known issue in the LayoutEngine, but i'm not quite sure because i use instream-foreign-object instead of external-graphic: http://xmlgraphics.apache.org/fop/knownissues.html#Layout+Engine (external-graphic don't shrink) No, that's the inability of FOP to shrink the image vertically if there's not enough room. That's not the same as the requirement you've stated above. My questions are: - is it possible to do what i want (having a page-break whenever it's needed) with instream-foreign-object (and with FOP) ? IMO, the instream-foreign-object part is already correct (first screenshot) but you've got the keeps wrong. - in case it's not, how could i calculate the space left at the end of page to decide whether i put a break-before=page on the corresponding block or not ? I saw some xpath in FOP testcases which tried to access some kind of internal properties like viewports etc... and i wondered whether it's possible for me to use these path to retrieve the remaining free space (and for my culture: are these paths part of the standard or specific to FOP ?) Nah, that's really FOP's job. Thanks in advance for your help, i'm stuck with this issue for days... Some ressources i found (and tried whenever it applied to my pb, but with no luck): http://www.nabble.com/Image-overflow-td5982795.html http://www.nabble.com/0.94-AND-0.95b-Images-to17627201.html#a17629647 For those who can understand french, here is a more detailed description of my problem: http://forum.hardware.fr/hfr/Programmation/XML-XSL/debordement-image-generer-sujet_118855_1.htm Here's what I would do: Enable the i-f-o behaviour as in your first screenshot, then remove all keeps. That should avoid the overflow. Then add keep-with-next or keep-together one step after the other. I'm pretty sure that you've just overdone the keeps. Please note that keep-*=always doesn't allow FOP to break the content appart. Looking at your layout you'd probably have a keep-with-next on the green bar to keep the bar with the following image. But it (probably) makes no sense to glue the green bars together. HTH good luck Jeremias Maerki - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Image overflow in FOP
Thank you for your answer ! Here's what I would do: Enable the i-f-o behaviour as in your first screenshot, then remove all keeps. That should avoid the overflow. Then add keep-with-next or keep-together one step after the other. I'm pretty sure that you've just overdone the keeps. Please note that keep-*=always doesn't allow FOP to break the content appart. I removed all the keeps in my entire document (i searched in the .fo output to be sure) but this didn't solve the problem unfortunately :( Actually, i even put some break-before (and even break-after for... the fun ?) everywhere in the encapsulating block hierarchy to force the page break ! But, these two didn't work either whereas they have worked in my previous test ! (i decided to drop this issue for a while because i thought i would be able to hack it easily later...) And that made me think of something i changed between my old test and now: 1) i ran into memory trouble before because the whole PDF was a unique page-sequence, so i decided to divide it into multiple page-sequences. It solved my memory problem and the style was more elegant. So i tried reverting theses changes having one single page-sequence again... no luck, still the overflow. 2) i needed a watermark on some of my pages (something like top secret stuff) and i chose an XML solution again by using SVG. It was more convenient because i was able to rotate the text and repeat it as much as i wanted. The issue was to render it as a watermark ie. all over the page and behind the content. I chose to use a block-container to encapsulate all the item, including the map (an item is Cheminée DALKIA for instance, it has several fields entitled in green boxes and eventually a map, as you can see in the screenshots) and i attached the watermark.svg as its background-image. This worked great, and was much more elegant than the other solutions i saw about watermarks. Same test as before: i removed the block-container and... it worked I then re-added the keep-with-next between the green boxes and the map and everything is now working very well. I just have to think about another solution for the watermark, which really is a less important issue than the one you helped me solve. Looking at your layout you'd probably have a keep-with-next on the green bar to keep the bar with the following image. But it (probably) makes no sense to glue the green bars together. That's correct ;) Well, thank you so much for you help. Even if the keeps were not the direct cause of the problem, i did abuse of them a little so i cleaned up my document. More important, it put me on the tracks to find out the solution. If you still have time to answer or some nice doc to point me to, I'd like to know how block-container works, why it screwed the page-breaking and how/when to use it. I think I didn't fully understand the W3C spec about it. Cheers ! - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Image overflow in FOP
On 05.11.2008 20:22:27 Sebastien wrote: Thank you for your answer ! Here's what I would do: Enable the i-f-o behaviour as in your first screenshot, then remove all keeps. That should avoid the overflow. Then add keep-with-next or keep-together one step after the other. I'm pretty sure that you've just overdone the keeps. Please note that keep-*=always doesn't allow FOP to break the content appart. I removed all the keeps in my entire document (i searched in the .fo output to be sure) but this didn't solve the problem unfortunately :( Actually, i even put some break-before (and even break-after for... the fun ?) everywhere in the encapsulating block hierarchy to force the page break ! But, these two didn't work either whereas they have worked in my previous test ! (i decided to drop this issue for a while because i thought i would be able to hack it easily later...) And that made me think of something i changed between my old test and now: 1) i ran into memory trouble before because the whole PDF was a unique page-sequence, so i decided to divide it into multiple page-sequences. It solved my memory problem and the style was more elegant. So i tried reverting theses changes having one single page-sequence again... no luck, still the overflow. 2) i needed a watermark on some of my pages (something like top secret stuff) and i chose an XML solution again by using SVG. It was more convenient because i was able to rotate the text and repeat it as much as i wanted. The issue was to render it as a watermark ie. all over the page and behind the content. I chose to use a block-container to encapsulate all the item, including the map (an item is Cheminée DALKIA for instance, it has several fields entitled in green boxes and eventually a map, as you can see in the screenshots) and i attached the watermark.svg as its background-image. This worked great, and was much more elegant than the other solutions i saw about watermarks. Same test as before: i removed the block-container and... it worked I then re-added the keep-with-next between the green boxes and the map and everything is now working very well. I just have to think about another solution for the watermark, which really is a less important issue than the one you helped me solve. Without seeing your FO to fully understand what you're doing it is a bit difficult to offer further suggestions. Usually, watermarks are best painted using block-containers (absolute-position=fixed) inside the region-before. Or you can use the background-image property on the region-body. Looking at your layout you'd probably have a keep-with-next on the green bar to keep the bar with the following image. But it (probably) makes no sense to glue the green bars together. That's correct ;) Well, thank you so much for you help. Even if the keeps were not the direct cause of the problem, i did abuse of them a little so i cleaned up my document. More important, it put me on the tracks to find out the solution. If you still have time to answer or some nice doc to point me to, I'd like to know how block-container works, why it screwed the page-breaking and how/when to use it. I think I didn't fully understand the W3C spec about it. Hey, even after all this years developing on FOP I can't say that I fully understand the XSL spec. But it's still (obviously) my main piece of reference. Jeremias Maerki - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Image overflow in FOP
Without seeing your FO to fully understand what you're doing it is a bit difficult to offer further suggestions. Usually, watermarks are best painted using block-containers (absolute-position=fixed) inside the region-before. Or you can use the background-image property on the region-body. I needed conditional watermarking, so i managed to work this out with the xsl-region-before. Thanks ;) - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Image overflow
Hi, This might have been answered, but could only find something on this in the archive of 2003. I believe in the 0.20.5 release images that where to wide were scaled down. Many of my the content that used to end up in a successful transformed PDF, now break on not being able to fit the text on a page. Is my assumption right that in the 0.20.5 release it worked as described here, and is this something that can be turned on in the latest release? Tx., Raphael
Re: Image overflow
Well, FOP 0.20.5 did all sorts of not quite conformant things with images. The new code is much more conformant to the spec. However, that doesn't mean there's no room for improvement. Currently, there's no way to scale down an image if there's not enough room to display it at full size (using .minimum/.optimum/.maximum on block-progression-dimension and inline-progression-dimension). XSL 1.1 introduces a few new possibilities in this area but again, these are not implemented, yet. What you can try is to use width=100% and content-width=scale-to-fit but this will always scale an image to take up the full width of the content area. Maybe you need to play a little with the properties available. If you have errors, you might also need to check if maybe some keep constraints cause the error and not the image itself. If you want more concrete help you'll need to post an example. On 25.08.2006 14:45:12 Raphael Parree wrote: This might have been answered, but could only find something on this in the archive of 2003. I believe in the 0.20.5 release images that where to wide were scaled down. Many of my the content that used to end up in a successful transformed PDF, now break on not being able to fit the text on a page. Is my assumption right that in the 0.20.5 release it worked as described here, and is this something that can be turned on in the latest release? Jeremias Maerki - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
