Re: keep-together Problems
Hi, sorry. I got the problem solved while creating the test-case. Just some stupid mismatch in xsl-template-names :-( Best regards, Alex OK, I'll create a small case, asap. By the way: I am using a trunk version from about 2 weeks ago, because 0.94 would not recognize my font paths. Hi Inside a table:row with attribute keep-together.within- page=auto, we have cells containing blocks with attributes: linefeed-treatment=preserve and white-space-collapse=false, but these are ignored. Can you post a small FO, so that we can try ourselves? Last I checked, the only known issue was with keep-together=always. This indeed overrides linefeed-treatment=preserve, because of the implicit keep-together.within-line. Other than that, with FOP 0.94 you shouldn't run into trouble... Cheers Andreas - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: fop-users- [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] __ Alexander Lohse • Entwicklungsleitung Projektmanagement Tel +49 38374 752 11 • Fax +49 38374 752 23 http://www.humantouch.de Human Touch Medienproduktion GmbH Am See 1 • 17440 Klein Jasedow • Deutschland Geschäftsführung: Lara Mallien, Nele Hybsier, Alexander Lohse, Johannes Heimrath (Senior) Handelsregister Stralsund • HRB 4192 • USt-IdNr. DE128367684 - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
keep-together Problems
Hi, I have following problem: Inside a table:row with attribute keep-together.within-page=auto, we have cells containing blocks with attributes: linefeed- treatment=preserve and white-space-collapse=false, but these are ignored. In other words: I want the content inside the blocks to keep the linefeeds as they are in XML, but I do not want the table-row to split up across pages. How can I achieve this? Thank you in advance. Regards, Alex __ Alexander Lohse • Entwicklungsleitung Projektmanagement Tel +49 38374 752 11 • Fax +49 38374 752 23 http://www.humantouch.de Human Touch Medienproduktion GmbH Am See 1 • 17440 Klein Jasedow • Deutschland Geschäftsführung: Lara Mallien, Nele Hybsier, Alexander Lohse, Johannes Heimrath (Senior) Handelsregister Stralsund • HRB 4192 • USt-IdNr. DE128367684 - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: keep-together Problems
Alexander Lohse wrote: Hi, I have following problem: Inside a table:row with attribute keep-together.within-page=auto, we have cells containing blocks with attributes: linefeed- treatment=preserve and white-space-collapse=false, but these are ignored. By ignored do you mean the table-row is still split up across pages? I think you should use keep-together.within-page=always instead of auto snip/ Chris - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: keep-together Problems
OK, I'll create a small case, asap. By the way: I am using a trunk version from about 2 weeks ago, because 0.94 would not recognize my font paths. Hi Inside a table:row with attribute keep-together.within- page=auto, we have cells containing blocks with attributes: linefeed-treatment=preserve and white-space-collapse=false, but these are ignored. Can you post a small FO, so that we can try ourselves? Last I checked, the only known issue was with keep-together=always. This indeed overrides linefeed-treatment=preserve, because of the implicit keep-together.within-line. Other than that, with FOP 0.94 you shouldn't run into trouble... Cheers Andreas - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: keep-together Problems
No ... sorry, I mean linefeeds inside xml-text-content are ignored. Am 05.03.2008 um 22:10 schrieb Chris Bowditch: Alexander Lohse wrote: Hi, I have following problem: Inside a table:row with attribute keep-together.within- page=auto, we have cells containing blocks with attributes: linefeed- treatment=preserve and white-space-collapse=false, but these are ignored. By ignored do you mean the table-row is still split up across pages? I think you should use keep-together.within-page=always instead of auto snip/ Chris - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] __ Alexander Lohse • Entwicklungsleitung Projektmanagement Tel +49 38374 752 11 • Fax +49 38374 752 23 http://www.humantouch.de Human Touch Medienproduktion GmbH Am See 1 • 17440 Klein Jasedow • Deutschland Geschäftsführung: Lara Mallien, Nele Hybsier, Alexander Lohse, Johannes Heimrath (Senior) Handelsregister Stralsund • HRB 4192 • USt-IdNr. DE128367684 - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Keep-Together Problems
Ross, it's good to know that there are people out there with the right spirit. Normally, I'd be glad to take this on. There are a few things in this special case that we have to look at, though. Implementing the integer values for keep-* properties is not going to be a fix. We'll have to do some investigation first. The integer values (full integer value range) have to be mapped somehow into the penalty system (integer values from 0 to 999) used by FOP's layout engine. That may make it necessary to find out which set of values are really used in the whole document. Smells like two-pass processing. I'm not sure, yet. Note that, to my knowlegde, only AntennaHouse has implemented this feature, yet, and only in their latest version. It's not something simple. I guess one thing we can do arather quickly is to amend the keep implementation to better satisfy the specification text in XSL 1.0, 4.8 which seems to allow relaxing the keep conditions even if it's set to always. At the moment, we're using the INFINITE penalty value for always which doesn't allow the layout engine to break to blocks apart. If we lower that value to 900 (or 999 or so) like I've done for a special rule in the table layout manager, we can probably better match the 0.20.5 behaviour, although there might be side-effects which I cannot predict right now. Before we continue here I'd like to get at least one second opinion by one of my fellow fop-devs. If there's someone who would like to dive in here in my place, he/she's welcome to do so as I have more than enough on my plate. A rather large backlog and ApacheCon this month would delay this anyway. I don't think I can do the scaled-down version (second paragraph above) before mid-July. On 02.06.2006 18:47:28 Ross Nicholls wrote: Dear Jeremias (or other), As this is a commercial project I can offer to employ you (or one of the developers) to cure this problem that we are experiencing. If you are willing, please let me know your personal charge for completing the fix. I can be contacted directly at [EMAIL PROTECTED] if preferable. Regards, Ross - Original Message - From: Jeremias Maerki [EMAIL PROTECTED] To: fop-users@xmlgraphics.apache.org Sent: Monday, May 29, 2006 1:11 PM Subject: Re: Keep-Together Problems At the moment, only always is supported for keep values which causes the effect you've seen. So far nobody has implemented any refinements that will cause certain keep conditions to be relaxed if necessary as defined in XSL 1.0, chapter 4.8. The solution would be to implement finer rules to specify penalty values during element list generation. Currently, there's no work-around other than not to use keeps. On 23.05.2006 16:01:41 Ross Nicholls wrote: Hi there, I am currently working on migrating our large XSL-FO project from FOP v0.20.5 to the new v0.92. Everything is going great and the new version offers some excellent advantages over the older one, I'm really looking forward to the SVG and MIF (or similar) output implementations when they materialise. I do have one problem however: The new version (0.92 beta) doesn't seem to cope too well with Keep-Together on table-rows (or any block level area for that matter) when the contents are actually larger than a page. In the old version (0.20.5) I was able to put a keep-together on the table-row which meant that each product from the catalogue would not be split over 2 pages UNLESS the product was too big to fit on a page of it's own. But with the new version, when it encounters such a product (table-row, that contains multiple blocks and image content) it crashes with an error - something like Content does not fit in available area after 50 attempts, gave up to avoid an infinite loop. Unfortunately, this means that we can't go ahead with the upgrade to the new version of FOP and take advantage of all the wonderful improvements - as the keep-togethers are very important. Does anyone have any idea how I can get round this problem, or is there a fix available or possible??? I appreciate any help or comments anyone can give. Kindest Regards, Ross Jeremias Maerki - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Keep-Together Problems
Dear Jeremias (or other), As this is a commercial project I can offer to employ you (or one of the developers) to cure this problem that we are experiencing. If you are willing, please let me know your personal charge for completing the fix. I can be contacted directly at [EMAIL PROTECTED] if preferable. Regards, Ross - Original Message - From: Jeremias Maerki [EMAIL PROTECTED] To: fop-users@xmlgraphics.apache.org Sent: Monday, May 29, 2006 1:11 PM Subject: Re: Keep-Together Problems At the moment, only always is supported for keep values which causes the effect you've seen. So far nobody has implemented any refinements that will cause certain keep conditions to be relaxed if necessary as defined in XSL 1.0, chapter 4.8. The solution would be to implement finer rules to specify penalty values during element list generation. Currently, there's no work-around other than not to use keeps. On 23.05.2006 16:01:41 Ross Nicholls wrote: Hi there, I am currently working on migrating our large XSL-FO project from FOP v0.20.5 to the new v0.92. Everything is going great and the new version offers some excellent advantages over the older one, I'm really looking forward to the SVG and MIF (or similar) output implementations when they materialise. I do have one problem however: The new version (0.92 beta) doesn't seem to cope too well with Keep-Together on table-rows (or any block level area for that matter) when the contents are actually larger than a page. In the old version (0.20.5) I was able to put a keep-together on the table-row which meant that each product from the catalogue would not be split over 2 pages UNLESS the product was too big to fit on a page of it's own. But with the new version, when it encounters such a product (table-row, that contains multiple blocks and image content) it crashes with an error - something like Content does not fit in available area after 50 attempts, gave up to avoid an infinite loop. Unfortunately, this means that we can't go ahead with the upgrade to the new version of FOP and take advantage of all the wonderful improvements - as the keep-togethers are very important. Does anyone have any idea how I can get round this problem, or is there a fix available or possible??? I appreciate any help or comments anyone can give. Kindest Regards, Ross Jeremias Maerki - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Keep-Together Problems
At the moment, only always is supported for keep values which causes the effect you've seen. So far nobody has implemented any refinements that will cause certain keep conditions to be relaxed if necessary as defined in XSL 1.0, chapter 4.8. The solution would be to implement finer rules to specify penalty values during element list generation. Currently, there's no work-around other than not to use keeps. On 23.05.2006 16:01:41 Ross Nicholls wrote: Hi there, I am currently working on migrating our large XSL-FO project from FOP v0.20.5 to the new v0.92. Everything is going great and the new version offers some excellent advantages over the older one, I'm really looking forward to the SVG and MIF (or similar) output implementations when they materialise. I do have one problem however: The new version (0.92 beta) doesn't seem to cope too well with Keep-Together on table-rows (or any block level area for that matter) when the contents are actually larger than a page. In the old version (0.20.5) I was able to put a keep-together on the table-row which meant that each product from the catalogue would not be split over 2 pages UNLESS the product was too big to fit on a page of it's own. But with the new version, when it encounters such a product (table-row, that contains multiple blocks and image content) it crashes with an error - something like Content does not fit in available area after 50 attempts, gave up to avoid an infinite loop. Unfortunately, this means that we can't go ahead with the upgrade to the new version of FOP and take advantage of all the wonderful improvements - as the keep-togethers are very important. Does anyone have any idea how I can get round this problem, or is there a fix available or possible??? I appreciate any help or comments anyone can give. Kindest Regards, Ross Jeremias Maerki - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Keep-Together Problems
Hi there, I am currently working on migrating our large XSL-FO project from FOP v0.20.5 to the new v0.92. Everything is going great and the new version offers some excellent advantages over the older one, I'm really looking forward to the SVG and MIF (or similar)output implementations when they materialise. I do have one problem however: The new version (0.92 beta) doesn't seem to cope too well with Keep-Together on table-rows (or any block level area for that matter) when the contents are actually larger than a page. In the old version (0.20.5) I was able to put a keep-together on the table-row which meant that each "product" from the catalogue would not be split over 2 pages UNLESS the product was too big to fit on a page of it's own. But with the new version, when it encounters such a product (table-row, that contains multiple blocks and image content) it crashes with an error - something like "Content does not fit in available area after 50 attempts, gave up to avoid an infinite loop". Unfortunately, this means that we can't go ahead with the upgrade to the new version of FOP and take advantage of all the wonderful improvements - as the keep-togethers are very important. Does anyone have any idea how I can get round this problem, or is there a fix available or possible??? I appreciate any help or comments anyone can give. Kindest Regards, Ross
