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: AW: table cell duplication
Date Tue, 03 Feb 2009 16:48:26 GMT
On 03.02.2009 17:25:34 Georg Datterl wrote:
>  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?

It's not nearly that simple, unfortunately. Area generation happens
after height calculations. The most important part before that would be
to create the right Knuth element lists. That means creating special
Position objects when the content of the table-cell has been contributed
to the merged element list. Implementing this requires intimate
knowledge of our Knuth-based approach at layout and about the way the
element lists are merged inside the table layout manager. Note: I've
only scratched the surface here.

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

You're welcome to try. Just a word of warning: if you're serious about
that, you're in for a steep learning curve. I don't want to scare you
away. It would be great to have additional people around with the
necessary knowledge but this is definitely not something you're going to
implement in a week or even a month if you have to learn about the
layout engine first.

There's another problem, too. That's what I meant when mentioning
Vincent's work. If someone implemented an (non-trivial) extension now,
Vincent would have to try to reimplement it in his new approach. So
every extension we add is a heavy burden on the person trying to improve
later. And even just implementing the various features of XSL-FO is a
damn difficult task.

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




Jeremias Maerki


Mime
View raw message