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
