https://issues.apache.org/bugzilla/show_bug.cgi?id=37579





--- Comment #51 from Vincent Hennebert <[EMAIL PROTECTED]>  2008-05-28 08:48:08 
PST ---
(In reply to comment #48)
> (In reply to comment #27)
> > (In reply to comment #26)
> > At the point where getBaseLength() fails, the ancestor tree looks like:
> > 
> > FlowLayoutManager
> > -> FootnoteBodyLM
> > 
> > So, the LM is reparented (in PageBreaker, line 166), and somewhere after 
> > that,
> > we get a call to PercentLength.getValue(footnoteBodyLayoutManager)
> 
> AFAIU the reason why FootnoteBodyLM is re-parented is that it put its areas at
> the right place (as children of the footnote-reference-area, instead of the
> block containing the footnote). Simply moving the setParent call after the 
> call
> to getNextKnuthElements makes the warnings disappear, and doesn't break any
> test.

This is more complicated than that. For most of the properties that can take a
percentage value, the percentage refers to the containing area's (or nearest
ancestor reference area's) ipd or bpd. The only notable exception is font-size,
which refers to the parent element.

So if we take end-indent, for instance, if it's not specified inside
footnote-body, then it takes the /computed/ value of the parent element (e.g.,
the block containing the footnote). /But/ if it has a specified percentage
value, then the percentage shall be resolved against the
footnote-reference-area. In many cases this will lead to the same result, but
not when footnotes are declared inside lists, tables, block-containers, or if
the region-body has several columns, etc.

This issue is not related to lists and tables only, but is more general. If
PageBreaker is left as is, then percentages specified inside footnotes should
resolve correctly, but not inherited values. If we move the setParent call like
explained above, then this is the other way around...


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

Reply via email to