You are viewing a plain text version of this content. The canonical link for it is here.
Posted to fop-users@xmlgraphics.apache.org by Giuseppe Briotti <g....@gmail.com> on 2012/08/21 15:45:22 UTC
FOP 1.1rc1 strange tablecell content behaviour with text-align=right
hi all.
We widely use fop 0.95 to produce pdf from xml documents. I made some
tests with fop 0.95, 1.0 and 1.1
in order to perform an upgrade to recent fop version.
FOP 1.0 works fine except for the well known bug
https://issues.apache.org/bugzilla/show_bug.cgi?id=49910.
Of course, it is possible to apply the patch to 1.0 source and recompile.
Anyway, I try the 1.1rc1 solve the bug, but there is something strange
with table cell alignement in case
of text-align=right, as you can see in the page 2 of fo-out.1.1o.pdf,
the cell content is placed out of
the cell on the right side (try to select the text on pdf to verify).
Probably I missed something, but...
Any hints?
--
Giuseppe Briotti
g.briotti@gmail.com
"Alme Sol, curru nitido diem qui
promis et celas aliusque et idem
nasceris, possis nihil urbe Roma
visere maius."
(Orazio)
Re: FOP 1.1rc1 strange tablecell content behaviour with text-align=right
Posted by Giuseppe Briotti <g....@gmail.com>.
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....@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 sloooowww) :-)
>
>
> 2012/8/29 Pascal Sancho <ps...@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....@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 <ps...@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 <ps...@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-unsubscribe@xmlgraphics.apache.org
>> For additional commands, e-mail: fop-users-help@xmlgraphics.apache.org
>
>
>
> --
>
> Giuseppe Briotti
> g.briotti@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.briotti@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-unsubscribe@xmlgraphics.apache.org
For additional commands, e-mail: fop-users-help@xmlgraphics.apache.org
Re: FOP 1.1rc1 strange tablecell content behaviour with text-align=right
Posted by Giuseppe Briotti <g....@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 sloooowww) :-)
2012/8/29 Pascal Sancho <ps...@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....@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 <ps...@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 <ps...@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-unsubscribe@xmlgraphics.apache.org
> For additional commands, e-mail: fop-users-help@xmlgraphics.apache.org
--
Giuseppe Briotti
g.briotti@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-unsubscribe@xmlgraphics.apache.org
For additional commands, e-mail: fop-users-help@xmlgraphics.apache.org
Re: FOP 1.1rc1 strange tablecell content behaviour with text-align=right
Posted by Pascal Sancho <ps...@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....@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 <ps...@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 <ps...@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
Re: FOP 1.1rc1 strange tablecell content behaviour with text-align=right
Posted by Giuseppe Briotti <g....@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 <ps...@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 <ps...@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-unsubscribe@xmlgraphics.apache.org
> For additional commands, e-mail: fop-users-help@xmlgraphics.apache.org
>
--
Giuseppe Briotti
g.briotti@gmail.com
"Alme Sol, curru nitido diem qui
promis et celas aliusque et idem
nasceris, possis nihil urbe Roma
visere maius."
(Orazio)
Re: FOP 1.1rc1 strange tablecell content behaviour with text-align=right
Posted by Pascal Sancho <ps...@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 <ps...@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-unsubscribe@xmlgraphics.apache.org
For additional commands, e-mail: fop-users-help@xmlgraphics.apache.org
Re: FOP 1.1rc1 strange tablecell content behaviour with text-align=right
Posted by Glenn Adams <gl...@skynav.com>.
On Mon, Aug 27, 2012 at 10:10 PM, Pascal Sancho <ps...@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?
Re: FOP 1.1rc1 strange tablecell content behaviour with text-align=right
Posted by Pascal Sancho <ps...@gmail.com>.
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....@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-unsubscribe@xmlgraphics.apache.org
For additional commands, e-mail: fop-users-help@xmlgraphics.apache.org
Re: FOP 1.1rc1 strange tablecell content behaviour with text-align=right
Posted by Giuseppe Briotti <g....@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?
--
Giuseppe Briotti
g.briotti@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-unsubscribe@xmlgraphics.apache.org
For additional commands, e-mail: fop-users-help@xmlgraphics.apache.org