Re: FOP 1.1rc1 strange tablecell content behaviour with text-align=right
Well Pascal, I made some more tests starting from your simple file. It is interesting to note that the behaviour is different, depending on the fact that the content is pure text or is mixed (text plus fo:page-number-citation ref-id=ID01/ element). I'm opening the bug as requested. I will add all the 4 tests I runned. Thanks again. G. 2012/8/30 Giuseppe Briotti g.brio...@gmail.com: OK, Pascal, I'll open the bug and perform some test with your suggestions as soon as possible (I have just EDGE connection, veeeryyy slwww) :-) 2012/8/29 Pascal Sancho psancho@gmail.com: Hi, Hmm, my bad, I looked to the wrong direction: the overflow property and the clipping. Looking it closer, and removing all things from FO that are not concerned with this issue, I understand now: as you said, text-align right used in conjunction with page-number-citation reveals that something is wrong when the i-p-d of the generated inline area is wider than available space. See attached FO, with minimal text case. I found some bug files that can be related to, but not sure: https://issues.apache.org/bugzilla/show_bug.cgi?id=39034 https://issues.apache.org/bugzilla/show_bug.cgi?id=43739 https://issues.apache.org/bugzilla/show_bug.cgi?id=36395 So, Giusseppe you should file a new bug entry, test case is now clear enough. That said, I see 2 workarounds that prevent overflow: - either remove keep-together - or give more space to the content @GA: I can affirm now that is not a regression FOP 0.95 or 1.0: keep-together is not taken into account, so the bug is not yet revealed FOP 1.1rc1: revelation! 2012/8/28 Giuseppe Briotti g.brio...@gmail.com: Hi Glen, hi Pascal! Thanks for yours replays. I don't know if this is a problem related to cell width or table width, probably you're right, but it seems to me that the width is ok to contains such text. Anyway I checked the table width and I add more space to the rightmost cell, then I performed some more tests. All tests are performed with FOP 1.1rc1 and I added some background color and removed overflow=hidden to show what happens. The page-width is set to 209.9 mm (A4). The region body is set with left and right margin to 6.5cm, thus the available space is 8cm. For instance, the first table has these sizes (computed the widths of 1st and 3rd columns, the width of 2nd column is computed by difference): 2.5mm + 64.69417mm + 12.80583mm = 80mm The table width is always 8cm, and the column widths are computed accordingly. The rightmost column cells are with text-align=right. The C_Comm-1 r25.info.1.1.wref document is obtained from the original FO and the C_Comm-1 r25.info.1.1.noref document is obtained from the same FO with elements fo:page-number-citation removed. Note that due to the hidden removed, now the left and right border of the main block are visibile: this is in case a 2 columns layout is required, to obtain the middle vertical line to separate the two columns. Probably I missed something, but this seems to me related to the computed area for page number citation. 2012/8/28 Pascal Sancho psancho@gmail.com: Hi Glen, Not exactly: FOP 0.95: table content is shrunk to fit in clip space (wrong) FOP 1.0: table content is shifted to the wrong side of the clip limit (wrong) FOP 1.1RC1: table content is at the right place, but that reveals a new bug: hidden part is copyable 2012/8/28 Glenn Adams gl...@skynav.com: On Mon, Aug 27, 2012 at 10:10 PM, Pascal Sancho psancho@gmail.com wrote: There is something wrong in your XSL-FO: the table containing TOC is wider than available i-p-d, and the corresponding region-body has its property overflow set to hidden. So, the PDF shows what is expected visually. But... hidden text can be copied, and IMHO this is not the correct behaviour; the [1] FO 1.1 REC says: (hidden) indicates that the content is clipped (...); users will not have access to clipped content. So, I suggest you to fill in a bug entry on Bugzilla, providing both XSL-FO and PDF output. This is reproducible against both FOP 1.1RC1 and FOP trunk. Is this a regression in 1.1rc1, or was it present in 1.0? -- -- pascal - To unsubscribe, e-mail: fop-users-unsubscr...@xmlgraphics.apache.org For additional commands, e-mail: fop-users-h...@xmlgraphics.apache.org -- Giuseppe Briotti g.brio...@gmail.com Alme Sol, curru nitido diem qui promis et celas aliusque et idem nasceris, possis nihil urbe Roma visere maius. (Orazio) -- Giuseppe Briotti g.brio...@gmail.com Alme Sol, curru nitido diem qui promis et celas aliusque et idem nasceris, possis nihil urbe Roma visere maius. (Orazio) - To unsubscribe, e-mail: fop-users-unsubscr...@xmlgraphics.apache.org For additional commands, e-mail:
Re: FOP 1.1rc1 strange tablecell content behaviour with text-align=right
OK, Pascal, I'll open the bug and perform some test with your suggestions as soon as possible (I have just EDGE connection, veeeryyy slwww) :-) 2012/8/29 Pascal Sancho psancho@gmail.com: Hi, Hmm, my bad, I looked to the wrong direction: the overflow property and the clipping. Looking it closer, and removing all things from FO that are not concerned with this issue, I understand now: as you said, text-align right used in conjunction with page-number-citation reveals that something is wrong when the i-p-d of the generated inline area is wider than available space. See attached FO, with minimal text case. I found some bug files that can be related to, but not sure: https://issues.apache.org/bugzilla/show_bug.cgi?id=39034 https://issues.apache.org/bugzilla/show_bug.cgi?id=43739 https://issues.apache.org/bugzilla/show_bug.cgi?id=36395 So, Giusseppe you should file a new bug entry, test case is now clear enough. That said, I see 2 workarounds that prevent overflow: - either remove keep-together - or give more space to the content @GA: I can affirm now that is not a regression FOP 0.95 or 1.0: keep-together is not taken into account, so the bug is not yet revealed FOP 1.1rc1: revelation! 2012/8/28 Giuseppe Briotti g.brio...@gmail.com: Hi Glen, hi Pascal! Thanks for yours replays. I don't know if this is a problem related to cell width or table width, probably you're right, but it seems to me that the width is ok to contains such text. Anyway I checked the table width and I add more space to the rightmost cell, then I performed some more tests. All tests are performed with FOP 1.1rc1 and I added some background color and removed overflow=hidden to show what happens. The page-width is set to 209.9 mm (A4). The region body is set with left and right margin to 6.5cm, thus the available space is 8cm. For instance, the first table has these sizes (computed the widths of 1st and 3rd columns, the width of 2nd column is computed by difference): 2.5mm + 64.69417mm + 12.80583mm = 80mm The table width is always 8cm, and the column widths are computed accordingly. The rightmost column cells are with text-align=right. The C_Comm-1 r25.info.1.1.wref document is obtained from the original FO and the C_Comm-1 r25.info.1.1.noref document is obtained from the same FO with elements fo:page-number-citation removed. Note that due to the hidden removed, now the left and right border of the main block are visibile: this is in case a 2 columns layout is required, to obtain the middle vertical line to separate the two columns. Probably I missed something, but this seems to me related to the computed area for page number citation. 2012/8/28 Pascal Sancho psancho@gmail.com: Hi Glen, Not exactly: FOP 0.95: table content is shrunk to fit in clip space (wrong) FOP 1.0: table content is shifted to the wrong side of the clip limit (wrong) FOP 1.1RC1: table content is at the right place, but that reveals a new bug: hidden part is copyable 2012/8/28 Glenn Adams gl...@skynav.com: On Mon, Aug 27, 2012 at 10:10 PM, Pascal Sancho psancho@gmail.com wrote: There is something wrong in your XSL-FO: the table containing TOC is wider than available i-p-d, and the corresponding region-body has its property overflow set to hidden. So, the PDF shows what is expected visually. But... hidden text can be copied, and IMHO this is not the correct behaviour; the [1] FO 1.1 REC says: (hidden) indicates that the content is clipped (...); users will not have access to clipped content. So, I suggest you to fill in a bug entry on Bugzilla, providing both XSL-FO and PDF output. This is reproducible against both FOP 1.1RC1 and FOP trunk. Is this a regression in 1.1rc1, or was it present in 1.0? -- -- pascal - To unsubscribe, e-mail: fop-users-unsubscr...@xmlgraphics.apache.org For additional commands, e-mail: fop-users-h...@xmlgraphics.apache.org -- Giuseppe Briotti g.brio...@gmail.com Alme Sol, curru nitido diem qui promis et celas aliusque et idem nasceris, possis nihil urbe Roma visere maius. (Orazio) - To unsubscribe, e-mail: fop-users-unsubscr...@xmlgraphics.apache.org For additional commands, e-mail: fop-users-h...@xmlgraphics.apache.org
Re: FOP 1.1rc1 strange tablecell content behaviour with text-align=right
Hi, Hmm, my bad, I looked to the wrong direction: the overflow property and the clipping. Looking it closer, and removing all things from FO that are not concerned with this issue, I understand now: as you said, text-align right used in conjunction with page-number-citation reveals that something is wrong when the i-p-d of the generated inline area is wider than available space. See attached FO, with minimal text case. I found some bug files that can be related to, but not sure: https://issues.apache.org/bugzilla/show_bug.cgi?id=39034 https://issues.apache.org/bugzilla/show_bug.cgi?id=43739 https://issues.apache.org/bugzilla/show_bug.cgi?id=36395 So, Giusseppe you should file a new bug entry, test case is now clear enough. That said, I see 2 workarounds that prevent overflow: - either remove keep-together - or give more space to the content @GA: I can affirm now that is not a regression FOP 0.95 or 1.0: keep-together is not taken into account, so the bug is not yet revealed FOP 1.1rc1: revelation! 2012/8/28 Giuseppe Briotti g.brio...@gmail.com: Hi Glen, hi Pascal! Thanks for yours replays. I don't know if this is a problem related to cell width or table width, probably you're right, but it seems to me that the width is ok to contains such text. Anyway I checked the table width and I add more space to the rightmost cell, then I performed some more tests. All tests are performed with FOP 1.1rc1 and I added some background color and removed overflow=hidden to show what happens. The page-width is set to 209.9 mm (A4). The region body is set with left and right margin to 6.5cm, thus the available space is 8cm. For instance, the first table has these sizes (computed the widths of 1st and 3rd columns, the width of 2nd column is computed by difference): 2.5mm + 64.69417mm + 12.80583mm = 80mm The table width is always 8cm, and the column widths are computed accordingly. The rightmost column cells are with text-align=right. The C_Comm-1 r25.info.1.1.wref document is obtained from the original FO and the C_Comm-1 r25.info.1.1.noref document is obtained from the same FO with elements fo:page-number-citation removed. Note that due to the hidden removed, now the left and right border of the main block are visibile: this is in case a 2 columns layout is required, to obtain the middle vertical line to separate the two columns. Probably I missed something, but this seems to me related to the computed area for page number citation. 2012/8/28 Pascal Sancho psancho@gmail.com: Hi Glen, Not exactly: FOP 0.95: table content is shrunk to fit in clip space (wrong) FOP 1.0: table content is shifted to the wrong side of the clip limit (wrong) FOP 1.1RC1: table content is at the right place, but that reveals a new bug: hidden part is copyable 2012/8/28 Glenn Adams gl...@skynav.com: On Mon, Aug 27, 2012 at 10:10 PM, Pascal Sancho psancho@gmail.com wrote: There is something wrong in your XSL-FO: the table containing TOC is wider than available i-p-d, and the corresponding region-body has its property overflow set to hidden. So, the PDF shows what is expected visually. But... hidden text can be copied, and IMHO this is not the correct behaviour; the [1] FO 1.1 REC says: (hidden) indicates that the content is clipped (...); users will not have access to clipped content. So, I suggest you to fill in a bug entry on Bugzilla, providing both XSL-FO and PDF output. This is reproducible against both FOP 1.1RC1 and FOP trunk. Is this a regression in 1.1rc1, or was it present in 1.0? -- -- pascal _test.fo Description: Binary data - To unsubscribe, e-mail: fop-users-unsubscr...@xmlgraphics.apache.org For additional commands, e-mail: fop-users-h...@xmlgraphics.apache.org
Re: FOP 1.1rc1 strange tablecell content behaviour with text-align=right
Hi Glen, Not exactly: FOP 0.95: table content is shrunk to fit in clip space (wrong) FOP 1.0: table content is shifted to the wrong side of the clip limit (wrong) FOP 1.1RC1: table content is at the right place, but that reveals a new bug: hidden part is copyable 2012/8/28 Glenn Adams gl...@skynav.com: On Mon, Aug 27, 2012 at 10:10 PM, Pascal Sancho psancho@gmail.com wrote: There is something wrong in your XSL-FO: the table containing TOC is wider than available i-p-d, and the corresponding region-body has its property overflow set to hidden. So, the PDF shows what is expected visually. But... hidden text can be copied, and IMHO this is not the correct behaviour; the [1] FO 1.1 REC says: (hidden) indicates that the content is clipped (...); users will not have access to clipped content. So, I suggest you to fill in a bug entry on Bugzilla, providing both XSL-FO and PDF output. This is reproducible against both FOP 1.1RC1 and FOP trunk. Is this a regression in 1.1rc1, or was it present in 1.0? -- pascal - To unsubscribe, e-mail: fop-users-unsubscr...@xmlgraphics.apache.org For additional commands, e-mail: fop-users-h...@xmlgraphics.apache.org
Re: FOP 1.1rc1 strange tablecell content behaviour with text-align=right
Hi, There is something wrong in your XSL-FO: the table containing TOC is wider than available i-p-d, and the corresponding region-body has its property overflow set to hidden. So, the PDF shows what is expected visually. But... hidden text can be copied, and IMHO this is not the correct behaviour; the [1] FO 1.1 REC says: (hidden) indicates that the content is clipped (...); users will not have access to clipped content. So, I suggest you to fill in a bug entry on Bugzilla, providing both XSL-FO and PDF output. This is reproducible against both FOP 1.1RC1 and FOP trunk. [1] http://www.w3.org/TR/xsl/#overflow 2012/8/23 Giuseppe Briotti g.brio...@gmail.com: Well. more info. I perform several tests replacing the content of the table cell and it works if the content is a block, containing an inline element with some text. Moreover, it works also if i replace the page-number-citation element with simple text. Thus this problem seems related to page-number-citation and right align. it sounds like a regression bug? -- pascal - To unsubscribe, e-mail: fop-users-unsubscr...@xmlgraphics.apache.org For additional commands, e-mail: fop-users-h...@xmlgraphics.apache.org
Re: FOP 1.1rc1 strange tablecell content behaviour with text-align=right
On Mon, Aug 27, 2012 at 10:10 PM, Pascal Sancho psancho@gmail.comwrote: There is something wrong in your XSL-FO: the table containing TOC is wider than available i-p-d, and the corresponding region-body has its property overflow set to hidden. So, the PDF shows what is expected visually. But... hidden text can be copied, and IMHO this is not the correct behaviour; the [1] FO 1.1 REC says: (hidden) indicates that the content is clipped (...); users will not have access to clipped content. So, I suggest you to fill in a bug entry on Bugzilla, providing both XSL-FO and PDF output. This is reproducible against both FOP 1.1RC1 and FOP trunk. Is this a regression in 1.1rc1, or was it present in 1.0?
Re: FOP 1.1rc1 strange tablecell content behaviour with text-align=right
Well. more info. I perform several tests replacing the content of the table cell and it works if the content is a block, containing an inline element with some text. Moreover, it works also if i replace the page-number-citation element with simple text. Thus this problem seems related to page-number-citation and right align. it sounds like a regression bug? -- Giuseppe Briotti g.brio...@gmail.com Alme Sol, curru nitido diem qui promis et celas aliusque et idem nasceris, possis nihil urbe Roma visere maius. (Orazio) - To unsubscribe, e-mail: fop-users-unsubscr...@xmlgraphics.apache.org For additional commands, e-mail: fop-users-h...@xmlgraphics.apache.org
