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 : > 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?
On Mar 27, 2007, at 10:32, Vincent Hennebert wrote: 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?
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?
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: >> >> >> >> ... >> >> ... >> >> 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?
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: > > > > ... > > ... > > Rest of 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: ... 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?
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: ... ... Rest of 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?
>- Oorspronkelijk bericht - >Van: Vincent Hennebert [mailto:[EMAIL PROTECTED] Hi Vincent, >> 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?
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! >>> >>> 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". >>> 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?
On Mar 21, 2007, at 22:06, Jeremias Maerki wrote: [Me: ] 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) 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. 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?
Hi Andreas, Thanks for your perseverance ;-) Andreas L Delmelle a écrit : > On Mar 22, 2007, at 10:05, Vincent Hennebert wrote: > > Hi Vincent, > >> >> 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? > > 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... > It is only when the latter viewport-area becomes visible that the > fixed-area appears (as a static part of that other viewport). It starts > out at the same position in the viewport as an absolute-positioned area, Invisible, then. Suppose you have to scroll down to make the nearest ancestor ref-area appear, and display the fixed area as soon as the ref-area starts appearing. Then unless "top" is negative the fixed area won't be visible yet. Follow me? > but stays there, no matter how far you scroll down... > >> Where? When the ref-area is scrolled away, should the fixed area >> suddenly disappear? Remain in the viewport? > > When the enclosing /viewport/-area goes out of scope, the fixed area > disappears. As long as the viewport is visible, the fixed area is too. > >> 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. > Remember that a "fixed" positioned b-c can be positioned (absolutely) > inside another b-c, and the outer b-c could even be a > relative-positioned one, to add to all the fun... :) > > > Cheers, > > Andreas Vincent
Re: Percentages in CommonAbsolutePosition?
On Mar 22, 2007, at 10:05, Vincent Hennebert wrote: Hi Vincent, 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? 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. It is only when the latter viewport-area becomes visible that the fixed-area appears (as a static part of that other viewport). It starts out at the same position in the viewport as an absolute-positioned area, but stays there, no matter how far you scroll down... Where? When the ref-area is scrolled away, should the fixed area suddenly disappear? Remain in the viewport? When the enclosing /viewport/-area goes out of scope, the fixed area disappears. As long as the viewport is visible, the fixed area is too. 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. Remember that a "fixed" positioned b-c can be positioned (absolutely) inside another b-c, and the outer b-c could even be a relative- positioned one, to add to all the fun... :) 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: >> 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. Vincent
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: > > >> > >> 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?
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:
> >
> >>
> >> 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:
>
>
>
>
> ...
>
> is semantically equivalent to
>
>
>
>
>
> ...
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 20.03.2007 17:18:36 a_l.delmelle wrote: > >- Oorspronkelijk bericht - > >Van: Chris Bowditch [mailto:[EMAIL PROTECTED] > > > > >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) I agree. > 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 don't think so. That's only about the positioning of the area, not about determining the percentages. This just means that the "bpd-cursor" is not advanced in the normal flow when an absolute or fixed block-container is encountered. > Any other (dissenting) thoughts? > > Cheers, > > Andreas > Jeremias Maerki
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 > 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 Mar 21, 2007, at 10:42, Vincent Hennebert wrote: 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?
Hi Andreas, [EMAIL PROTECTED] a écrit : >> - Oorspronkelijk bericht - >> Van: Chris Bowditch [mailto:[EMAIL PROTECTED] >> > >> 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 20, 2007, at 21:55, Andreas L Delmelle wrote:
On Mar 20, 2007, at 17:47, Chris Bowditch wrote:
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?)
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:
...
is semantically equivalent to
...
The offsets are, in BOTH cases relative to the containing page,
unless absolute-position="auto".
Correct?
Cheers,
Andreas
Re: Percentages in CommonAbsolutePosition?
On Mar 20, 2007, at 17:47, Chris Bowditch wrote: 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. ;) Cheers, Andreas
Re: Percentages in CommonAbsolutePosition?
[EMAIL PROTECTED] wrote: - Oorspronkelijk bericht - Van: Chris Bowditch [mailto:[EMAIL PROTECTED] 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... Have you actually checked the code to see the difference in handling between absolute-position="absolute" and absolute-position="fixed"? When I was having trouble placing a BC in the past, Jeremias told me that I needed to use absolute-position="fixed" instead of absolute-position="absolute" to place it relatively to the top left of the page. From the fact JM wrote the BC Layout code I deduce this is JM's assessment as well as Vincent's assessment. But I guess he can speak for himself ;) In the meantime, the current behaviour can be deduced from the code. 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? I think so, but like yourself I'm not 100% certain. I think it would certainly meet user expectations. Chris
Re: Percentages in CommonAbsolutePosition?
>- Oorspronkelijk bericht - >Van: Chris Bowditch [mailto:[EMAIL PROTECTED] > >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?
[EMAIL PROTECTED] wrote: 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 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: 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 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?
Hi, Manuel Mall a écrit : > On Tuesday 20 March 2007 04:10, Andreas L Delmelle wrote: >> 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)? To the outer block-container, which generates a ref-area. That would be relative to the page if the value of "absolute-position" were "fixed". If I'm correct... However, the following statement in §7.6.5 of the XSL-FO rec is a bit unclear: "The left, right, top, and bottom are interpreted in the prevailing coordinate system (established by the nearest ancestor reference area) and not relative to the "containing block" as in CSS." Does that apply only to the edge from which the block should be shifted, or also to the length? It seems you chose the nearest ref-area in your patch, but I can't have a definite opinion towards one or the other possibility. >> 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". 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 Vincent
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]> > > > >> > >> > >>> >>> bidi="embed"> > >>> >>> left="16.0%" top="16.0%"> > >>> > >>> 1 >>> fo:inline> > >>> > >>> > >> > >> > >> > >>> 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 inside > >>> the top-level 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
