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
