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 Cheers Manuel
