xmlgraphics-fop-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Georg Datterl" <georg.datt...@geneon.de>
Subject AW: AW: AW: AW: table cell duplication
Date Tue, 03 Feb 2009 16:25:34 GMT
 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:dev@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


Mime
View raw message