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

Reply via email to