Re: Percentages in CommonAbsolutePosition?
Hello Vincent, So you wanna join the game? ;-) Well, sometimes it's hard to resist :-) Normally you would assume that if you define a position wrt a certain area (i.c. the page viewport), percentages are also interpreted wrt to width and height of that same area. The added remark to the left property (7.6.5) states that it should be interpreted in the prevailing coordinate system (established by the nearest ancestor reference area). You're right, and that would rule out the page viewport. Still I'd like to think (and hope) that they simply forgot to add ...or, if absolute-position has the value 'fixed', the page-viewport area here. The sections quoted below, when taken together, state that for fixed areas, left, top etc. should be interpreted immediately as relative to the page-viewport: 4.2.2 Common Traits (...) Each area has the traits top-position, bottom-position left-position, and right-position which represent the distance from the edges of its content-rectangle to the like-named edges of the nearest ancestor reference-area (or the page-viewport-area in the case of areas generated by descendants of formatting objects whose absolute- position is fixed); 4.9.1 Geometry (...) All areas in the tree with an area-class of xsl-fixed are positioned such that the left-, right-, top-, and bottom-edges of its content- rectangle are offset inward from the content-rectangle of its ancestor page-viewport-area by distances specified by the left- position, right-position, top-position, and bottom-position traits, respectively. 5.5.4 Absolute-position Property If absolute-position has the value absolute or fixed, the values of the left-position, top-position, etc. traits are copied directly from the values of the left, top, etc. properties. Otherwise these traits' values are left undefined during refinement and determined during composition. So, at the moment, it seems that we can all take our pick depending on what we prefer. Time for official clarification indeed. Personally I hope that: a) percentages and explicit lengths should always be interpreted in the same coordinate system, and b) for absolute and fixed areas, that this coordinate system is always the ancestor which the area is attached to (nearest ancestor-ref and page-vp, respectively). Kind regards, Paul Vinkenoog
Re: Percentages in CommonAbsolutePosition?
Hi Paul, So you wanna join the game? ;-) Paul Vinkenoog a écrit : snip/ The (1.1) spec says that if the positioning is... - absolute: the positions are taken with respect to the nearest ancestor reference area; - fixed: the positions are taken with respect to the page viewport (for paged media, like PDF) or the document viewport (for continuous media). But then 7.3, Reference Rectangle for Percentage Computations, seems a bit confusing, at least for fixed positioning: When the absolute-position is fixed, the containing block is defined by the nearest ancestor viewport area. Thanks for pointing this out. Indeed this seems to add to the confusion :-\ Normally you would assume that if you define a position wrt a certain area (i.c. the page viewport), percentages are also interpreted wrt to width and height of that same area. The added remark to the left property (7.6.5) states that it should be interpreted in the prevailing coordinate system (established by the nearest ancestor reference area). But section 7.3 says that the containing block is defined by the nearest ancestor viewport area, which is always the same excepted for table-cells. What's not clear is if the references for the /offset/ and for the /length/ should be the same or not. The ambiguity could be resolved by considering that the added remark in 7.6.5 applies only to the offset, and that the statements in 7.3 to the computation of percentages. Then again, thinking about what is an ancestor area: the way I see it, absolute and fixed positioning make an area break out of its FO ancestry. That is, if fo:block-container A is a direct child of fo:block-container B, but A's positioning is fixed, the *area* generated by A is not a direct child of the area generated by B, but of the page-viewport area. Sure, but my understanding is that the ancestor area should be determined /before/ taking the object out of the flow. So the position of A should be computed WRT B, and only then A would be made a child of the nearest page-viewport area. IMO this notion of out of the flow has an importance only for the following siblings, whose positions are computed without taking A into account. This in turn means that A's nearest ancestor viewport area is the page viewport (or document viewport), and the apparent inconsistency vanishes. Granted, it's an interpretation, but it seems the most logical one to me. For visibility, this means: - On a continuous medium, a fixed-positioned area is 1) always visible if it lies completely within the document viewport 2) never visible if it's completely outside the viewport 3) clipped if it lies partly within the viewport All this independent of the scroll position of the document. - On a paged medium, the same applies, but now with respect to the page. So again, the fixed area may be visible, invisible or partly visible *on the page*, depending on size and offsets. Of course the area may be out of sight even if it's (partly or fully) visible, because you may scroll away from (that part of) the page, or turn pages in a book. But that doesn't affect the principal visibility. Scrolling through a PDF document has nothing to do with viewport/reference pairs *within* the document's area tree. - With absolutely-positioned areas, the visibility may change over time even if the entire page (or document) is always fully visible, because one or more of their ancestor reference-areas may be scrollable within their associated viewport. This all makes sense. All this seems pretty logical and consistent to me, and (AFAIK) within the specification. So I hope I'm not just adding to the confusion here... :-) You do, but still thanks for chiming in ;-) That enforces my willing to ask for clarification to [EMAIL PROTECTED] Cheers, Vincent
Re: Percentages in CommonAbsolutePosition?
Hi Andreas, Andreas L Delmelle a écrit : On Mar 26, 2007, at 11:47, [EMAIL PROTECTED] wrote: If I understand you correctly, what you're saying is that if the fixed positioned block's nearest ref-area is not initially visible, then the top/left/etc. properties should be taken WRT the region-viewport-area? Almost... What I'm saying is that if the fixed-positioned block's nearest ancestor reference area is not visible, then the viewport-area will also not be visible. I've been searching around, but could not immediately find an example of a situation where a reference-area is established without an accompanying viewport-area. Regular fo:blocks generate normal block areas, which are not reference-areas... Diving into the viewport/reference-area relation some more, I think what I could as well have said from the beginning was: If the nearest ancestor reference area is the region-reference-area, then the position of a fixed-positioned area in the viewport is initially identical to that of an absolute-positioned area. By means of an example, if you have: fo:block fo:block-container absolute-position=absolute top=5% left=5% .../fo:block-container fo:block-container absolute-position=fixed top=5% left=15% .../fo:block-container Rest of block /fo:block Then the areas corresponding to the block-containers will be positioned at the resolved coördinates in the nearest ancestor reference area, whatever that is. In this case, the same top, slightly different left. My point: Even if the rest of the block's content gets clipped or even if the content gets clipped somewhere way above the block, both block-containers should still be rendered at the specified coördinates in the reference-area and so, initially also in the viewport-area. Those coördinates specify an absolute position in the reference-area for absolute-position=absolute and a fixed position in the accompanying viewport-area for absolute-position=fixed. See the light? I don't think it overcomplicates the situation, quite on the contrary. To the renderers, maybe, since many of them need to process that relative-absolute position into one that maps to absolute positions on the page... I fully agree with you on that case. But tables for example (table-cell objects, actually) generate reference-area without generating viewport-areas. Also, if you have an enclosing normal-positioned block-container around your fixed-positioned block: fo:block-container fo:block-container absolute-position=fixed top=5% left=15% ... /fo:block-container /fo:block-container then the fixed area will be positioned WRT to the enclosing b-c's viewport area, which may itself be clipped. That's why I suspect that for fixed the ref-area to be considered should be the region-area (for paged media), unlike for absolute where this should be the nearest ancestor ref-area. There won't be any difference in most cases excepted in the above one, where I think it makes sense. Agree? Vincent
Re: Percentages in CommonAbsolutePosition?
Hi guys, Diving into the viewport/reference-area relation some more, I think what I could as well have said from the beginning was: If the nearest ancestor reference area is the region-reference-area, then the position of a fixed-positioned area in the viewport is initially identical to that of an absolute-positioned area. By means of an example, if you have: fo:block fo:block-container absolute-position=absolute top=5% left=5% .../fo:block-container fo:block-container absolute-position=fixed top=5% left=15% .../fo:block-container Then the areas corresponding to the block-containers will be positioned at the resolved coördinates in the nearest ancestor reference area, whatever that is. In this case, the same top, slightly different left. My point: Even if the rest of the block's content gets clipped or even if the content gets clipped somewhere way above the block, both block-containers should still be rendered at the specified coördinates in the reference-area and so, initially also in the viewport-area. Those coördinates specify an absolute position in the reference-area for absolute-position=absolute and a fixed position in the accompanying viewport-area for absolute-position=fixed. The (1.1) spec says that if the positioning is... - absolute: the positions are taken with respect to the nearest ancestor reference area; - fixed: the positions are taken with respect to the page viewport (for paged media, like PDF) or the document viewport (for continuous media). But then 7.3, Reference Rectangle for Percentage Computations, seems a bit confusing, at least for fixed positioning: When the absolute-position is fixed, the containing block is defined by the nearest ancestor viewport area. Normally you would assume that if you define a position wrt a certain area (i.c. the page viewport), percentages are also interpreted wrt to width and height of that same area. Then again, thinking about what is an ancestor area: the way I see it, absolute and fixed positioning make an area break out of its FO ancestry. That is, if fo:block-container A is a direct child of fo:block-container B, but A's positioning is fixed, the *area* generated by A is not a direct child of the area generated by B, but of the page-viewport area. This in turn means that A's nearest ancestor viewport area is the page viewport (or document viewport), and the apparent inconsistency vanishes. Granted, it's an interpretation, but it seems the most logical one to me. For visibility, this means: - On a continuous medium, a fixed-positioned area is 1) always visible if it lies completely within the document viewport 2) never visible if it's completely outside the viewport 3) clipped if it lies partly within the viewport All this independent of the scroll position of the document. - On a paged medium, the same applies, but now with respect to the page. So again, the fixed area may be visible, invisible or partly visible *on the page*, depending on size and offsets. Of course the area may be out of sight even if it's (partly or fully) visible, because you may scroll away from (that part of) the page, or turn pages in a book. But that doesn't affect the principal visibility. Scrolling through a PDF document has nothing to do with viewport/reference pairs *within* the document's area tree. - With absolutely-positioned areas, the visibility may change over time even if the entire page (or document) is always fully visible, because one or more of their ancestor reference-areas may be scrollable within their associated viewport. All this seems pretty logical and consistent to me, and (AFAIK) within the specification. So I hope I'm not just adding to the confusion here... :-) Yes, I think the spec could have been a lot clearer in places. Kind regards, Paul Vinkenoog
Re: Percentages in CommonAbsolutePosition?
I wrote: So I hope I'm not just adding to the confusion here... :-) ...but I probably did, because I was replying with the entire thread in mind, and the quoted text which I used as a handle certainly wasn't the most appropriate for what I wanted to say -- it just happened to be the last message in the thread, and it triggered my response because it mentioned the region-reference (and a little later, the nearest ancestor ref area) as the reference area for fixed positioning. Sorry about that. Kind regards, Paul Vinkenoog
Re: Percentages in CommonAbsolutePosition?
On Mar 27, 2007, at 10:32, Vincent Hennebert wrote: snip / That's why I suspect that for fixed the ref-area to be considered should be the region-area (for paged media), unlike for absolute where this should be the nearest ancestor ref-area. There won't be any difference in most cases excepted in the above one, where I think it makes sense. Agree? Yep. Good thing you noticed that table-cells generate normal reference-areas. That's one type of FO I forgot to check... :( Cheers, Andreas
Re: Percentages in CommonAbsolutePosition?
Hi Andreas, Andreas L Delmelle a écrit : On Mar 23, 2007, at 11:22, Vincent Hennebert wrote: Thanks for your perseverance ;-) You're welcome. :o) I'm sure we will manage! snip / If the nearest ancestor ref-area is not immediately visible, then I think this implies that the fixed-area's position is definitely not relative to the viewport you refer to, but to another nested viewport. Then which one? If there is no block-container in the flow, then the only viewport area is the region-body. And my question remains... OK, take the region-body as an example, with overflowing content and a fixed-positioned block-container that is a descendant of a block that initially falls outside the region-viewport, and thus is not immediately visible. Same as an absolute-positioned block-container, it will appear at a certain position in the region-viewport-area (regardless of where it was specified, or whether the containing block is visible or not). If I understand you correctly, what you're saying is that if the fixed positioned block's nearest ref-area is not initially visible, then the top/left/etc. properties should be taken WRT the region-viewport-area? I would really not agree with that. Besides the fact that that would complicate the implementation, I think that if the fixed area turns out to not be visible, then it will never be. Anyway if you give arbitrarily great values to top/left/etc. you /will/ get an area that lies outside the viewport-area, regardless of the value of the overflow property. For our current output-targets, the story ends here, because there is no scrolling. Note that an absolute-positioned block-container will always appear, even if the containing block ends up on a part that is clipped (never visible). OTOH, if the fixed-positioned block-container is enclosed by a regular one, then its initial visibility depends on the initial visibility of the regular block-container, precisely because the regular block-container establishes a new viewport/reference-area pair. The fixed-positioned one will appear as a static part in that new viewport once it becomes visible. Now I'm starting to see what you mean. While it makes perfectly sense to me, I'm almost sure this wasn't the intent of the authors when they wrote the description of fixed. Moreover there would then be little difference with absolute. snip / As the idea is probably to mimic the absolute and fixed value for position in CSS2, I think the description of fixed should not refer to the one of absolute for placing areas. They should have written something like These properties specify offsets with respect to the page's viewport area. The term page seems too narrow here. Your suggestion would only cover the case of absolute- or fixed-positioned areas whose nearest ancestor ref-area is the page-area. No, what I was saying is that the position would be computed WRT to the ancestor page-area (more precisely, the region-reference-area) instead of the nearest ancestor ref-area, whatever it is. Why? I think that would actually make it more difficult than it is now, since a nested block-container would then also need to get at the containing page, whereas now it is enough to stop at the first block-container that establishes the reference area. Well, yes. Although I'm not sure which one would actually be more complicated to implement. Also, the following sentence in the description of fixed: In the case of paged media, the area is fixed with respect to the page seems to go in that direction. Cheers, Vincent
Re: Percentages in CommonAbsolutePosition?
- Oorspronkelijk bericht - Van: Vincent Hennebert [mailto:[EMAIL PROTECTED] Hi Vincent, snip / OK, take the region-body as an example, with overflowing content and a fixed-positioned block-container that is a descendant of a block that initially falls outside the region-viewport, and thus is not immediately visible. Same as an absolute-positioned block-container, it will appear at a certain position in the region-viewport-area (regardless of where it was specified, or whether the containing block is visible or not). If I understand you correctly, what you're saying is that if the fixed positioned block's nearest ref-area is not initially visible, then the top/left/etc. properties should be taken WRT the region-viewport-area? Almost... What I'm saying is that if the fixed-positioned block's nearest ancestor reference area is not visible, then the viewport-area will also not be visible. I've been searching around, but could not immediately find an example of a situation where a reference-area is established without an accompanying viewport-area. Regular fo:blocks generate normal block areas, which are not reference-areas... I would really not agree with that. Besides the fact that that would complicate the implementation, I think that if the fixed area turns out to not be visible, then it will never be. Anyway if you give arbitrarily great values to top/left/etc. you /will/ get an area that lies outside the viewport-area, regardless of the value of the overflow property. Indeed, that was a situation I conveniently left out of scope for now, but this is also possible and legitimate. Cheers, Andreas
Re: Percentages in CommonAbsolutePosition?
On Mar 26, 2007, at 11:47, [EMAIL PROTECTED] wrote: If I understand you correctly, what you're saying is that if the fixed positioned block's nearest ref-area is not initially visible, then the top/left/etc. properties should be taken WRT the region-viewport- area? Almost... What I'm saying is that if the fixed-positioned block's nearest ancestor reference area is not visible, then the viewport- area will also not be visible. I've been searching around, but could not immediately find an example of a situation where a reference-area is established without an accompanying viewport- area. Regular fo:blocks generate normal block areas, which are not reference-areas... Diving into the viewport/reference-area relation some more, I think what I could as well have said from the beginning was: If the nearest ancestor reference area is the region-reference-area, then the position of a fixed-positioned area in the viewport is initially identical to that of an absolute-positioned area. By means of an example, if you have: fo:block fo:block-container absolute-position=absolute top=5% left=5% .../fo:block-container fo:block-container absolute-position=fixed top=5% left=15% .../fo:block-container Rest of block /fo:block Then the areas corresponding to the block-containers will be positioned at the resolved coördinates in the nearest ancestor reference area, whatever that is. In this case, the same top, slightly different left. My point: Even if the rest of the block's content gets clipped or even if the content gets clipped somewhere way above the block, both block-containers should still be rendered at the specified coördinates in the reference-area and so, initially also in the viewport-area. Those coördinates specify an absolute position in the reference-area for absolute-position=absolute and a fixed position in the accompanying viewport-area for absolute-position=fixed. See the light? I don't think it overcomplicates the situation, quite on the contrary. To the renderers, maybe, since many of them need to process that relative-absolute position into one that maps to absolute positions on the page... Cheers, Andreas
Re: Percentages in CommonAbsolutePosition?
On Mar 21, 2007, at 22:06, Jeremias Maerki wrote: [Me: ] snip / 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. Looking further into this, I can see the difficulties. A region on one page can have a different reference-orientation/ writing-mode than on the preceding or following page, and it's precisely those that form the basis on which the mapping of height/ width should be made. From the point of view of the higher-level LM, the height of an absolute-positioned block-container is the block-progression- dimension if the block-container's reference-orientation and writing- mode are the same(*) as that of the particular region it ends up on. If not, then everything is re-evaluated. height becomes ipd, top becomes after, left may become end... In a certain sense, it even seems that one could say that the specified value for block-progression-dimension may turn out to be what the higher level LM needs to consider as the inline-progression- dimension of the child area. Correct? (*) reference-orientation could also differ by 180 for height/width; for top/right/bottom/left this would make a difference however... Analogous for the writing-mode's difference between lr-tb and rl-tb Cheers, Andreas
Re: Percentages in CommonAbsolutePosition?
On Mar 23, 2007, at 11:22, Vincent Hennebert wrote: Thanks for your perseverance ;-) You're welcome. :o) snip / If the nearest ancestor ref-area is not immediately visible, then I think this implies that the fixed-area's position is definitely not relative to the viewport you refer to, but to another nested viewport. Then which one? If there is no block-container in the flow, then the only viewport area is the region-body. And my question remains... OK, take the region-body as an example, with overflowing content and a fixed-positioned block-container that is a descendant of a block that initially falls outside the region-viewport, and thus is not immediately visible. Same as an absolute-positioned block-container, it will appear at a certain position in the region-viewport-area (regardless of where it was specified, or whether the containing block is visible or not). For our current output-targets, the story ends here, because there is no scrolling. Note that an absolute-positioned block-container will always appear, even if the containing block ends up on a part that is clipped (never visible). OTOH, if the fixed-positioned block-container is enclosed by a regular one, then its initial visibility depends on the initial visibility of the regular block-container, precisely because the regular block-container establishes a new viewport/reference-area pair. The fixed-positioned one will appear as a static part in that new viewport once it becomes visible. snip / As the idea is probably to mimic the absolute and fixed value for position in CSS2, I think the description of fixed should not refer to the one of absolute for placing areas. They should have written something like These properties specify offsets with respect to the page's viewport area. The term page seems too narrow here. Your suggestion would only cover the case of absolute- or fixed-positioned areas whose nearest ancestor ref-area is the page-area. No, what I was saying is that the position would be computed WRT to the ancestor page-area (more precisely, the region-reference-area) instead of the nearest ancestor ref-area, whatever it is. Why? I think that would actually make it more difficult than it is now, since a nested block-container would then also need to get at the containing page, whereas now it is enough to stop at the first block-container that establishes the reference area. Cheers, Andreas
Re: Percentages in CommonAbsolutePosition?
Jeremias Maerki a écrit : 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. Well, that's still unclear. The area should be placed like in the absolute model, plus mustn't move WRT the viewport. In case of a continuous media, what should happen if the nearest ancestor ref-area doesn't appear yet in the viewport at the beginning of the viewing, but only after having scrolled a bit? Should the fixed area suddenly appear? Where? When the ref-area is scrolled away, should the fixed area suddenly disappear? Remain in the viewport? As the idea is probably to mimic the absolute and fixed value for position in CSS2, I think the description of fixed should not refer to the one of absolute for placing areas. They should have written something like These properties specify offsets with respect to the page's viewport area. Combined with the sentence The area generated is a descendant of the page-area where the first area from the object would have been placed had the object had absolute-position=auto specified, that would make the scheme absolutely clear I think. 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. Ye Re-reading the definition of left once again, it seems we may go with that. 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. Not in the case of absolutely-placed areas I think, as they are removed from the flow and have no impact on the layout of normal areas. If the ipd of the nearest ancestor ref-area is auto, then we would just have to wait that it becomes known (based on the layout constraints of other normal areas) before placing the absolute area. snip/ Vincent
Re: Percentages in CommonAbsolutePosition?
Hi Andreas, [EMAIL PROTECTED] a écrit : - Oorspronkelijk bericht - Van: Chris Bowditch [mailto:[EMAIL PROTECTED] snip / AFAICT, I don't think you've got everything nailed down here. As Vincent already mentioned the ancestor reference area could change depending on the value of abolute-position property. So can you clarify exactly how you intend to resolve the % for top and left for all values of absolute-position property of BC? Thanks, Hmm, I don't completely agree with Vincent's assessment... absolute-position=absolute - The area's position (and possibly size) is specified with the left, right, top, and bottom properties. These properties specify offsets with respect to the area's nearest ancestor reference area. absolute-position=fixed - The area's position is calculated according to the absolute model... 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) So I agree with you that offsets should always start from the edges of the nearest ref-area ancestor... 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 :-\ Any other (dissenting) thoughts? If no other opinion comes up in the next few days I'll raise the question on the xsl-editors list. Vincent
Re: Percentages in CommonAbsolutePosition?
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. 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? If so, then percentages refer to the dimensions of the outer b-c's area. 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... Seems my proposed fix (bugzilla 41894) goes in the right direction. 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... ;-) Cheers, Andreas
Re: Percentages in CommonAbsolutePosition?
On 20.03.2007 11:56:10 a_l.delmelle wrote: - Oorspronkelijk bericht - Van: Vincent Hennebert [mailto:[EMAIL PROTECTED] Manuel Mall a écrit : My understanding of the spec is that for top and bottom percentages only make sense if the containing block has a fixed height. If the containing block has a variable height percentages are suppose to be ignored and the property value assumed to be auto. I second that, see the CSS2 spec [1]: For 'top' and 'bottom', if the height of the containing block is not specified explicitly (i.e., it depends on content height), the percentage value is interpreted like 'auto'. [1] http://www.w3.org/TR/1998/REC-CSS2-19980512/visuren.html#position-props CSS doesn't have the last word here. See the definition for the 'left' property (XSL-FO 1.1 - §7.6.5) all the way at the bottom. In XSL, these are interpreted relative to the prevailing coördinate system. Not to the containing block as in CSS, but to the nearest ancestor reference area. I'd think a similar substitution holds for the definition of a percentage value a bit higher up, so that the offset is a percentage of the /nearest ancestor reference area/'s width Agreed? Yes. This part about the prevailing coordinate system is an addition of XSL 1.1. The WG tried to make this clearer. See: http://www.w3.org/TR/xsl11/#change10 Jeremias Maerki
Re: Percentages in CommonAbsolutePosition?
On 20.03.2007 22:54:30 Andreas L Delmelle wrote: On Mar 20, 2007, at 21:55, Andreas L Delmelle wrote: On Mar 20, 2007, at 17:47, Chris Bowditch wrote: snip / Have you actually checked the code to see the difference in handling between absolute-position=absolute and absolute- position=fixed? Errm, that would be a no. I've checked: a) the Recommendation and b) the resulting output. I never trust code. Not someone else's, but especially not my own. ;) FWIW: re-reading the description of the value of fixed for absolute- position, I think the key difference between absolute and fixed can be made clearer by an example. It is a minor, yet possibly very important nuance. In the case of continuous media, the area is fixed with respect to the viewport (and doesn't move when scrolled). Suppose you are viewing the output in Adobe Reader and zoom to fit-to- page-width. If you scroll down, a block-container with absolute- position=absolute would 'stick to' the page, while fixed would make that same block-container absolute-positioned relative to the viewport of the viewer application (until the whole page goes out of scope?) Why are leaving out the paged media here? Continuous media is not really the issue here. At least, that's what the example seems to want to point out, for AFAICT (Authors may wish to specify 'fixed' in a media-dependent way.) OTOH, there is the following consequence 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? I think so, but like yourself I'm not 100% certain. I think it would certainly meet user expectations. The counter-intuitive answer is in the second additional restriction imposed by the XSL Rec. The area generated is a descendant of the page-area where the first area from the object would have been placed had the object had absolute-position='auto' specified. This means that: fo:block-container absolute-position=absolute top=5mm fo:block fo:block-container absolute-position=absolute top=5mm ... is semantically equivalent to fo:block-container absolute-position=absolute top=5mm fo:block / /fo:block-container fo:block-container absolute-position=absolute top=5mm ... I strongly disagree because the outer block-container creates a reference area which means the second block-container would be positioned differently in the two cases. If you talked about fixed block-containers, then yes, the outcome would be the same, as both would be positioned relative to the page and not the nearest ancestor reference area. The offsets are, in BOTH cases relative to the containing page, unless absolute-position=auto. Nonono. Correct? Cheers, Andreas Jeremias Maerki
Re: Percentages in CommonAbsolutePosition?
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. Ye 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
Re: Percentages in CommonAbsolutePosition?
- Oorspronkelijk bericht - Van: Vincent Hennebert [mailto:[EMAIL PROTECTED] Manuel Mall a écrit : My understanding of the spec is that for top and bottom percentages only make sense if the containing block has a fixed height. If the containing block has a variable height percentages are suppose to be ignored and the property value assumed to be auto. I second that, see the CSS2 spec [1]: For 'top' and 'bottom', if the height of the containing block is not specified explicitly (i.e., it depends on content height), the percentage value is interpreted like 'auto'. [1] http://www.w3.org/TR/1998/REC-CSS2-19980512/visuren.html#position-props CSS doesn't have the last word here. See the definition for the 'left' property (XSL-FO 1.1 - §7.6.5) all the way at the bottom. In XSL, these are interpreted relative to the prevailing coördinate system. Not to the containing block as in CSS, but to the nearest ancestor reference area. I'd think a similar substitution holds for the definition of a percentage value a bit higher up, so that the offset is a percentage of the /nearest ancestor reference area/'s width Agreed? Cheers, Andreas
Re: Percentages in CommonAbsolutePosition?
[EMAIL PROTECTED] wrote: snip/ CSS doesn't have the last word here. See the definition for the 'left' property (XSL-FO 1.1 - §7.6.5) all the way at the bottom. In XSL, these are interpreted relative to the prevailing coördinate system. Not to the containing block as in CSS, but to the nearest ancestor reference area. I'd think a similar substitution holds for the definition of a percentage value a bit higher up, so that the offset is a percentage of the /nearest ancestor reference area/'s width Agreed? AFAICT, I don't think you've got everything nailed down here. As Vincent already mentioned the ancestor reference area could change depending on the value of abolute-position property. So can you clarify exactly how you intend to resolve the % for top and left for all values of absolute-position property of BC? Thanks, Chris
Re: Percentages in CommonAbsolutePosition?
- Oorspronkelijk bericht - Van: Chris Bowditch [mailto:[EMAIL PROTECTED] snip / AFAICT, I don't think you've got everything nailed down here. As Vincent already mentioned the ancestor reference area could change depending on the value of abolute-position property. So can you clarify exactly how you intend to resolve the % for top and left for all values of absolute-position property of BC? Thanks, Hmm, I don't completely agree with Vincent's assessment... absolute-position=absolute - The area's position (and possibly size) is specified with the left, right, top, and bottom properties. These properties specify offsets with respect to the area's nearest ancestor reference area. absolute-position=fixed - The area's position is calculated according to the absolute model... 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) 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? Any other (dissenting) thoughts? Cheers, Andreas
Re: Percentages in CommonAbsolutePosition? (was: Absolute positioning one fop-users@)
On Tuesday 20 March 2007 04:10, Andreas L Delmelle wrote: Begin forwarded message: From: Andreas L Delmelle [EMAIL PROTECTED] snip/ fo:block margin-left=0pt margin-right=0pt unicode- bidi=embed fo:block-container absolute-position=absolute left=16.0% top=16.0% fo:block fo:inline margin-left=0pt margin-right=0pt1/ fo:inline /fo:block /fo:block-container snip/ So now the 1, 2 and 3 are all inside the outer box, but all at the top left corner. This could be because the fo:block inside the top-level fo:block-container doesn't fill the entire block container. It could also be because % simply doesn't work (hopefully that isn't the case though, the former problem is easier to work around.) The problem could be the use of % in the left and top attributes. I just confirmed (by replacing the percentages with absolute widths): the percentages are most definitely the problem here. This is a FOP bug. :( I went digging a bit deeper, and what I found was that somehow the value of 16% got parsed into a FixedLength with an absolute value of 160mpt. The relative positioning between the block-containers is respected, but the displacement is brought down to only a fraction of a pixel. A fix for the left-percentage is setting the PercentBase on the PropertyMaker for left to LengthBase.CONTAINING_BLOCK_WIDTH in FOPropertyMapping.createAbsolutePositionProperties(). Although I'm not sure whether that is completely correct. Should the 16% be relative to the outer block-container, or to the page (since the inner block-containers' positions are also absolute)? Anyway, for the top-percentage, setting the percent-base still doesn't seem to be enough, although it fixes the issue described above. The parsed property is no longer a FixedLength. I'll see if I can track that last one down as well. My understanding of the spec is that for top and bottom percentages only make sense if the containing block has a fixed height. If the containing block has a variable height percentages are suppose to be ignored and the property value assumed to be auto. Cheers, Andreas Manuel
