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

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

> > 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.


Jeremias Maerki

Reply via email to