Re: Percentages in CommonAbsolutePosition?

[Andreas L Delmelle]

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?

[Andreas L Delmelle]

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?

[Chris Bowditch]

[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

DO NOT REPLY [Bug 41831] - [PATCH] Refactored configuration, font detection and caching, url resolution

[bugzilla]

DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG·
RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT
.
ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND·
INSERTED IN THE BUG DATABASE.

http://issues.apache.org/bugzilla/show_bug.cgi?id=41831


[EMAIL PROTECTED] changed:

   What|Removed |Added

  Attachment #19713|0   |1
is obsolete||




--- Additional Comments From [EMAIL PROTECTED]  2007-03-20 09:25 ---
Created an attachment (id=19756)
 --> (http://issues.apache.org/bugzilla/attachment.cgi?id=19756&action=view)
Patch file

Following feedback from Andreas - thanks v much for taking the time to look at
this :-),  I have made a very minor modification to the MacFontDirFinder.  It
should hopefully now be able to detect fonts that have been installed under
user home directory (i.e. ~/Library/Fonts).  Please try this patch out on your
system Andreas.  I would encourage, maybe even urge ;-) someone to commit this
patch soon as it is a large patch that touches upon a number of files (see file
list) and is therefore likely to become out of date quickly with commits to the
repository.

Kind regards,

Adrian.

-- 
Configure bugmail: http://issues.apache.org/bugzilla/userprefs.cgi?tab=email
--- You are receiving this mail because: ---
You are the assignee for the bug, or are watching the assignee.

Re: Percentages in CommonAbsolutePosition?

[a_l . delmelle]

>- 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?

[Chris Bowditch]

[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?

[a_l . delmelle]

>- 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?

[Vincent Hennebert]

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