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: <[email protected]> > 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]
