On 22/06/10 15:06, Jeremias Maerki wrote: > I remember from back when I was deep in the table layout code that > elastic space in tables is extremely tricky (with our layout approach) > which is why it's not available in tables today. In your case, it would > actually be relatively easy since there is only one column, but it's > still not available. So what you've done between tables is about as much > as you can get right now.
Thanks very much for spending the time to look at and respond to this, and for confirming I'm not missing the obvious. > The only work-around that I can come up with right now is not to put the > ads in a table and generate only the initial header for each section. > And then to try some post-processing magic with the area tree XML. Ugly > but I don't see any other possibility right now. I'll have to experiment with that. It'll potentially be a way to solve the other issue I have (how to insert "house ads" where holes in columns are too big to neatly justify out) without requiring user intervention. Thanks for the pointer. It's a pity that it'll mean I can't use just standard XSL-FO, but the spec doesn't appear to be up to this particular task yet. If this doesn't work, given that you said adding support for expanding one-column tables would be "relatively easy", is there any chance you'd be willing to quote on that as a contract job to extend fop? Assuming that it'd be within the standard to support elastic spacing in table cells, of course. If it's the difference between being able to use XSL-FO + fop, and having to buy an insanely overpriced classified pagination/booking/automation "system", paying for some small enhancements to fop would be a no brainer. Georg Datterl mentioned markers as a possibility if I could use page-break rather than column-break as the repetition boundary. Unfortunately I can't, but this makes me wonder if there's any concept of a more granular "break marker" that could be used at column boundaries too. (I suspect I'm displaying my relative ignorance of FO here). It seems like a pity that markers were limited to page-level operation in the spec, especially since the 1.1 spec extends and generalizes regions in ways that'd make "region markers" very useful. It looks like FO also has "table markers" ... which would be great, except that tables already solve the issue markers are needed for but introduce issues with vertical space justification. Argh. The other thing I've been wondering about is the possibility of conditional content. Much as space-before can be conditional, so that it doesn't display if the block is the first element after a break, I wonder about having conditional block display where an object only gets laid out if it's the first item after a break, or *not* the first item after a break. That'd be incredibly handy, and I suspect not just for my weird little use case. Leaders would be an obvious use for this. This isn't something you can really do at the XSLT stage (unlike most variable/conditional content) since it requires layout awareness. I can't find any consideration of this in the FO spec except as applies to markers, which I'm rather surprised by. Of course, even with a solution to this issue I'll still probably need to use the area tree output to determine where I need to insert "house ads" to consume any column whitespace holes that are too large to just spread out between objects in the column. There doesn't seem to be even the remotest concept in FO of marker-like content that's triggered by "amount of free space in the region", which is what I'd need to do this automatically. Alas, I don't think I'll have any better luck doing this with TeX(ML) either, nor generating InDesign documents as XML, so FOP + area trees might be my best bet. Thanks for the pointer, I'll have a play. Meanwhile I'd be interested in your thoughts on the above, with a potential view to paid extension work on FOP - if you see anything that might be worthwhile and if I can swing the cost with my boss. -- Craig Ringer --------------------------------------------------------------------- To unsubscribe, e-mail: fop-users-unsubscr...@xmlgraphics.apache.org For additional commands, e-mail: fop-users-h...@xmlgraphics.apache.org
