You are viewing a plain text version of this content. The canonical link for it is here.
Posted to fop-dev@xmlgraphics.apache.org by Andreas L Delmelle <a_...@pandora.be> on 2007/03/19 20:10:12 UTC
Percentages in CommonAbsolutePosition? (was: "Absolute positioning" one fop-users@)
Begin forwarded message:
> From: Andreas L Delmelle <a_...@pandora.be>
>
>> <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="0pt">1</
>>> 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.
Cheers,
Andreas
Re: Percentages in CommonAbsolutePosition?
Posted by Jeremias Maerki <de...@jeremias-maerki.ch>.
On 20.03.2007 11:56:10 a_l.delmelle wrote:
> >----- Oorspronkelijk bericht -----
> >Van: Vincent Hennebert [mailto:vincent.hennebert@anyware-tech.com]
>
> >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?
Posted by Vincent Hennebert <vi...@anyware-tech.com>.
Hi,
Manuel Mall a écrit :
> On Tuesday 20 March 2007 04:10, Andreas L Delmelle wrote:
<snip/>
>> 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@)
Posted by Manuel Mall <ma...@apache.org>.
On Tuesday 20 March 2007 04:10, Andreas L Delmelle wrote:
> Begin forwarded message:
> > From: Andreas L Delmelle <a_...@pandora.be>
> >
> >> <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="0pt">1</
> >>> 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