Re: fo:inline bpd
linearea bpd=11100 space-before=1650 space-after=1650 inlinearea bpd=9250 textarea font-size=10ptsome 10pt text/textarea inlinearea bpd=11100 textarea font-size=12ptsome 12pt text/textarea /inlinearea textarea font-size=10ptmore 10pt text/textarea /inlinearea linearea All the inline areas also have a line-height trait of 12000 but that is only used when lls=line-height [4.6]. [Manuel] Hmm, the line-height property would be normal everywhere which equates to 1.2 that means the trait would be 14400 for areas generated from fo elements with a font-size of 12pt and 12000 for areas generated from fo elements with a font-size of 10pt. But as you said it doesn't matter really unless lss is line-height. Your are right, my mistake. I believe the line-height trait should be 14400 for all the inline areas. Does it make sense? Yes it does. Does it also means the bpd doesn't bubble up in the case of nested inlines? So if we expand on the example of the nested inline above: fo:blockfo:inline font-size=10ptsome 10pt textfo:inline font-size=14ptsome 14 pt text/fo:inlinemore 10pt text/fo:inline/fo:block Does the line-area generated from that have a bpd corresponding to a 12pt font or 14 pt font (spec [4.5] for lss=max-height: block-progression-direction is the minimum required to enclose both the nominal-requested-line-rectangle and the allocation-rectangles of all the inline-areas stacked within the line-area)? I believe the bpd of the line area will correspond to the 14pt font because [4.5] talks about all the inline-areas. So the bpd on inlines does not bubble up the outer inlines, but it (and/or depth altitude) do bubble up to the calculation of line-rectangles on the line-area. Also, I think that makes sense. The nominal-requested-line-rectangle corresponds to a 12pt font. But is the area generated from the nested inline an inline-area stacked within the line-area or not? Stacked inline-areas must refer to all the desendents, not just the immediate children, see [4.6.1]. regards, finn
Re: fo:inline bpd
On Wed, 14 Sep 2005 03:12 pm, Finn Bock wrote: linearea bpd=11100 space-before=1650 space-after=1650 inlinearea bpd=9250 textarea font-size=10ptsome 10pt text/textarea inlinearea bpd=11100 textarea font-size=12ptsome 12pt text/textarea /inlinearea textarea font-size=10ptmore 10pt text/textarea /inlinearea linearea All the inline areas also have a line-height trait of 12000 but that is only used when lls=line-height [4.6]. [Manuel] Hmm, the line-height property would be normal everywhere which equates to 1.2 that means the trait would be 14400 for areas generated from fo elements with a font-size of 12pt and 12000 for areas generated from fo elements with a font-size of 10pt. But as you said it doesn't matter really unless lss is line-height. Your are right, my mistake. I believe the line-height trait should be 14400 for all the inline areas. Why do you say that the line-height trait should be the same for all areas? In the line-height case the specified value (1.2) is inherited not the computed value. Therefore I was assuming that on the areas generated from fo elements with font-size=10pt the line-height trait would be 12000. Does it make sense? Yes it does. Does it also means the bpd doesn't bubble up in the case of nested inlines? So if we expand on the example of the nested inline above: fo:blockfo:inline font-size=10ptsome 10pt textfo:inline font-size=14ptsome 14 pt text/fo:inlinemore 10pt text/fo:inline/fo:block Does the line-area generated from that have a bpd corresponding to a 12pt font or 14 pt font (spec [4.5] for lss=max-height: block-progression-direction is the minimum required to enclose both the nominal-requested-line-rectangle and the allocation-rectangles of all the inline-areas stacked within the line-area)? I believe the bpd of the line area will correspond to the 14pt font because [4.5] talks about all the inline-areas. So the bpd on inlines does not bubble up the outer inlines, but it (and/or depth altitude) do bubble up to the calculation of line-rectangles on the line-area. Also, I think that makes sense. OK, happy to proceed on that basis. For what its worth I did a quick test against xep and it seems to behave as you suggested Finn. The nominal-requested-line-rectangle corresponds to a 12pt font. But is the area generated from the nested inline an inline-area stacked within the line-area or not? Stacked inline-areas must refer to all the desendents, not just the immediate children, see [4.6.1]. regards, finn BTW, thanks for your patience in this exchange Finn. Certainly clarified things for me. Manuel
Re: fo:inline bpd
[Manuel] 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? You mean the phrases: If the property is set on an inline-level element, it specifies ... is only used when the line-height property is explicitly set on inline-level? If the line-height is inherited then that paragraph isn't operative? If that is the case, then line-height is the only(?) property that isn't using the specified value. Strange. But is it not a big deal, the inline-level .bind() method will have to check if the line-height is explicit set: lineHeightExplicit = pList.getExplicit(PR_LINE_HEIGHT); which is then non-null is the property is set on the element. However it is a huge deviation from the rest of the properties. regards, finn
Re: fo:inline bpd
On Tue, 13 Sep 2005 04:12 pm, Finn Bock wrote: [Manuel] 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? You mean the phrases: If the property is set on an inline-level element, it specifies ... is only used when the line-height property is explicitly set on inline-level? If the line-height is inherited then that paragraph isn't operative? Yes that's how I read it because otherwise the sentence If the property is set on an inline-level element, it specifies ... doesn't make sense to me. As the property is always implicitly set so this must mean explicit. Do you (or anyone else) understand that differently? If that is the case, then line-height is the only(?) property that isn't using the specified value. Strange. But is it not a big deal, the inline-level .bind() method will have to check if the line-height is explicit set: lineHeightExplicit = pList.getExplicit(PR_LINE_HEIGHT); which is then non-null is the property is set on the element. However it is a huge deviation from the rest of the properties. Yes it appears to be. regards, finn Manuel
Re: fo:inline bpd
[Manuel] Any way, back to the topic at hand. Lets assume the following fo: fo:blockfo:inline font-size=10ptsome 10pt textfo:inline font-size=12ptsome 12 pt text/fo:inlinemore 10pt text/fo:inline/fo:block In this case the line-height everywhere is normal which is equivalent to 1.2em. The innermost fo:inline will return an area with a bpd of 12pt. However, the outer fo:inline has a smaller font and as the line-height spec on an inline element is binding it can only return areas of 10pt bpd therefore cutting off part of the inner fo:inline. So our area tree (assuming it all fits on one line) in fop terminology would look like: linearea bpd=1 space-before=1200 space-after=1200 inlinearea bpd=1 textarea font-size=10ptsome 10pt text/textarea inlinearea bpd=12000 textarea font-size=12ptsome 12pt text/textarea /inlinearea textarea font-size=10ptmore 10pt text/textarea /inlinearea linearea Right, except the 1 and 12000 values should be text-altitude + text-depth: linearea bpd=11100 space-before=1650 space-after=1650 inlinearea bpd=9250 textarea font-size=10ptsome 10pt text/textarea inlinearea bpd=11100 textarea font-size=12ptsome 12pt text/textarea /inlinearea textarea font-size=10ptmore 10pt text/textarea /inlinearea linearea All the inline areas also have a line-height trait of 12000 but that is only used when lls=line-height [4.6]. In my interpretation as there is no explicit line-height spec on the inlines we get an area tree like: linearea bpd=12000 space-before=1200 space-after=1200 inlinearea bpd=12000 textarea font-size=10ptsome 10pt text/textarea inlinearea bpd=12000 textarea font-size=12ptsome 12pt text/textarea /inlinearea textarea font-size=10ptmore 10pt text/textarea /inlinearea linearea I have no idea whose right or wrong here or even which interpretation makes more sense. From [4.6]: An inline-area with inline-area children has a content-rectangle which extends from its dominant baseline (see [4.2.6 Font Baseline Tables]) by its text-depth in the block-progression-direction, and in the opposite direction by its text-altitude; So it appears that the bpd of an inline depends on the inline's font and not on the line-height property or the inline's children. Does it make sense? I have no idea what the spec means by [7.15.4]: If the property is set on an inline-level element, it specifies the exact height of each box generated by the element. because both set and box is undefined by the rest of the spec. The text is copied from CSS where it perhaps makes sense. regards, finn
Re: fo:inline bpd
On Wed, 14 Sep 2005 01:33 am, Finn Bock wrote: [Manuel] Any way, back to the topic at hand. Lets assume the following fo: fo:blockfo:inline font-size=10ptsome 10pt textfo:inline font-size=12ptsome 12 pt text/fo:inlinemore 10pt text/fo:inline/fo:block In this case the line-height everywhere is normal which is equivalent to 1.2em. The innermost fo:inline will return an area with a bpd of 12pt. However, the outer fo:inline has a smaller font and as the line-height spec on an inline element is binding it can only return areas of 10pt bpd therefore cutting off part of the inner fo:inline. So our area tree (assuming it all fits on one line) in fop terminology would look like: linearea bpd=1 space-before=1200 space-after=1200 inlinearea bpd=1 textarea font-size=10ptsome 10pt text/textarea inlinearea bpd=12000 textarea font-size=12ptsome 12pt text/textarea /inlinearea textarea font-size=10ptmore 10pt text/textarea /inlinearea linearea Right, except the 1 and 12000 values should be text-altitude + text-depth: Yes, of course - minor simplification on my part :-). linearea bpd=11100 space-before=1650 space-after=1650 inlinearea bpd=9250 textarea font-size=10ptsome 10pt text/textarea inlinearea bpd=11100 textarea font-size=12ptsome 12pt text/textarea /inlinearea textarea font-size=10ptmore 10pt text/textarea /inlinearea linearea All the inline areas also have a line-height trait of 12000 but that is only used when lls=line-height [4.6]. Hmm, the line-height property would be normal everywhere which equates to 1.2 that means the trait would be 14400 for areas generated from fo elements with a font-size of 12pt and 12000 for areas generated from fo elements with a font-size of 10pt. But as you said it doesn't matter really unless lss is line-height. In my interpretation as there is no explicit line-height spec on the inlines we get an area tree like: linearea bpd=12000 space-before=1200 space-after=1200 inlinearea bpd=12000 textarea font-size=10ptsome 10pt text/textarea inlinearea bpd=12000 textarea font-size=12ptsome 12pt text/textarea /inlinearea textarea font-size=10ptmore 10pt text/textarea /inlinearea linearea I have no idea whose right or wrong here or even which interpretation makes more sense. From [4.6]: An inline-area with inline-area children has a content-rectangle which extends from its dominant baseline (see [4.2.6 Font Baseline Tables]) by its text-depth in the block-progression-direction, and in the opposite direction by its text-altitude; So it appears that the bpd of an inline depends on the inline's font and not on the line-height property or the inline's children. Does it make sense? Yes it does. Does it also means the bpd doesn't bubble up in the case of nested inlines? So if we expand on the example of the nested inline above: fo:blockfo:inline font-size=10ptsome 10pt textfo:inline font-size=14ptsome 14 pt text/fo:inlinemore 10pt text/fo:inline/fo:block Does the line-area generated from that have a bpd corresponding to a 12pt font or 14 pt font (spec [4.5] for lss=max-height: block-progression-direction is the minimum required to enclose both the nominal-requested-line-rectangle and the allocation-rectangles of all the inline-areas stacked within the line-area)? The nominal-requested-line-rectangle corresponds to a 12pt font. But is the area generated from the nested inline an inline-area stacked within the line-area or not? Or is only the inline area generated from the outer inline an inline-area stacked within the line-area as the inner inline area is contained within the outer inline area and therefore not really stacked. If the second interpretation is correct the line-area would have a bpd corresponding to a 12pt font and only unnesting like: fo:blockfo:inline font-size=10ptsome 10pt text/fo:inlinefo:inline font-size=14ptsome 14 pt text/fo:inlinefo:inline font-size=10ptmore 10pt text/fo:inline/fo:block would give us a line-area with a bpd corresponding to a 14pt font. I have no idea what the spec means by [7.15.4]: If the property is set on an inline-level element, it specifies the exact height of each box generated by the element. because both set and box is undefined by the rest of the spec. The text is copied from CSS where it perhaps makes sense. OK, I agree its hard to make sense out of this. So lets just ignore this then for the time being. regards, finn Cheers Manuel
Re: fo:inline bpd
Luca, 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? Manuel On Mon, 12 Sep 2005 07:06 pm, Luca Furini wrote: Some days ago, Manuel Mall wrote: The problem is that the Inline LM doesn't calculate the dimension of the area it is suppose to construct from the subsequence given to it by the Line LM. Instead it just assumes the dimension of the line as given to it in the LayoutContext. However, to be able to do the required calculations the Inline LM would need access to the KnuthElements of the subsequence it is suppose to construct the area for. However, what's given to it is a sequence of KnuthPositions (the standard addAreas() interface) not elements. Maybe there is no need for the InlineLM to know the elements, or for the LineLM to compute the height of each inline: the LeafNodeLM (and its subclasses) already set their areas bpd according to the font ascender and descender. So, InlineLM.addAreas() could check the bpd of its inline children after adding them, and choose the larger one, which could be smaller than the line height. Or am I missing something important? Regards Luca
Re: fo:inline bpd
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? 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. Regards Luca
Re: fo:inline bpd
On Mon, 12 Sep 2005 07:52 pm, Luca Furini 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? 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. That's were it may get messy. The children of a fo:inline are not only text areas but also other fo:inline, fo:character, fo:page-number, ... as well as a possible fo:block. For some areas added one would need to add the half-leading trait for others not, depending on what generated the area. Regards Luca Cheers Manuel
Re: fo:inline bpd
Rather complex area, line building. One that is a little under-present in our testcases so far. I believe you're correct (comments in 4.6 and 7.15.4), but I have the impression that we'd actually need to look at this from a more general angle eventually. Not necessarily right now, of course. But it may be good to start building up test cases and the knowledge on all the advanced aspects of line building. On 06.09.2005 06:57:06 Manuel Mall wrote: Currently fop sets the bpd of areas created from fo:inlines to to line-height of the line the area appears in. For example: fo:block font-size=10ptSome text fo:inline font-size=8ptsmaller text/fo:inline/fo:block The inline parent area created for the fo:inline will be given a bpd of 12pt, i.e. the line-height of the surrounding block, and not 9.6pt which is the height of the fo:inline. The difference is visually noticeable to moment one applies backgrounds or borders/padding to the fo:inline. Am I correct in saying that the current implementation is incorrect and that the smaller bpd should be applied in the example above? Manuel Jeremias Maerki
Re: fo:inline bpd
On Tue, 6 Sep 2005 04:02 pm, Jeremias Maerki wrote: Rather complex area, line building. One that is a little under-present in our testcases so far. I believe you're correct (comments in 4.6 and 7.15.4), but I have the impression that we'd actually need to look at this from a more general angle eventually. Not necessarily right now, of course. But it may be good to start building up test cases and the knowledge on all the advanced aspects of line building. I seemed to have a bad run here :-). Whenever I poke my nose into something lately the response seems to be: That's a very difficult subject which needs more investigation... Just joking - please don't take this as a complaint. Yes, the spec says that areas returned from fo:inline have their own line-height trait which can be different to the line-height trait of the line area they belong to. We don't do that currently. At a high level the algorithm seems to look like: Collect all the Knuth sequences. Break them into lines - this also determines the line dimensions (line height, baseline, ...). For each line determine the subsequences which belong to the same child LM and give those to the child LMs for area construction. The problem is that the Inline LM doesn't calculate the dimension of the area it is suppose to construct from the subsequence given to it by the Line LM. Instead it just assumes the dimension of the line as given to it in the LayoutContext. However, to be able to do the required calculations the Inline LM would need access to the KnuthElements of the subsequence it is suppose to construct the area for. However, what's given to it is a sequence of KnuthPositions (the standard addAreas() interface) not elements. Alternatively the Line LM could calculate the dimensions of the line segment the Inline LM is suppose to construct. It may actually be appropriate to do that in the Line LM as it already has the relevant logic. But still we would need an interface to get this across to the Inline LM. On 06.09.2005 06:57:06 Manuel Mall wrote: Currently fop sets the bpd of areas created from fo:inlines to to line-height of the line the area appears in. For example: fo:block font-size=10ptSome text fo:inline font-size=8ptsmaller text/fo:inline/fo:block The inline parent area created for the fo:inline will be given a bpd of 12pt, i.e. the line-height of the surrounding block, and not 9.6pt which is the height of the fo:inline. The difference is visually noticeable to moment one applies backgrounds or borders/padding to the fo:inline. Am I correct in saying that the current implementation is incorrect and that the smaller bpd should be applied in the example above? Manuel Jeremias Maerki Manuel
