You are viewing a plain text version of this content. The canonical link for it is here.
Posted to fop-dev@xmlgraphics.apache.org by Jeremias Maerki <de...@jeremias-maerki.ch> on 2009/02/03 09:46:18 UTC
Re: table cell duplication
Smells table-marker-ish to me. A block-container in the table-header
(retrieved through retrieve-table-marker) could display the second "CCC"
in the right position.
The only problem: someone has to implement table markers first. But I
think this would be better than to introduce yet another extension.
On 03.02.2009 09:21:39 Georg Datterl wrote:
> Hello everybody,
>
> for my project I need one final feature: Table cell duplication. Imagine a Table like this:
>
> TH1 TH2
> AAA EEE
> BBB EEE
> CCC EEE
> EEE
> EEE
> EEE
> DDD EEE
>
> Two columns, four rows, Block E spans all four rows, A aligns with the top of the table, B and C follow, D aligns with the bottom of the table. A, B, C and D always keep-together. Now, if Block E breaks to a new page, it usually looks like this:
>
> AAA EEE
> BBB EEE
> CCC EEE
> EEE
> ---break---
> TH1 TH2
> EEE
> EEE
> DDD EEE
>
> What I want is:
>
> AAA EEE
> BBB EEE
> CCC EEE
> EEE
> ---break---
> TH1 TH2
> CCC EEE
> EEE
> DDD EEE
>
> Basically, the complete block C should be repeated on the next page, if the table breaks. As far as I was able to see, this is not supported by the specification, so I assume, I have to write my own extension. I'd be grateful for any ideas how to solve that in a supported way or any comments on where and how to implement the extension.
>
> Regards,
>
> Georg Datterl
Jeremias Maerki
Re: AW: AW: AW: AW: table cell duplication
Posted by Jeremias Maerki <de...@jeremias-maerki.ch>.
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
AW: AW: AW: AW: table cell duplication
Posted by Georg Datterl <ge...@geneon.de>.
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
Re: AW: AW: AW: table cell duplication
Posted by Jeremias Maerki <de...@jeremias-maerki.ch>.
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
Re: table cell duplication
Posted by Vincent Hennebert <vh...@gmail.com>.
Hi Georg,
Georg Datterl wrote:
> Hi Jost, hi Vincent
>
> I could use a combination of your ideas. If I just put the drawings in a table header and fill the table body with empty cells, I still have to keep in mind that a new page means, the header is reprinted, therefore the body moves down. Since I don't know, over how many pages the table spans, I don't know for how many headers I should include in my calculation.
> I could generate the document with only one set of drawings. Then I would know how many pages a table spans and I would know, how long the table body should be. Only if the last part of the table is shorter than the drawings, the bottom line of the complete DesignTable would move down and the page spanning of further DesignTables can be influenced. So worst case I would have to generate the whole page-sequence once for each DesignTable. Performance nightmare, but it should give the desired result.
This would have to be tested, but I think you can estimate the height of
the blank content accurately enough. If you have the height of content E
and the height of pages, then you can compute the maximum number of
pages over which the DesignTable can be spread. So the maximum number of
times drawing C would appear, and substract that number of times from
the height of the blank content. That should allow you to avoid
re-generating the whole page-sequence once for every DesignTable.
By making a post-process based on the informations of the intermediate
format, you could probably manage to get the borders of the tables
inside content E extended until the bottom of the DesignTable.
> Vincent, could I just insert multiple copies of the drawings block and
> add a break-before="page" all but the first block?
Yes, if you use the post-process approach, then you don’t need to worry
about using a table. In spite of the multiple processings problem that
you identified above, this approach may be better if you can’t
accurately estimate the height of content E.
> Georg Datterl
<snip/>
HTH,
Vincent
AW: AW: AW: table cell duplication
Posted by Georg Datterl <ge...@geneon.de>.
Hi Jost, hi Vincent
I could use a combination of your ideas. If I just put the drawings in a table header and fill the table body with empty cells, I still have to keep in mind that a new page means, the header is reprinted, therefore the body moves down. Since I don't know, over how many pages the table spans, I don't know for how many headers I should include in my calculation.
I could generate the document with only one set of drawings. Then I would know how many pages a table spans and I would know, how long the table body should be. Only if the last part of the table is shorter than the drawings, the bottom line of the complete DesignTable would move down and the page spanning of further DesignTables can be influenced. So worst case I would have to generate the whole page-sequence once for each DesignTable. Performance nightmare, but it should give the desired result.
Vincent, could I just insert multiple copies of the drawings block and add a break-before="page" all but the first block?
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: Jost Klopfstein [mailto:xml@axostech.com]
Gesendet: Mittwoch, 4. Februar 2009 19:04
An: fop-dev@xmlgraphics.apache.org
Betreff: Re: AW: AW: table cell duplication
Hi Georg,
I worked in the past on a few industrial catalogs and solved similar problems with 2 or multi-pass rendering, depending on the complexity of your requirements.
Someone would have to implement a pinpoint extension. You would then intercept the pinpointsin the new intermediate format and adjust the input.
HTH
Cheers, Jost
----- Original Message -----
From: "Georg Datterl" <ge...@geneon.de>
To: <fo...@xmlgraphics.apache.org>
Sent: Tuesday, February 03, 2009 7:38 AM
Subject: AW: AW: AW: table cell duplication
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.
> 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.
> 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.
> 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?
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 16:06
An: fop-dev@xmlgraphics.apache.org
Betreff: Re: AW: AW: table cell duplication
Tough stuff for XSL-FO, catalogs.
I see multiple problems:
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.
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.
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.
On the other hand, the example you posted also smells a bit like side-floats, although that would
not address the repetition of the image C.
Also, how such a thing would interact with what Vincent is working on is another story.
Anyway, you've chosen a very tough problem. I'd try negotiating a relaxation of the requirements.
;-) Or maybe someone else has another idea here.
On 03.02.2009 12:19:25 Georg Datterl wrote:
> Hi Jeremias,
>
> Yes, I include a picture of my table (created with iText, except for
> the red stuff). The left colum contains numbers (Block A), photos
> (Block B), drawings (Block C) and finally another number (Block D).
> The right column contains headlines, text, tables, various stuff. As
> you can see on the second page, last table, Block A aligns with Block
> E, Block D is on the bottom line of the table, not necessarily aligned
> to anything in
>Block E.
>
> The text "PE universeel fittingen" is in the header area and can be
> ignored.
>
> Maybe my table structure is not that smart, but it seemed the easiest
> way to keep block D on the bottom. More or less... If you know a way
> to elongate the table columns down to the table baseline regardless of
> empty rows, that would be most welcome, too.
>
> 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 11:29
> An: fop-dev@xmlgraphics.apache.org
> Betreff: Re: AW: table cell duplication
>
> Do you have a real-world example of what you're trying to build? I mean, your earlier picture
> suggests that most of the EEE content belongs to the CCC section. What is DDD? A sum at the end?
> I don't get how this fits together on a logical level. Maybe you could generate the DDD in a
> similar way as I suggested for the repeating CCC: via a block-container (from the table-footer or
> from the EEE cell). Anyway, this seems way beyond what XSL-FO provides. An extension would be
> very specific to your use case here I suspect.
>
> And no, the table marker would not be invoked in the picture you provided if it is defined by the
> CCC cell.
>
> On 03.02.2009 10:29:27 Georg Datterl wrote:
> > Hi Jeremias,
> >
> > I had similar thoughts, but:
> >
> > At the moment, the table would (contrary to my previous example) look like:
> >
> > AAA EEE
> > BBB EEE
> > CCC EEE
> > DDD EEE
> > ---break---
> > TH1 TH2
> > EEE
> > EEE
> > EEE
> >
> > Cell D is on the first page, even with vertical alignment it is at best printed on the bottom
> > of the first page, but never on the second page. Would the table marker get invoked in this
> > case?
> >
> > Regards,
> >
> > Georg Datterl
>
>
>
> Jeremias Maerki
>
Jeremias Maerki
Re: AW: AW: table cell duplication
Posted by Jost Klopfstein <xm...@axostech.com>.
Hi Georg,
I worked in the past on a few industrial catalogs and solved similar problems with 2 or multi-pass
rendering, depending on the complexity of your requirements.
Someone would have to implement a pinpoint extension. You would then intercept the pinpointsin the
new intermediate format and adjust the input.
HTH
Cheers, Jost
----- Original Message -----
From: "Georg Datterl" <ge...@geneon.de>
To: <fo...@xmlgraphics.apache.org>
Sent: Tuesday, February 03, 2009 7:38 AM
Subject: AW: AW: AW: table cell duplication
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.
> 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.
> 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.
> 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?
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 16:06
An: fop-dev@xmlgraphics.apache.org
Betreff: Re: AW: AW: table cell duplication
Tough stuff for XSL-FO, catalogs.
I see multiple problems:
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.
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.
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.
On the other hand, the example you posted also smells a bit like side-floats, although that would
not address the repetition of the image C.
Also, how such a thing would interact with what Vincent is working on is another story.
Anyway, you've chosen a very tough problem. I'd try negotiating a relaxation of the requirements.
;-) Or maybe someone else has another idea here.
On 03.02.2009 12:19:25 Georg Datterl wrote:
> Hi Jeremias,
>
> Yes, I include a picture of my table (created with iText, except for
> the red stuff). The left colum contains numbers (Block A), photos
> (Block B), drawings (Block C) and finally another number (Block D).
> The right column contains headlines, text, tables, various stuff. As
> you can see on the second page, last table, Block A aligns with Block
> E, Block D is on the bottom line of the table, not necessarily aligned
> to anything in
>Block E.
>
> The text "PE universeel fittingen" is in the header area and can be
> ignored.
>
> Maybe my table structure is not that smart, but it seemed the easiest
> way to keep block D on the bottom. More or less... If you know a way
> to elongate the table columns down to the table baseline regardless of
> empty rows, that would be most welcome, too.
>
> 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 11:29
> An: fop-dev@xmlgraphics.apache.org
> Betreff: Re: AW: table cell duplication
>
> Do you have a real-world example of what you're trying to build? I mean, your earlier picture
> suggests that most of the EEE content belongs to the CCC section. What is DDD? A sum at the end?
> I don't get how this fits together on a logical level. Maybe you could generate the DDD in a
> similar way as I suggested for the repeating CCC: via a block-container (from the table-footer or
> from the EEE cell). Anyway, this seems way beyond what XSL-FO provides. An extension would be
> very specific to your use case here I suspect.
>
> And no, the table marker would not be invoked in the picture you provided if it is defined by the
> CCC cell.
>
> On 03.02.2009 10:29:27 Georg Datterl wrote:
> > Hi Jeremias,
> >
> > I had similar thoughts, but:
> >
> > At the moment, the table would (contrary to my previous example) look like:
> >
> > AAA EEE
> > BBB EEE
> > CCC EEE
> > DDD EEE
> > ---break---
> > TH1 TH2
> > EEE
> > EEE
> > EEE
> >
> > Cell D is on the first page, even with vertical alignment it is at best printed on the bottom
> > of the first page, but never on the second page. Would the table marker get invoked in this
> > case?
> >
> > Regards,
> >
> > Georg Datterl
>
>
>
> Jeremias Maerki
>
Jeremias Maerki
AW: AW: AW: table cell duplication
Posted by Georg Datterl <ge...@geneon.de>.
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.
> 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.
> 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.
> 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?
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 16:06
An: fop-dev@xmlgraphics.apache.org
Betreff: Re: AW: AW: table cell duplication
Tough stuff for XSL-FO, catalogs.
I see multiple problems:
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.
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.
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.
On the other hand, the example you posted also smells a bit like side-floats, although that would not address the repetition of the image C.
Also, how such a thing would interact with what Vincent is working on is another story.
Anyway, you've chosen a very tough problem. I'd try negotiating a relaxation of the requirements. ;-) Or maybe someone else has another idea here.
On 03.02.2009 12:19:25 Georg Datterl wrote:
> Hi Jeremias,
>
> Yes, I include a picture of my table (created with iText, except for
> the red stuff). The left colum contains numbers (Block A), photos
> (Block B), drawings (Block C) and finally another number (Block D).
> The right column contains headlines, text, tables, various stuff. As
> you can see on the second page, last table, Block A aligns with Block
> E, Block D is on the bottom line of the table, not necessarily aligned
> to anything in
>Block E.
>
> The text "PE universeel fittingen" is in the header area and can be
> ignored.
>
> Maybe my table structure is not that smart, but it seemed the easiest
> way to keep block D on the bottom. More or less... If you know a way
> to elongate the table columns down to the table baseline regardless of
> empty rows, that would be most welcome, too.
>
> 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 11:29
> An: fop-dev@xmlgraphics.apache.org
> Betreff: Re: AW: table cell duplication
>
> Do you have a real-world example of what you're trying to build? I mean, your earlier picture suggests that most of the EEE content belongs to the CCC section. What is DDD? A sum at the end? I don't get how this fits together on a logical level. Maybe you could generate the DDD in a similar way as I suggested for the repeating CCC: via a block-container (from the table-footer or from the EEE cell). Anyway, this seems way beyond what XSL-FO provides. An extension would be very specific to your use case here I suspect.
>
> And no, the table marker would not be invoked in the picture you provided if it is defined by the CCC cell.
>
> On 03.02.2009 10:29:27 Georg Datterl wrote:
> > Hi Jeremias,
> >
> > I had similar thoughts, but:
> >
> > At the moment, the table would (contrary to my previous example) look like:
> >
> > AAA EEE
> > BBB EEE
> > CCC EEE
> > DDD EEE
> > ---break---
> > TH1 TH2
> > EEE
> > EEE
> > EEE
> >
> > Cell D is on the first page, even with vertical alignment it is at best printed on the bottom of the first page, but never on the second page. Would the table marker get invoked in this case?
> >
> > Regards,
> >
> > Georg Datterl
>
>
>
> Jeremias Maerki
>
Jeremias Maerki
Re: AW: AW: table cell duplication
Posted by Jeremias Maerki <de...@jeremias-maerki.ch>.
Tough stuff for XSL-FO, catalogs.
I see multiple problems:
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.
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.
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.
On the other hand, the example you posted also smells a bit like
side-floats, although that would not address the repetition of the image
C.
Also, how such a thing would interact with what Vincent is working on is
another story.
Anyway, you've chosen a very tough problem. I'd try negotiating a
relaxation of the requirements. ;-) Or maybe someone else has another
idea here.
On 03.02.2009 12:19:25 Georg Datterl wrote:
> Hi Jeremias,
>
> Yes, I include a picture of my table (created with iText, except for
> the red stuff). The left colum contains numbers (Block A), photos (Block B),
> drawings (Block C) and finally another number (Block D). The right
> column contains headlines, text, tables, various stuff. As you can see
> on the second page, last table, Block A aligns with Block E, Block D is
> on the bottom line of the table, not necessarily aligned to anything in
>Block E.
>
> The text "PE universeel fittingen" is in the header area and can be
> ignored.
>
> Maybe my table structure is not that smart, but it seemed the easiest
> way to keep block D on the bottom. More or less... If you know a way to
> elongate the table columns down to the table baseline regardless of
> empty rows, that would be most welcome, too.
>
> 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 11:29
> An: fop-dev@xmlgraphics.apache.org
> Betreff: Re: AW: table cell duplication
>
> Do you have a real-world example of what you're trying to build? I mean, your earlier picture suggests that most of the EEE content belongs to the CCC section. What is DDD? A sum at the end? I don't get how this fits together on a logical level. Maybe you could generate the DDD in a similar way as I suggested for the repeating CCC: via a block-container (from the table-footer or from the EEE cell). Anyway, this seems way beyond what XSL-FO provides. An extension would be very specific to your use case here I suspect.
>
> And no, the table marker would not be invoked in the picture you provided if it is defined by the CCC cell.
>
> On 03.02.2009 10:29:27 Georg Datterl wrote:
> > Hi Jeremias,
> >
> > I had similar thoughts, but:
> >
> > At the moment, the table would (contrary to my previous example) look like:
> >
> > AAA EEE
> > BBB EEE
> > CCC EEE
> > DDD EEE
> > ---break---
> > TH1 TH2
> > EEE
> > EEE
> > EEE
> >
> > Cell D is on the first page, even with vertical alignment it is at best printed on the bottom of the first page, but never on the second page. Would the table marker get invoked in this case?
> >
> > Regards,
> >
> > Georg Datterl
>
>
>
> Jeremias Maerki
>
Jeremias Maerki
AW: table cell duplication
Posted by Georg Datterl <ge...@geneon.de>.
Hi Vincent,
Thanks for your idea. Calculating the height of the left column is no problem, I can get the height of blocks A-D. Block E is tricky. The table height can be calculated, but the text part may contain lists or flow text. I guess I will have to count line breaks, calculate linelengths and guess how many breaks hyphenation will generate. Not very reliable, I'm afraid, but it sounds doable.
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: Vincent Hennebert [mailto:vhennebert@gmail.com]
Gesendet: Mittwoch, 4. Februar 2009 11:04
An: fop-dev@xmlgraphics.apache.org
Betreff: Re: table cell duplication
Hi Georg,
Georg Datterl a écrit :
> Hi Jeremias,
>
> Yes, I include a picture of my table (created with iText, except for the red stuff). The left colum contains numbers (Block A), photos (Block B), drawings (Block C) and finally another number (Block D). The right column contains headlines, text, tables, various stuff. As you can see on the second page, last table, Block A aligns with Block E, Block D is on the bottom line of the table, not necessarily aligned to anything in Block E.
Please have a look at the FO file attached. That's the most accurate approach I could find. That requires a bit of pre-processing, and knowing the heights of the images, but since your content seems to be even you might be happy with it. Plus it's implementable straight away, without any modification to FOP.
I can think of two FO constructs to make content repeat on pages:
markers or table headers/footers. Markers are not really an option here (even supposing that table markers are implemented), since the repeated content should be mixed with the table body, and have an influence on its height.
Remains table header. The idea is to put the drawing in a header and fill the body with blank content such that the height of the table matches the height of content E. In the sample FO I used blocks containing non-breaking spaces. The whole challenge is to determine how many such blocks should be put. In your case you seem to always have the same content: 2 title lines, a few list items, then tables with a certain amount of entries. If the title content and list items are short enough to never be broken over lines, then you can easily estimate the height of content E, substract the heights of A, B and C, which gives you the amount of blank blocks to put.
However, I can't think of any way to extend the borders to the final horizontal line.
Block D is relatively easy to achieve: just put a block with negative margin after the whole table.
> The text "PE universeel fittingen" is in the header area and can be ignored.
>
> Maybe my table structure is not that smart, but it seemed the easiest way to keep block D on the bottom. More or less... If you know a way to elongate the table columns down to the table baseline regardless of empty rows, that would be most welcome, too.
>
> Regards,
>
> Georg Datterl
HTH,
Vincent
Re: table cell duplication
Posted by Vincent Hennebert <vh...@gmail.com>.
Hi Georg,
Georg Datterl a écrit :
> Hi Jeremias,
>
> Yes, I include a picture of my table (created with iText, except for the red stuff). The left colum contains numbers (Block A), photos (Block B), drawings (Block C) and finally another number (Block D). The right column contains headlines, text, tables, various stuff. As you can see on the second page, last table, Block A aligns with Block E, Block D is on the bottom line of the table, not necessarily aligned to anything in Block E.
Please have a look at the FO file attached. That’s the most accurate
approach I could find. That requires a bit of pre-processing, and
knowing the heights of the images, but since your content seems to be
even you might be happy with it. Plus it’s implementable straight away,
without any modification to FOP.
I can think of two FO constructs to make content repeat on pages:
markers or table headers/footers. Markers are not really an option here
(even supposing that table markers are implemented), since the repeated
content should be mixed with the table body, and have an influence on
its height.
Remains table header. The idea is to put the drawing in a header and
fill the body with blank content such that the height of the table
matches the height of content E. In the sample FO I used blocks
containing non-breaking spaces. The whole challenge is to determine how
many such blocks should be put. In your case you seem to always have the
same content: 2 title lines, a few list items, then tables with
a certain amount of entries. If the title content and list items are
short enough to never be broken over lines, then you can easily estimate
the height of content E, substract the heights of A, B and C, which
gives you the amount of blank blocks to put.
However, I can’t think of any way to extend the borders to the final
horizontal line.
Block D is relatively easy to achieve: just put a block with negative
margin after the whole table.
> The text "PE universeel fittingen" is in the header area and can be ignored.
>
> Maybe my table structure is not that smart, but it seemed the easiest way to keep block D on the bottom. More or less... If you know a way to elongate the table columns down to the table baseline regardless of empty rows, that would be most welcome, too.
>
> Regards,
>
> Georg Datterl
HTH,
Vincent
AW: AW: table cell duplication
Posted by Georg Datterl <ge...@geneon.de>.
Hi Jeremias,
Yes, I include a picture of my table (created with iText, except for the red stuff). The left colum contains numbers (Block A), photos (Block B), drawings (Block C) and finally another number (Block D). The right column contains headlines, text, tables, various stuff. As you can see on the second page, last table, Block A aligns with Block E, Block D is on the bottom line of the table, not necessarily aligned to anything in Block E.
The text "PE universeel fittingen" is in the header area and can be ignored.
Maybe my table structure is not that smart, but it seemed the easiest way to keep block D on the bottom. More or less... If you know a way to elongate the table columns down to the table baseline regardless of empty rows, that would be most welcome, too.
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 11:29
An: fop-dev@xmlgraphics.apache.org
Betreff: Re: AW: table cell duplication
Do you have a real-world example of what you're trying to build? I mean, your earlier picture suggests that most of the EEE content belongs to the CCC section. What is DDD? A sum at the end? I don't get how this fits together on a logical level. Maybe you could generate the DDD in a similar way as I suggested for the repeating CCC: via a block-container (from the table-footer or from the EEE cell). Anyway, this seems way beyond what XSL-FO provides. An extension would be very specific to your use case here I suspect.
And no, the table marker would not be invoked in the picture you provided if it is defined by the CCC cell.
On 03.02.2009 10:29:27 Georg Datterl wrote:
> Hi Jeremias,
>
> I had similar thoughts, but:
>
> At the moment, the table would (contrary to my previous example) look like:
>
> AAA EEE
> BBB EEE
> CCC EEE
> DDD EEE
> ---break---
> TH1 TH2
> EEE
> EEE
> EEE
>
> Cell D is on the first page, even with vertical alignment it is at best printed on the bottom of the first page, but never on the second page. Would the table marker get invoked in this case?
>
> Regards,
>
> Georg Datterl
Jeremias Maerki
Re: AW: table cell duplication
Posted by Jeremias Maerki <de...@jeremias-maerki.ch>.
Do you have a real-world example of what you're trying to build? I mean,
your earlier picture suggests that most of the EEE content belongs to
the CCC section. What is DDD? A sum at the end? I don't get how this
fits together on a logical level. Maybe you could generate the DDD in a
similar way as I suggested for the repeating CCC: via a block-container
(from the table-footer or from the EEE cell). Anyway, this seems way
beyond what XSL-FO provides. An extension would be very specific to your
use case here I suspect.
And no, the table marker would not be invoked in the picture you
provided if it is defined by the CCC cell.
On 03.02.2009 10:29:27 Georg Datterl wrote:
> Hi Jeremias,
>
> I had similar thoughts, but:
>
> At the moment, the table would (contrary to my previous example) look like:
>
> AAA EEE
> BBB EEE
> CCC EEE
> DDD EEE
> ---break---
> TH1 TH2
> EEE
> EEE
> EEE
>
> Cell D is on the first page, even with vertical alignment it is at best printed on the bottom of the first page, but never on the second page. Would the table marker get invoked in this case?
>
> Regards,
>
> Georg Datterl
Jeremias Maerki
AW: table cell duplication
Posted by Georg Datterl <ge...@geneon.de>.
Hi Jeremias,
I had similar thoughts, but:
At the moment, the table would (contrary to my previous example) look like:
AAA EEE
BBB EEE
CCC EEE
DDD EEE
---break---
TH1 TH2
EEE
EEE
EEE
Cell D is on the first page, even with vertical alignment it is at best printed on the bottom of the first page, but never on the second page. Would the table marker get invoked in this case?
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