Re: Border and padding on page regions
On Thu, Jun 19, 2008 at 3:45 PM, Jeremias Maerki [EMAIL PROTECTED] wrote: There's both in FOP. block-container has the border on the viewport. table-cell has it on the reference area (table-cell doesn't generate a viewport). But I fear we might actually be wrong about having the border and padding on the viewport area. Ok, so the region reference is the right place for borders and padding; a posteriori it seems reasonable: the viewport defines the window, the reference area starts defining what we see ... (but I could easily convince myself of the other option too :-) ) It's interesting that we treat background and borders together in the renderers although 4.9.4 http://www.w3.org/TR/xsl11/#rend-border makes a distinction where the background is to be applied. But we don't support background-attachment so that didn't get noticed that way. I could split the matod AbstractPathOrientedRenderer.drawBackAndBorders() in two drawBackground() / drawBorders() methods, as the background trait is still in the viewport while borders and padding will be in the reference area. Thanks for the feedback (to Andreas too) Regards Luca
Border and padding on page regions
Some time ago (well, almost 2 years!) we spoke about the possibility to allow users to define borders and padding for the page regions [1]. This week I finally found some time to do it, so I have it working on my local copy ... but then I was struck by a dilemma: the additional traits about borders and padding should be set for the region viewport (class RegionViewport) of for the region reference area (RegionReference)? This sentence in the specs (4.2.2. common traits) made me decide to put them in the RegionRefernce, as the padding results in a reduction of the content rectangle bpd / ipd: Only a reference-area may have a block-progression-direction which is different from that of its parent. But (6.4.14. fo:region-body), where it says that padding and borders should be 0, also says that it's the region viewport that has margins (so it would have paddings and borders too, if allowed). Moreover, the code already present in AbstractPathOrientedRendere.handleRegionTraits() (not to mention Murphy's laws!) seem to suggest that these traits should belong to the region viewport. So, a couple of questions: - do we still think that supporting borders and padding on regions when relaxed validation is on would be something good (or, at least, not bad)? - is RegionViewport the right place for the additional traits? Regards Luca [1] http://www.nabble.com/Re%3A-svn-commit%3A-r225580xmlgraphics-fop-trunk-test-layoutengine-testcases-page-master4.xml-to511937.html#a511937
Re: Border and padding on page regions
On Thu, Jun 19, 2008 at 1:26 PM, Luca Furini [EMAIL PROTECTED] wrote: Only a reference-area may have a block-progression-direction which is different from that of its parent. Ops, I realize only now that it says direction and not dimension :-) Ok, so I think this definitely means that the traits should be in the region viewport ... Sorry for the noise! Regards Luca
Re: Border and padding on page regions
On Jun 19, 2008, at 13:26, Luca Furini wrote: snip / So, a couple of questions: - do we still think that supporting borders and padding on regions when relaxed validation is on would be something good (or, at least, not bad)? I think this would be a fine addition. Other implementations have something similar, and the question has popped up a number of times now, so it will definitely not be bad... Cheers Andreas
Re: Border and padding on page regions
On 19.06.2008 13:26:21 Luca Furini wrote: Some time ago (well, almost 2 years!) we spoke about the possibility to allow users to define borders and padding for the page regions [1]. This week I finally found some time to do it, so I have it working on my local copy ... but then I was struck by a dilemma: the additional traits about borders and padding should be set for the region viewport (class RegionViewport) of for the region reference area (RegionReference)? Good question. There's both in FOP. block-container has the border on the viewport. table-cell has it on the reference area (table-cell doesn't generate a viewport). But I fear we might actually be wrong about having the border and padding on the viewport area. In 6.5.3, block-container: http://www.w3.org/TR/xsl11/#fo_block-container These determine the orientation of the start-edge, end-edge, before-edge and afteredge of the content-rectangle of the viewport-area, and of the padding-, border-, and content-rectangles of the reference-area. The same on inline-container, for example. This sentence in the specs (4.2.2. common traits) made me decide to put them in the RegionRefernce, as the padding results in a reduction of the content rectangle bpd / ipd: Only a reference-area may have a block-progression-direction which is different from that of its parent. But (6.4.14. fo:region-body), where it says that padding and borders should be 0, also says that it's the region viewport that has margins (so it would have paddings and borders too, if allowed). Moreover, the code already present in AbstractPathOrientedRendere.handleRegionTraits() (not to mention Murphy's laws!) seem to suggest that these traits should belong to the region viewport. Don't confuse margins with border/padding. Margins are on the outside of a construct, i.e. outside the viewport. Borders/padding are on the inside. It's interesting that we treat background and borders together in the renderers although 4.9.4 http://www.w3.org/TR/xsl11/#rend-border makes a distinction where the background is to be applied. But we don't support background-attachment so that didn't get noticed that way. I guess we have a corpse in the basement. ;-) Can anyone confirm? So, a couple of questions: - do we still think that supporting borders and padding on regions when relaxed validation is on would be something good (or, at least, not bad)? I guess so although I'd rather have background on simple-page-master. ;-) - is RegionViewport the right place for the additional traits? Regards Luca [1] http://www.nabble.com/Re%3A-svn-commit%3A-r225580xmlgraphics-fop-trunk-test-layoutengine-testcases-page-master4.xml-to511937.html#a511937 Jeremias Maerki