[no subject]
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 -- 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
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
AW: table cell duplication
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
Intermediate Format Performance: Necessary changes to IFPainter interface
I'm getting near to finishing my work on the new intermediate format. Logically, performance tests have to show whether the goals have been achieved. Generally, they have: - Rendering directly from the new intermediate is a lot faster than from the old area tree XML format. - The new intermediate files are also a lot smaller. - New output formats are much easier to implement than the old Renderers. However, the performance tests showed that the improvement for the PostScript output was rather small (and that's one of the most important formats in that context). The cause was my simplistic approach to glyph positioning (using the xshow operator). It causes at least one DecimalFormat.format() call per glyph even if the text has no kerning, letter/wordspacing or justification. So I had to revise my decision to simply carry a dx (from SVG) property with glyph offsets. Adding SVG's letter-spacing and word-spacing attributes made it possible to keep dx to null in many cases. Furthermore, a custom text painting operator in PostScript (similar to PDF's TJ) allowed much more compact PostScript code and brought the performance back in the region of PDF and AFP. So, IFPainter.drawText will get two new parameters letterSpacing and wordSpacing. I'm currently updating the rest of the output formats in a similar way (for example, PDF gets to use the Tc operator for letter-spacing). AFP will also profit from that. I'll commit when everything's working again. I'll also publish performance figures when this is done. Jeremias Maerki
Re: Intermediate Format Performance: Necessary changes to IFPainter interface
Oh, yes, I almost forgot: I'm removing the dy parameter for now since it's not supported anyway until we support different writing-modes. Doesn't make sense to keep that around until then. On 03.02.2009 11:10:03 Jeremias Maerki wrote: I'm getting near to finishing my work on the new intermediate format. Logically, performance tests have to show whether the goals have been achieved. Generally, they have: - Rendering directly from the new intermediate is a lot faster than from the old area tree XML format. - The new intermediate files are also a lot smaller. - New output formats are much easier to implement than the old Renderers. However, the performance tests showed that the improvement for the PostScript output was rather small (and that's one of the most important formats in that context). The cause was my simplistic approach to glyph positioning (using the xshow operator). It causes at least one DecimalFormat.format() call per glyph even if the text has no kerning, letter/wordspacing or justification. So I had to revise my decision to simply carry a dx (from SVG) property with glyph offsets. Adding SVG's letter-spacing and word-spacing attributes made it possible to keep dx to null in many cases. Furthermore, a custom text painting operator in PostScript (similar to PDF's TJ) allowed much more compact PostScript code and brought the performance back in the region of PDF and AFP. So, IFPainter.drawText will get two new parameters letterSpacing and wordSpacing. I'm currently updating the rest of the output formats in a similar way (for example, PDF gets to use the Tc operator for letter-spacing). AFP will also profit from that. I'll commit when everything's working again. I'll also publish performance figures when this is done. Jeremias Maerki Jeremias Maerki
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: 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:d...@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: Intermediate Format Performance: Necessary changes to IFPainter interface
Sounds exciting! Cool! On Tue, Feb 3, 2009 at 2:31 AM, Jeremias Maerki d...@jeremias-maerki.ch wrote: Oh, yes, I almost forgot: I'm removing the dy parameter for now since it's not supported anyway until we support different writing-modes. Doesn't make sense to keep that around until then. On 03.02.2009 11:10:03 Jeremias Maerki wrote: I'm getting near to finishing my work on the new intermediate format. Logically, performance tests have to show whether the goals have been achieved. Generally, they have: - Rendering directly from the new intermediate is a lot faster than from the old area tree XML format. - The new intermediate files are also a lot smaller. - New output formats are much easier to implement than the old Renderers. However, the performance tests showed that the improvement for the PostScript output was rather small (and that's one of the most important formats in that context). The cause was my simplistic approach to glyph positioning (using the xshow operator). It causes at least one DecimalFormat.format() call per glyph even if the text has no kerning, letter/wordspacing or justification. So I had to revise my decision to simply carry a dx (from SVG) property with glyph offsets. Adding SVG's letter-spacing and word-spacing attributes made it possible to keep dx to null in many cases. Furthermore, a custom text painting operator in PostScript (similar to PDF's TJ) allowed much more compact PostScript code and brought the performance back in the region of PDF and AFP. So, IFPainter.drawText will get two new parameters letterSpacing and wordSpacing. I'm currently updating the rest of the output formats in a similar way (for example, PDF gets to use the Tc operator for letter-spacing). AFP will also profit from that. I'll commit when everything's working again. I'll also publish performance figures when this is done. Jeremias Maerki Jeremias Maerki -- Regards, The Web Maestro -- the.webmaes...@gmail.com - http://ourlil.com/ My religion is simple. My religion is kindness. - HH The 14th Dalai Lama of Tibet
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 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
Re: AFP: Embedding fonts
Jeremias Maerki wrote: Hi Jeremias, snip/ Embedding the fonts is easy enough: you can just copy the files as new objects into the file-level resource group. IBM's AFP Workbench will still ignore the embedded fonts and replace them for system fonts but that's pretty irrelevant. Pixel-oriented AFP viewers and IPDS environments will be able to use the fonts. The ability to embed AFP Fonts would be a useful feature. As for the decision whether to embed the font or not, we could do it the same way we do it for the other output formats: the configuration specifies which fonts NOT to embed. But obviously, that would result in a behavioural change of the AFP output by default. So I'm asking around if everyone would be ok with that or if anyone sees a problem with it. I don't like the idea of changing the default behaviour as existing users may suddenly get different output when they upgrade their FOP version. Embedding fonts also increases the size of the AFP Output File. AFP Users tend to be pretty fussy about the size of AFP Output as the key benefit of AFP over other formats is its concise nature. Can we not just add a new attribute embed to the font definition that defaults to false? That is my preference. Another change I'd probably do in this context is to create Coded Fonts in the resource group. Basically, this just groups the font and the codepage together in one object that can be referenced my Map Coded Font. I learned this is best practice, too. Doing this should also make it easier to implement double-byte functionality once that pops up on the priority list. Support for Coded Fonts would be great too. Most AFP Software supports Coded Fonts, but currently FOP can't deal with them and insists on specifying the code page and character set separately. Thanks, Chris
Re: AFP: Embedding fonts
On 03.02.2009 16:43:12 Chris Bowditch wrote: Jeremias Maerki wrote: Hi Jeremias, snip/ Embedding the fonts is easy enough: you can just copy the files as new objects into the file-level resource group. IBM's AFP Workbench will still ignore the embedded fonts and replace them for system fonts but that's pretty irrelevant. Pixel-oriented AFP viewers and IPDS environments will be able to use the fonts. The ability to embed AFP Fonts would be a useful feature. As for the decision whether to embed the font or not, we could do it the same way we do it for the other output formats: the configuration specifies which fonts NOT to embed. But obviously, that would result in a behavioural change of the AFP output by default. So I'm asking around if everyone would be ok with that or if anyone sees a problem with it. I don't like the idea of changing the default behaviour as existing users may suddenly get different output when they upgrade their FOP version. Embedding fonts also increases the size of the AFP Output File. AFP Users tend to be pretty fussy about the size of AFP Output as the key benefit of AFP over other formats is its concise nature. Can we not just add a new attribute embed to the font definition that defaults to false? That is my preference. Understood. Can do. But I think it's also problematic if some output formats default to true while others default to false. Source for confusion especially for new users. If it's about file size, we better see to it that we can compress images in AFP. That will easily make up for the larger files because of embedded fonts. ;-) Anyway, I don't really expect different output if the fonts are embedded. You'd rather do away with the possible problem that FOP did the layout with a different font than is actually used on the production machine. There are pros and cons, that's all. Another change I'd probably do in this context is to create Coded Fonts in the resource group. Basically, this just groups the font and the codepage together in one object that can be referenced my Map Coded Font. I learned this is best practice, too. Doing this should also make it easier to implement double-byte functionality once that pops up on the priority list. Support for Coded Fonts would be great too. Most AFP Software supports Coded Fonts, but currently FOP can't deal with them and insists on specifying the code page and character set separately. Thanks, Chris Jeremias Maerki
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
AW: AW: AW: AW: table cell duplication
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:d...@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,
Re: AW: AW: AW: AW: table cell duplication
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:d...@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
AFP: Embedding fonts
Right now, the AFP output just loads the configured bitmap and outline fonts for metrics but it requires that the same fonts are correctly set up on the target AFP viewer or printer. Even just registering the fonts for FOP is tricky enough. Doing that for every target environment is sometimes even trickier. The easiest way to simplify the whole thing would be to embed the AFP fonts like we do for PDF and PostScript. That way you can be sure that you have the fonts available on the target environment and you're working exactly with the fonts that you did the layout with. This also seems to be best practice as I learned from an AFP expert a few days ago. Embedding the fonts is easy enough: you can just copy the files as new objects into the file-level resource group. IBM's AFP Workbench will still ignore the embedded fonts and replace them for system fonts but that's pretty irrelevant. Pixel-oriented AFP viewers and IPDS environments will be able to use the fonts. As for the decision whether to embed the font or not, we could do it the same way we do it for the other output formats: the configuration specifies which fonts NOT to embed. But obviously, that would result in a behavioural change of the AFP output by default. So I'm asking around if everyone would be ok with that or if anyone sees a problem with it. Another change I'd probably do in this context is to create Coded Fonts in the resource group. Basically, this just groups the font and the codepage together in one object that can be referenced my Map Coded Font. I learned this is best practice, too. Doing this should also make it easier to implement double-byte functionality once that pops up on the priority list. Jeremias Maerki
Re: Intermediate Format Performance: Necessary changes to IFPainter interface
Sounds impressive. On Tue, Feb 03, 2009 at 07:35:03AM -0800, The Web Maestro wrote: Sounds exciting! Cool! On Tue, Feb 3, 2009 at 2:31 AM, Jeremias Maerki d...@jeremias-maerki.ch wrote: Oh, yes, I almost forgot: I'm removing the dy parameter for now since it's not supported anyway until we support different writing-modes. Doesn't make sense to keep that around until then. On 03.02.2009 11:10:03 Jeremias Maerki wrote: I'm getting near to finishing my work on the new intermediate format. Logically, performance tests have to show whether the goals have been achieved. Generally, they have: - Rendering directly from the new intermediate is a lot faster than from the old area tree XML format. - The new intermediate files are also a lot smaller. - New output formats are much easier to implement than the old Renderers. However, the performance tests showed that the improvement for the PostScript output was rather small (and that's one of the most important formats in that context). The cause was my simplistic approach to glyph positioning (using the xshow operator). It causes at least one DecimalFormat.format() call per glyph even if the text has no kerning, letter/wordspacing or justification. So I had to revise my decision to simply carry a dx (from SVG) property with glyph offsets. Adding SVG's letter-spacing and word-spacing attributes made it possible to keep dx to null in many cases. Furthermore, a custom text painting operator in PostScript (similar to PDF's TJ) allowed much more compact PostScript code and brought the performance back in the region of PDF and AFP. So, IFPainter.drawText will get two new parameters letterSpacing and wordSpacing. I'm currently updating the rest of the output formats in a similar way (for example, PDF gets to use the Tc operator for letter-spacing). AFP will also profit from that. I'll commit when everything's working again. I'll also publish performance figures when this is done. Simon -- Simon Pepping home page: http://www.leverkruid.eu
