xmlgraphics-fop-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Jeremias Maerki <...@jeremias-maerki.ch>
Subject Re: AW: AW: AW: table cell duplication
Date Tue, 03 Feb 2009 16:14:59 GMT
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


Mime
View raw message