On 23/06/10 17:55, Georg Datterl wrote: > Table markers are not yet implemented and most likely wouldn't help > you anyway. The problem with ordinary marker is, the header is not > aware of the columns, since they are defined in the flow. So markers > in the header can't find, like, the first marker in a column. That's > why I suggested a seven-column table to fake the seven columns of the > flow.
I see. So the only way they could ever make sense was if, rather than columns, the document used named regions (as per XSL-FO 1.1) with a flow map to control flow into them. Then static content could be aware of what "column" it was coming from. That's a whole lot more complicated, though, and doesn't seem to be even considered in the spec. Most use cases would probably be better handled by smarter conditional content (as per the "future work" section of the spec) anyway. > Another idea I just had: What would happen, if you defined one > pagewidth as 1/7th of a real page, spread the page header and footer > over seven pages and just PRINT seven pages on one sheet of paper? > (or combine them later, if possible?) Yuck! That's fantastically ugly, and would actually work pretty decently. It also makes house ad placement easier because it's way easier to manipulate the size of a region on a page master rather than try to block out a piece of one column. It's ... gruesome ... but an awfully good idea. It wouldn't work if I was trying to generate press-ready pages, since I'd need to include a proper folio with page numbers etc, but in my case all I'm trying to do is generate the "content" PDFs that'll then be placed onto InDesign pages, possibly with other content, for layout and print. If I did need to assemble the paginated document into a single PDF for final output, I imagine some area-tree post processing could probably manage that, and failing that there's always PDF imposition. I've been staring at the area tree output and going increasingly cross-eyed thinking about how I can possibly manipulate it to achieve what I need, so your suggestion gives me a great workaround and buys me some time to figure out the area tree approach. Thanks! -- Craig Ringer --------------------------------------------------------------------- To unsubscribe, e-mail: fop-users-unsubscr...@xmlgraphics.apache.org For additional commands, e-mail: fop-users-h...@xmlgraphics.apache.org
