On 21.03.2007 21:22:04 Andreas L Delmelle wrote: > On Mar 21, 2007, at 10:42, Vincent Hennebert wrote: > > >> <snip /> > >> Whatever follows in that second definition is irrelevant wrt > >> determining the base for percentage values to compute the initial > >> offset (or IOW: determining which is the nearest ancestor > >> reference area) > > > > Indeed, you're right. In fact we don't have to care about the "fixed" > > value for absolute-position, because it doesn't apply to most of our > > renderers (which belong to the paged media category). The only > > renderer > > which would be concerned is the AWT previewer, but that's another > > question. > > > > (Re-reading the definition of "fixed" it actually doesn't make any > > sense > > to me. The position is computed WRT the nearest ancestor ref-area, but > > then it shouldn't move WRT the viewport. What if the ref-area appears > > only when we start scrolling? Should the fixed area already be > > there, or > > suddenly appear, or whatever? grrr) > > Well, it's only by forcing the issue that I begin to understand what > "fixed" refers to exactly. Until recently, I only /wondered/ what the > distinction was made for... > It makes more sense if you combine it with the definition of the > overflow property, I think. Some renderers could provide a scrolling > mechanism in case of overflow. A fixed-positioned block container > would in that case have a fixed place in the viewport, and the > content would scroll away underneath.
That's the picture I work with. Only for paged media you don't scroll and the viewport is the page. > >> Leaves my original question: > >> What I'm still not sure about is: > >> "Absolutely positioned areas are taken out of the normal flow." > >> Does that mean that percentages on any block-container with > >> position="absolute" should always be based on the containing page? > > > > ... and I agree with you that if they are specified as percentages > > that's unclear whether the percentage refers to the ref-area or the > > containing block :-\ > > I thought I had the answer yesterday, but now I'm beginning to doubt > again... :S > > The additional restriction imposed by the XSL Rec. (7.6.1 - "absolute- > position") says "descendant", which I too eagerly read as "child". It > all boils down to the question: in the case of nested block- > containers, is the area corresponding to the outer b-c the nearest > ancestor reference area to the area corresponding to the inner b-c? Yes, definitely. If you look at the area tree XML, you'll see exactly that. Only the renderer handles the positioning differently based of the trait. Taking the b-c out of the normal flow only means in terms of bpd cursor advancement. > If so, then percentages refer to the dimensions of the outer b-c's area. Yessss > As Manuel indicated, if these dimensions are unspecified or > explicitly set to "auto", then the percentage would resolve to zero > because of the circular dependency: the resolved value of the > percentage would be needed to determine the base value... Something like that. > Seems my proposed fix (bugzilla 41894) goes in the right direction. I agree. > Only it does not take reference-orientation and/or writing-mode into > account when mapping width/height to ipd/bpd... but that seems to me > currently a part of a larger problem. At certain places in the code, > nothing but ipd/bpd is used. Then at other places, we get explicit > references to width/height. I'm thinking of moving this logic to the > fo tree/property side. The layoutengine should work entirely with ipd > and bpd, if only to give the /impression/ of consistency... ;-) Agreed, that part is still in need of improvement. Remember the post on fop-users of a user who wanted to rotate the column headings of a table by 90° and had to resort to SVG? That's actually something that IMO, the block-container could and should do. And it's exactly where FOP currently fails to behave. Jeremias Maerki
