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 "Amick, Eric" <Er...@mail.house.gov> on 2009/05/29 18:31:34 UTC
Strange bug in 0.95?
I have the following simple FO:
<root xmlns="http://www.w3.org/1999/XSL/Format" font-family="Times">
<layout-master-set>
<simple-page-master master-name="page" margin=".25in"
page-height="11in" page-width="8.5in">
<region-body/>
</simple-page-master>
</layout-master-set>
<page-sequence master-reference="page">
<flow flow-name="xsl-region-body">
<block-container height="100%" border="solid" padding="1em">
<block>Hello</block>
</block-container>
</flow>
</page-sequence>
</root>
I was expecting the border to be the same distance from every edge of
the page, but the resulting PDF has the side and bottom edges of the box
closer to the edges of the page; in fact, the bottom edge of the box is
off the page. If I remove the padding, the border appears as I was
expecting. It appears that the padding is causing the height and width
of the block-container to increase instead of reducing the available
area inside the block-container's border. Am I missing something, or is
this a bug?
Eric Amick
Legislative Computer Systems
Office of the Clerk
Re: Strange bug in 0.95?
Posted by Vincent Hennebert <vh...@gmail.com>.
Hi,
Andreas Delmelle wrote:
> On 01 Jun 2009, at 16:49, Amick, Eric wrote:
>
>> Fair enough. It still seems like a lot of work (and not exactly
>> intuitive) just to draw a box along the margins of a page. I can't help
>> wondering why they disallowed borders on region-body, for instance.
I think that was deliberately done to ease the life of developers.
Although it turned out that almost all implementations actually added
that feature as an extension.
> Heh, FOP allows those. I know this works in FOP Trunk, but not 100% sure
> whether the related changes are already in 0.95.
Confirmed, this works only in FOP Trunk, and you have to enable relaxed
validation (‘-r’ switch)
> Regards
>
> Andreas
Vincent
---------------------------------------------------------------------
To unsubscribe, e-mail: fop-users-unsubscribe@xmlgraphics.apache.org
For additional commands, e-mail: fop-users-help@xmlgraphics.apache.org
Re: Strange bug in 0.95?
Posted by Andreas Delmelle <an...@telenet.be>.
On 01 Jun 2009, at 16:49, Amick, Eric wrote:
> Fair enough. It still seems like a lot of work (and not exactly
> intuitive) just to draw a box along the margins of a page. I can't
> help
> wondering why they disallowed borders on region-body, for instance.
Heh, FOP allows those. I know this works in FOP Trunk, but not 100%
sure whether the related changes are already in 0.95.
Regards
Andreas
---------------------------------------------------------------------
To unsubscribe, e-mail: fop-users-unsubscribe@xmlgraphics.apache.org
For additional commands, e-mail: fop-users-help@xmlgraphics.apache.org
RE: Strange bug in 0.95?
Posted by "Amick, Eric" <Er...@mail.house.gov>.
Fair enough. It still seems like a lot of work (and not exactly
intuitive) just to draw a box along the margins of a page. I can't help
wondering why they disallowed borders on region-body, for instance.
Eric Amick
Legislative Computer Systems
Office of the Clerk
-----Original Message-----
From: Vincent Hennebert [mailto:vhennebert@gmail.com]
Sent: Monday, June 1, 2009 10:23
To: fop-users@xmlgraphics.apache.org
Subject: Re: Strange bug in 0.95?
Hi Eric,
Amick, Eric wrote:
> Strange. Is there any reason there is apparently no property to
> specify the height of the allocation-rectangle for a block-area? It
> seems like an extremely useful thing to have.
Indeed I don't think there is such a property. Whether it would be
'extremely' useful might be debatable though. There is a semi-automatic
way to achieve what you want:
<fo:block-container height="100% - 2*1em - 2*1pt" ...
assuming the padding is 2em and the border 1pt. Since in most cases
XSL-FO files are produced in some programmed way, it should be
relatively easy to create placeholders in the formula above for the
actual values of padding and border.
HTH,
Vincent
> Eric Amick
> Legislative Computer Systems
> Office of the Clerk
>
> -----Original Message-----
> From: Vincent Hennebert [mailto:vhennebert@gmail.com]
> Sent: Monday, June 1, 2009 7:00
> To: fop-users@xmlgraphics.apache.org
> Subject: Re: Strange bug in 0.95?
>
> Hi,
>
> Andreas Delmelle wrote:
>> On 29 May 2009, at 18:31, Amick, Eric wrote:
>>
>>
>> Hi Eric
>>
>>> I have the following simple FO:
>>>
>>> <snip />
>>> I was expecting the border to be the same distance from every edge
>>> of
>
>>> the page, but the resulting PDF has the side and bottom edges of the
>>> box closer to the edges of the page; in fact, the bottom edge of the
>>> box is off the page. If I remove the padding, the border appears as
>>> I
>
>>> was expecting. It appears that the padding is causing the height and
>>> width of the block-container to increase instead of reducing the
>>> available area inside the block-container's border. Am I missing
>>> something, or is this a bug?
>> Definitely a bug. Apparently, it only occurs for relative-positioned
>> block-containers. If you position it absolutely (position="absolute"
>> top="0" left="0"), you also get the expected output...
>
> This is /not/ a bug. The 'height' property specify the /content
> height/ of the block [1] i.e., excluding the border- and
> padding-rectangles. If its value is a percentage it refers to the
> height of the nearest ancestor reference area, loosely speaking here
> the height of the region-body.
>
> In the block-progression-direction, areas are stacked from border
> rectangle to border-rectangle. So here, the top of the border
> rectangle coincides with the top of the region-body, and this is why
> you get a warning that the block doesn't fit in the page. In the
> inline-progression-direction, areas are stacked from
> /content-rectangle/ to content-rectangle, that is, without taking
> border and padding into account. So if no indent is specified on the
> block, the border- and padding-rectangle effectively stick out into
> the margins. This is all explained in official terms in section 4 of
> the Recommendation [2] (more specifically section 4.2, 4.4 and 4.5).
>
> If the block is absolutely positioned, the 'top' and 'left' properties
> specify the positioning of the /content-rectangle/, so if set to 0 the
> top-left corner of the content-rectangle coincides with the top-left
> corner of the region-body.
>
> So in both cases FOP's behaviour is perfectly normal.
>
> [1] http://www.w3.org/TR/xsl11/#block-progression-dimension
> [2] http://www.w3.org/TR/xsl11/#area_model
>
>
>> Please log a report for this in Bugzilla, so we don't lose track of
> it.
>>
>> Thanks!
>>
>> Andreas
>
>
> Hope this clarifies the topic,
> Vincent
---------------------------------------------------------------------
To unsubscribe, e-mail: fop-users-unsubscribe@xmlgraphics.apache.org
For additional commands, e-mail: fop-users-help@xmlgraphics.apache.org
---------------------------------------------------------------------
To unsubscribe, e-mail: fop-users-unsubscribe@xmlgraphics.apache.org
For additional commands, e-mail: fop-users-help@xmlgraphics.apache.org
Re: Strange bug in 0.95?
Posted by Vincent Hennebert <vh...@gmail.com>.
Hi Eric,
Amick, Eric wrote:
> Strange. Is there any reason there is apparently no property to specify
> the height of the allocation-rectangle for a block-area? It seems like
> an extremely useful thing to have.
Indeed I don’t think there is such a property. Whether it would be
‘extremely’ useful might be debatable though. There is a semi-automatic
way to achieve what you want:
<fo:block-container height="100% - 2*1em - 2*1pt" ...
assuming the padding is 2em and the border 1pt. Since in most cases
XSL-FO files are produced in some programmed way, it should be
relatively easy to create placeholders in the formula above for the
actual values of padding and border.
HTH,
Vincent
> Eric Amick
> Legislative Computer Systems
> Office of the Clerk
>
> -----Original Message-----
> From: Vincent Hennebert [mailto:vhennebert@gmail.com]
> Sent: Monday, June 1, 2009 7:00
> To: fop-users@xmlgraphics.apache.org
> Subject: Re: Strange bug in 0.95?
>
> Hi,
>
> Andreas Delmelle wrote:
>> On 29 May 2009, at 18:31, Amick, Eric wrote:
>>
>>
>> Hi Eric
>>
>>> I have the following simple FO:
>>>
>>> <snip />
>>> I was expecting the border to be the same distance from every edge of
>
>>> the page, but the resulting PDF has the side and bottom edges of the
>>> box closer to the edges of the page; in fact, the bottom edge of the
>>> box is off the page. If I remove the padding, the border appears as I
>
>>> was expecting. It appears that the padding is causing the height and
>>> width of the block-container to increase instead of reducing the
>>> available area inside the block-container's border. Am I missing
>>> something, or is this a bug?
>> Definitely a bug. Apparently, it only occurs for relative-positioned
>> block-containers. If you position it absolutely (position="absolute"
>> top="0" left="0"), you also get the expected output...
>
> This is /not/ a bug. The 'height' property specify the /content height/
> of the block [1] i.e., excluding the border- and padding-rectangles. If
> its value is a percentage it refers to the height of the nearest
> ancestor reference area, loosely speaking here the height of the
> region-body.
>
> In the block-progression-direction, areas are stacked from border
> rectangle to border-rectangle. So here, the top of the border rectangle
> coincides with the top of the region-body, and this is why you get a
> warning that the block doesn't fit in the page. In the
> inline-progression-direction, areas are stacked from /content-rectangle/
> to content-rectangle, that is, without taking border and padding into
> account. So if no indent is specified on the block, the border- and
> padding-rectangle effectively stick out into the margins. This is all
> explained in official terms in section 4 of the Recommendation [2] (more
> specifically section 4.2, 4.4 and 4.5).
>
> If the block is absolutely positioned, the 'top' and 'left' properties
> specify the positioning of the /content-rectangle/, so if set to 0 the
> top-left corner of the content-rectangle coincides with the top-left
> corner of the region-body.
>
> So in both cases FOP's behaviour is perfectly normal.
>
> [1] http://www.w3.org/TR/xsl11/#block-progression-dimension
> [2] http://www.w3.org/TR/xsl11/#area_model
>
>
>> Please log a report for this in Bugzilla, so we don't lose track of
> it.
>>
>> Thanks!
>>
>> Andreas
>
>
> Hope this clarifies the topic,
> Vincent
---------------------------------------------------------------------
To unsubscribe, e-mail: fop-users-unsubscribe@xmlgraphics.apache.org
For additional commands, e-mail: fop-users-help@xmlgraphics.apache.org
RE: Strange bug in 0.95?
Posted by "Amick, Eric" <Er...@mail.house.gov>.
Strange. Is there any reason there is apparently no property to specify
the height of the allocation-rectangle for a block-area? It seems like
an extremely useful thing to have.
Eric Amick
Legislative Computer Systems
Office of the Clerk
-----Original Message-----
From: Vincent Hennebert [mailto:vhennebert@gmail.com]
Sent: Monday, June 1, 2009 7:00
To: fop-users@xmlgraphics.apache.org
Subject: Re: Strange bug in 0.95?
Hi,
Andreas Delmelle wrote:
> On 29 May 2009, at 18:31, Amick, Eric wrote:
>
>
> Hi Eric
>
>> I have the following simple FO:
>>
>> <snip />
>> I was expecting the border to be the same distance from every edge of
>> the page, but the resulting PDF has the side and bottom edges of the
>> box closer to the edges of the page; in fact, the bottom edge of the
>> box is off the page. If I remove the padding, the border appears as I
>> was expecting. It appears that the padding is causing the height and
>> width of the block-container to increase instead of reducing the
>> available area inside the block-container's border. Am I missing
>> something, or is this a bug?
>
> Definitely a bug. Apparently, it only occurs for relative-positioned
> block-containers. If you position it absolutely (position="absolute"
> top="0" left="0"), you also get the expected output...
This is /not/ a bug. The 'height' property specify the /content height/
of the block [1] i.e., excluding the border- and padding-rectangles. If
its value is a percentage it refers to the height of the nearest
ancestor reference area, loosely speaking here the height of the
region-body.
In the block-progression-direction, areas are stacked from border
rectangle to border-rectangle. So here, the top of the border rectangle
coincides with the top of the region-body, and this is why you get a
warning that the block doesn't fit in the page. In the
inline-progression-direction, areas are stacked from /content-rectangle/
to content-rectangle, that is, without taking border and padding into
account. So if no indent is specified on the block, the border- and
padding-rectangle effectively stick out into the margins. This is all
explained in official terms in section 4 of the Recommendation [2] (more
specifically section 4.2, 4.4 and 4.5).
If the block is absolutely positioned, the 'top' and 'left' properties
specify the positioning of the /content-rectangle/, so if set to 0 the
top-left corner of the content-rectangle coincides with the top-left
corner of the region-body.
So in both cases FOP's behaviour is perfectly normal.
[1] http://www.w3.org/TR/xsl11/#block-progression-dimension
[2] http://www.w3.org/TR/xsl11/#area_model
> Please log a report for this in Bugzilla, so we don't lose track of
it.
>
>
> Thanks!
>
> Andreas
Hope this clarifies the topic,
Vincent
---------------------------------------------------------------------
To unsubscribe, e-mail: fop-users-unsubscribe@xmlgraphics.apache.org
For additional commands, e-mail: fop-users-help@xmlgraphics.apache.org
---------------------------------------------------------------------
To unsubscribe, e-mail: fop-users-unsubscribe@xmlgraphics.apache.org
For additional commands, e-mail: fop-users-help@xmlgraphics.apache.org
Re: Strange bug in 0.95?
Posted by Andreas Delmelle <an...@telenet.be>.
On 01 Jun 2009, at 13:33, Andreas Delmelle wrote:
> <snip />
> Right, my mistake. I should have double-checked. The additional
> space at the top, outside of the block-container is a result of the
> line's half-leading. I initially thought the padding was being
> doubled somehow.
This comment also offers a possible workaround for the sample file:
set the flow's font-size to zero, and reset it on the block-container
or the block to get the desired result.
Regards
Andreas
---------------------------------------------------------------------
To unsubscribe, e-mail: fop-users-unsubscribe@xmlgraphics.apache.org
For additional commands, e-mail: fop-users-help@xmlgraphics.apache.org
Re: Strange bug in 0.95?
Posted by Andreas Delmelle <an...@telenet.be>.
On 01 Jun 2009, at 12:59, Vincent Hennebert wrote:
> Andreas Delmelle wrote:
>> Definitely a bug. Apparently, it only occurs for relative-positioned
>> block-containers. If you position it absolutely (position="absolute"
>> top="0" left="0"), you also get the expected output...
>
> This is /not/ a bug. The ‘height’ property specify the /content
> height/
> of the block [1] i.e., excluding the border- and padding-rectangles.
> If
> its value is a percentage it refers to the height of the nearest
> ancestor reference area, loosely speaking here the height of the
> region-body.
Right, my mistake. I should have double-checked. The additional space
at the top, outside of the block-container is a result of the line's
half-leading. I initially thought the padding was being doubled somehow.
Regards
Andreas
---------------------------------------------------------------------
To unsubscribe, e-mail: fop-users-unsubscribe@xmlgraphics.apache.org
For additional commands, e-mail: fop-users-help@xmlgraphics.apache.org
Re: Strange bug in 0.95?
Posted by Vincent Hennebert <vh...@gmail.com>.
Hi,
Andreas Delmelle wrote:
> On 29 May 2009, at 18:31, Amick, Eric wrote:
>
>
> Hi Eric
>
>> I have the following simple FO:
>>
>> <snip />
>> I was expecting the border to be the same distance from every edge of
>> the page, but the resulting PDF has the side and bottom edges of the
>> box closer to the edges of the page; in fact, the bottom edge of the
>> box is off the page. If I remove the padding, the border appears as I
>> was expecting. It appears that the padding is causing the height and
>> width of the block-container to increase instead of reducing the
>> available area inside the block-container's border. Am I missing
>> something, or is this a bug?
>
> Definitely a bug. Apparently, it only occurs for relative-positioned
> block-containers. If you position it absolutely (position="absolute"
> top="0" left="0"), you also get the expected output...
This is /not/ a bug. The ‘height’ property specify the /content height/
of the block [1] i.e., excluding the border- and padding-rectangles. If
its value is a percentage it refers to the height of the nearest
ancestor reference area, loosely speaking here the height of the
region-body.
In the block-progression-direction, areas are stacked from border
rectangle to border-rectangle. So here, the top of the border rectangle
coincides with the top of the region-body, and this is why you get
a warning that the block doesn’t fit in the page. In the
inline-progression-direction, areas are stacked from /content-rectangle/
to content-rectangle, that is, without taking border and padding into
account. So if no indent is specified on the block, the border- and
padding-rectangle effectively stick out into the margins. This is all
explained in official terms in section 4 of the Recommendation [2] (more
specifically section 4.2, 4.4 and 4.5).
If the block is absolutely positioned, the ‘top’ and ‘left’ properties
specify the positioning of the /content-rectangle/, so if set to 0 the
top-left corner of the content-rectangle coincides with the top-left
corner of the region-body.
So in both cases FOP’s behaviour is perfectly normal.
[1] http://www.w3.org/TR/xsl11/#block-progression-dimension
[2] http://www.w3.org/TR/xsl11/#area_model
> Please log a report for this in Bugzilla, so we don't lose track of it.
>
>
> Thanks!
>
> Andreas
Hope this clarifies the topic,
Vincent
---------------------------------------------------------------------
To unsubscribe, e-mail: fop-users-unsubscribe@xmlgraphics.apache.org
For additional commands, e-mail: fop-users-help@xmlgraphics.apache.org
Re: Strange bug in 0.95?
Posted by Andreas Delmelle <an...@telenet.be>.
On 29 May 2009, at 18:31, Amick, Eric wrote:
Hi Eric
> I have the following simple FO:
>
> <snip />
> I was expecting the border to be the same distance from every edge
> of the page, but the resulting PDF has the side and bottom edges of
> the box closer to the edges of the page; in fact, the bottom edge of
> the box is off the page. If I remove the padding, the border appears
> as I was expecting. It appears that the padding is causing the
> height and width of the block-container to increase instead of
> reducing the available area inside the block-container's border. Am
> I missing something, or is this a bug?
Definitely a bug. Apparently, it only occurs for relative-positioned
block-containers. If you position it absolutely (position="absolute"
top="0" left="0"), you also get the expected output...
Please log a report for this in Bugzilla, so we don't lose track of it.
Thanks!
Andreas
---------------------------------------------------------------------
To unsubscribe, e-mail: fop-users-unsubscribe@xmlgraphics.apache.org
For additional commands, e-mail: fop-users-help@xmlgraphics.apache.org