Hi Jeremias, > "empty cell areas": When a table-cell is broken over two pages, > it generates two so-called reference areas. If the table-row that > it belongs to is broken over two pages but the full content of a > table-cell fit on the first page, FOP still has to create a (empty) > reference area for that table-cell on the second page. What you want > is to place an image in that empty area. My suggestion was to have a > facility to specify content that would be distributed into these empty > reference areas generated by the table-cell. The only tricky thing is > to let the height of that content influence the actual height calculation > for the table-row.
Since the content for this empty cells is already known, I could replace the empty reference area with an ordinary area, add a page-break before and fill in the content. If the area is generated before the height is calculated, it should influence the calculation just like any area would. Is that mostly correct? > Disclaimer: If I'm talking about possible solutions that doesn't mean I offer > to implement it. I'll just keep asking until I can implement it. Tomorrow I'll search for the empty reference areas... Regards, Georg Datterl ------ Kontakt ------ Georg Datterl Geneon media solutions gmbh Gutenstetter Straße 8a 90449 Nürnberg HRB Nürnberg: 17193 Geschäftsführer: Yong-Harry Steiert Tel.: 0911/36 78 88 - 26 Fax: 0911/36 78 88 - 20 www.geneon.de Weitere Mitglieder der Willmy MediaGroup: IRS Integrated Realization Services GmbH: www.irs-nbg.de Willmy PrintMedia GmbH: www.willmy.de Willmy Consult & Content GmbH: www.willmycc.de -----Ursprüngliche Nachricht----- Von: Jeremias Maerki [mailto:d...@jeremias-maerki.ch] Gesendet: Dienstag, 3. Februar 2009 17:15 An: fop-dev@xmlgraphics.apache.org Betreff: Re: AW: AW: AW: table cell duplication On 03.02.2009 16:38:05 Georg Datterl wrote: > Hi Jeremias, > > > Tough stuff for XSL-FO, catalogs. > > I see multiple problems: > > Seeing the problems ain't my problem either. Seeing the solutions is > tricky, :-) > > > Getting Block D at the bottom of the article. display-align="after" > >on the table-cell can help to a certain degree. Better: Setting > >block-progression -dimension.maximum="1.2em" on that cell should > >restrict that last row to one line, thus automatically placing it at > >the end of the table. However, FOP doesn't listen to that in this case, it > >appears. > > Been there. I'm hoping the problem will disappear, when the drawings are on > the second page. Hope is good. ;-) Usually, problems don't just disappear. > > Elongating borders down to the bottom of the available space is not > > possible at the moment. The whole min/opt/max functionality is quite > > restricted inside tables at the moment. You can specify > > block-progression-dimension.optimum="20cm" > > on the last table-row but unfortunately, our layout algorithm will > > then move the last row to the next page leaving the previous page > > underfilled. > > Been there too. This might be a requirement I can discuss away. > > > Thinking about a possible extension for repeating the cell content, > > I can't help but think that would not be the most flexible approach. > > Maybe an extension definining some content for empty cell areas (I > > don't mean empty table-cells here) would be better. Maybe someone > > doesn't want to repeat the content but actually add something > > different. I guess something like that would actually be implementable > > though it's not going to be easy. > > I liked the part "I guess something like that would actually be > implementable", but I did not quite understand the "empty cell areas" > part. "empty cell areas": When a table-cell is broken over two pages, it generates two so-called reference areas. If the table-row that it belongs to is broken over two pages but the full content of a table-cell fit on the first page, FOP still has to create a (empty) reference area for that table-cell on the second page. What you want is to place an image in that empty area. My suggestion was to have a facility to specify content that would be distributed into these empty reference areas generated by the table-cell. The only tricky thing is to let the height of that content influence the actual height calculation for the table-row. Disclaimer: If I'm talking about possible solutions that doesn't mean I offer to implement it. > > Also, how such a thing would interact with what Vincent is working on is > > another story. > > Hm, maybe Vincent will read this too and comment. I have no idea what he is > working on. Vincent is working on the page breaking code of FOP so it can do things it currently can't and so we can one day format documents of arbitrary size. > > Anyway, you've chosen a very tough problem. > > Tough problems choose me, hardly the other way round. > > > I'd try negotiating a relaxation of the requirements. > > Well, the requirement is: If there's table content on a page, the > associated drawings have to be there too. I guess, putting the > drawings in markers at the end of the page-sequence, referencing them > through the id of the DesignTable (the whole table-text-images-mess) > and then pulling them in once on each page if necessary will not work? You lost me. Sorry. Sounds adventurous anyway. <snip/> Jeremias Maerki
