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: table cell duplication
Date Thu, 05 Feb 2009 06:50:50 GMT
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" <georg.datterl@geneon.de>
To: <fop-dev@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



Mime
View raw message