On Tue, 13 Sep 2005 01:26 am, Finn Bock wrote:
> > Manuel Mall wrote:
> >> yes, that is an option. What I am unsure about here is that the
> >> children, typically text areas, do not take the line spacing into
> >> account when reporting their bpd, that is the usually 10% space
> >> above and below the character. So what is the correct bpd for an
> >> fo:inline which has text area children: is it just the max bpd of
> >> its children or is it max bpd plus any line spacing settings from
> >> its parent?
> [Luca]
> > Oh, yes, the "half-leading" trait ...
> >
> > If I understand correctly the specs (4.5 Line areas) this line
> > spacing must be added to the bpd of each inline area too. As it is
> > the same for all inline areas, it could be stored into the
> > LayoutContext by the LineLM.
> I don't read it that way, instead the half-leading are set as
> space-[before|after] only on the line area, and are in some cases
> resolved with other surrounding spaces.
After reading the (what I think relevant) sections of the spec again I 
tend to agree with Finn.  Section 4.5 says in the 2nd paragraph that 
the half-leading value becomes space-before/after on the line area if 
the line stacking strategy is font-height or max-height.

We don't do that in the moment. It appears to me that we actually 
implement the "line-height" line-stacking-strategy by default which 
includes the half-leading values into the allocation. However, the spec 
says that "max-height" is the default line-stacking-strategy.

There are some other related issues. While inline areas don't have their 
own line-stacking-strategy their allocation rectangle size is 
determined by the lss on the containing block. We don't do that.

Inline areas have their own line-height trait which can be different to 
the line-height on the containing line area / containing block. 
line-height when specified on an inline fo has a different meaning, 
i.e. the inline area returned MUST have the exact line-height as 
specified, while line-height on a block level sets the minimum height 
for all decendant inline areas. We don't do any of that in the moment. 
Side note: in layout we don't know any more if a property is inherited 
or specified on that element, that could be a complication here. Finn, 
any thoughts on this?

What concerns me a bit about that is that I am unsure if the current 
design of the line layout can handle this. In simplified terms 
currently a block is "flattened" into a sequence of Knuth elements 
which the Line LM then breaks into lines. As part of that it calculates 
the line-height trait for the line but without knowledge of any 
line-height constraints on contained inlines as the Knuth elements 
carry only font type height information.

> regards,
> finn



Reply via email to