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
