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:[email protected]] Sent: Monday, June 1, 2009 10:23 To: [email protected] 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:[email protected]] > Sent: Monday, June 1, 2009 7:00 > To: [email protected] > 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: [email protected] For additional commands, e-mail: [email protected] --------------------------------------------------------------------- To unsubscribe, e-mail: [email protected] For additional commands, e-mail: [email protected]
