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 ?xml version=1.0 standalone=no? fo:root xmlns:fo=http://www.w3.org/1999/XSL/Format; fo:layout-master-set fo:simple-page-master master-name=page page-height=10cm page-width=20cm margin=1cm fo:region-body/ /fo:simple-page-master /fo:layout-master-set fo:page-sequence master-reference=page fo:flow flow-name=xsl-region-body fo:table table-layout=fixed width=100% border-bottom=1pt solid black fo:table-column column-width=proportional-column-width(1)/ fo:table-column column-width=proportional-column-width(4)/ fo:table-body fo:table-cell fo:block keep-together.within-column=always fo:block538000/fo:block fo:block538001/fo:block /fo:block fo:block keep-together.within-column=always fo:blockPHOTO/fo:block fo:blockPHOTO/fo:block fo:blockPHOTO/fo:block fo:blockPHOTO/fo:block fo:blockPHOTO/fo:block /fo:block fo:table table-layout=fixed width=100% fo:table-header fo:table-cell fo:blockDRAWING/fo:block fo:blockDRAWING/fo:block fo:blockDRAWING/fo:block fo:blockDRAWING/fo:block fo:blockDRAWING/fo:block /fo:table-cell /fo:table-header fo:table-body fo:table-cell fo:block /fo:block fo:block /fo:block fo:block /fo:block fo:block /fo:block /fo:table-cell /fo:table-body /fo:table /fo:table-cell fo:table-cell fo:block font-weight=bold font-size=14pt fo:blockvoorlaskraag, PE100 SDR17/17.6/fo:block fo:blockgecombineerd dichtvlak: vlak en gegroefd/fo:block /fo:block fo:blockblah 1/fo:block fo:blockblah 2/fo:block fo:blockblah 3/fo:block fo:blockblah 4/fo:block fo:blockblah 5/fo:block fo:blockblah 6/fo:block fo:blockblah 7/fo:block fo:blockblah 8/fo:block fo:blockblah 9/fo:block fo:blockblah 10/fo:block fo:blockblah 11/fo:block fo:blockblah 12/fo:block fo:blockblah 13/fo:block fo:blockblah 14/fo:block fo:blockblah 15/fo:block fo:blockblah 16/fo:block fo:blockblah 17/fo:block fo:blockblah 18/fo:block fo:blockblah 19/fo:block
AW: table cell duplication
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:vhenneb...@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: 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.datt...@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:d...@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
AW: AW: AW: table cell duplication
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:x...@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.datt...@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:
