Re: Border-separation half in margin-start/end?
On 28.11.2007 17:28:04 Vincent Hennebert wrote: Hi Jeremias, Thanks for your patience... but I’m still not convinced ;-) Jeremias Maerki wrote: For illustration I have attached an FO file that shows different scenarios with some explanations. This renders correctly in FOP 0.94. There's really no mistake anywhere that I can detect. Well I see two problems: - the second table goes too far in the right margin. IIUC the inner edge of the border-end should coincide with the region-body. Or this is the other way around: the layout of the table would be ok but then it would be wrong for the previous block when adding width=100% on it; it should then also stick out in the margin. By reading the rule for percentage on IPD I’m suddenly not so sure anymore. Right, there seems to be something wrong on the right side. I actually didn't pay attention to the right side at all when I built the example. I also only specified margin-left but no margin-right. But even with margin-right set to 0pt, the table bleeds out of the main reference area, but that's (probably) because of a priority conflict between the inline-progression-dimension property (width=100%) and the indents which restrict the size of the content rectangle. But reading again the CSS text for fixed table layout (which is active in this case), I would say that the end-indent is really overruled here and that FOP behaves correctly in this case. You'd have to specify width=100% - 2 * 5pt for the second table to be like the block above the second table. So this behaviour is correct IMO. - there is still missing half of the border-separation around the row of the last table, should it be in the margin or not. Here's where you seem to be right. I just didn't realize it somehow but there's really just no half border-separation from the table, only from the table-cells. D'oh! Look at the new last table in the updated example. It makes it more obvious. Your graphic really helped me realizing that. Looks like your earlier suggestion about additional graphics may indeed not be a bad idea in some cases. Oh, stupid me! Everything's alright like it is. I didn't notice that there is a margin=0pt in the test case. With a border of 5pt, that sets the start-indent to 5pt and that's why the border is inside the content rectangle of the main reference area. margin=0 has a complex mapping to start-indent. margin is not taken directly for indent calculations. It's always mapped to start-indent. And we're only working with start-indent internally. See: http://www.w3.org/TR/xsl11/#refine-margin-space-indent Indeed, you’re right. snip/ Looks like you uncovered one of my past mistakes. Looking again at all this stuff, I have to agree that the table's outer border has to lie outside the table's content-rectangle, and that content-rectangle is inset relative to the parent reference area by start-indent. Like it happens with fo:block. Right now, fo:table (border-collapse=separate) behaves differently from fo:block. There's only a difference here if border-collapse is collapse, but not for the separate case. The stuff about the outermost grid boundary line is covered by the normal FO box model with the speciality that fo:table has no padding. http://www.w3.org/TR/xsl11/#area-stackblock Well I’ve never really understood that section since, to my knowledge, space-start doesn’t apply to block areas. I suspect you've fallen into the property vs. trait trap. start-indent is a trait which is indirectly set through the start-indent property on block-level FOs. The section is mainly about areas and therefore traits. I admit that I made some confusion between trait and property. But re-reading the spec, the question remains: start-indent is not a trait (doesn’t appear in section 4.2.2). space-start is a trait although it’s specified nowhere how its value should be set for block areas. I assume the start-indent property directly maps to the space-start trait. No, take a look at the graphic in http://www.w3.org/TR/xsl11/#area-stackblock. space-start = start-indent - border-start - padding-start. But then the formula still doesn’t make sense, since it is mixing traits and properties! If we consider that traits have already been mapped, then the start-indent and the space-start in the formula cancel each other and lead to the simplification I gave. There's no way around mixing the two if you want to convert from one world to the other. In the above equation that is: trait = property - property - property The formula makes sense only by replacing space-start with start-indent. The sentence would be rephrased like this: “the start-edge of its allocation-rectangle is parallel to the start-edge of the content-rectangle of R (where R is the closest ancestor reference-area of B), and offset from it inward by a distance equal to the
Re: Border-separation half in margin-start/end?
Hi Jeremias, I think we’re making progress ;-) Jeremias Maerki wrote: On 28.11.2007 17:28:04 Vincent Hennebert wrote: Jeremias Maerki wrote: For illustration I have attached an FO file that shows different scenarios with some explanations. This renders correctly in FOP 0.94. There's really no mistake anywhere that I can detect. Well I see two problems: - the second table goes too far in the right margin. IIUC the inner edge of the border-end should coincide with the region-body. Or this is the other way around: the layout of the table would be ok but then it would be wrong for the previous block when adding width=100% on it; it should then also stick out in the margin. By reading the rule for percentage on IPD I’m suddenly not so sure anymore. Right, there seems to be something wrong on the right side. I actually didn't pay attention to the right side at all when I built the example. I also only specified margin-left but no margin-right. But even with margin-right set to 0pt, the table bleeds out of the main reference area, but that's (probably) because of a priority conflict between the inline-progression-dimension property (width=100%) and the indents which restrict the size of the content rectangle. But reading again the CSS text for fixed table layout (which is active in this case), I would say that the end-indent is really overruled here and that FOP behaves correctly in this case. You'd have to specify width=100% - 2 * 5pt for the second table to be like the block above the second table. So this behaviour is correct IMO. Studying the spec more carefully I come to the same conclusion as you, but not the same explanation. First, width doesn’t apply to fo:block, so what I said above (“it should then also stick out in the margin”) is non-sense and damn me for adding yet another imprecision. The following: fo:block-container margin-left=0pt width=100% border=solid 5pt blue fo:blockThis is a block!/fo:block /fo:block-container fo:table margin-left=0pt margin-right=0pt table-layout=fixed width=100% border-collapse=separate border=solid 5pt red leads to the same amount of content sticking out in the margin, both for the block-container and the table. I think the explanation is to be found in the XSL Rec instead of CSS since width is mapped to either ipd or bpd. And section 5.3.4, “Overconstrained Geometry” gives the answer. In the present case end-indent is adjusted to a negative value (-10pt). At least that one is clear! snip/ The stuff about the outermost grid boundary line is covered by the normal FO box model with the speciality that fo:table has no padding. http://www.w3.org/TR/xsl11/#area-stackblock Well I’ve never really understood that section since, to my knowledge, space-start doesn’t apply to block areas. I suspect you've fallen into the property vs. trait trap. start-indent is a trait which is indirectly set through the start-indent property on block-level FOs. The section is mainly about areas and therefore traits. I admit that I made some confusion between trait and property. But re-reading the spec, the question remains: start-indent is not a trait (doesn’t appear in section 4.2.2). space-start is a trait although it’s specified nowhere how its value should be set for block areas. I assume the start-indent property directly maps to the space-start trait. No, take a look at the graphic in http://www.w3.org/TR/xsl11/#area-stackblock. space-start = start-indent - border-start - padding-start. But then the formula still doesn’t make sense, since it is mixing traits and properties! If we consider that traits have already been mapped, then the start-indent and the space-start in the formula cancel each other and lead to the simplification I gave. There's no way around mixing the two if you want to convert from one world to the other. In the above equation that is: trait = property - property - property So you assume that the border-start, padding-start and start-indent on the graphics are properties, while space-start would be a trait? Weird. Anyway, if we consider the formula deducted from the graphic: space-start(trait) = start-indent(property) - border-start(property) - padding-start(property) and insert it into the formula that I re-phrased: xa = start-indent(property) + start-intrusion-adjustment - border-start(trait) - padding-start(trait) - space-start(trait) = start-indent(property) + s-i-a - border-start(trait) - padding-start(trait) - start-indent(property) + border-start(property) + padding-start(property) where xa is the x-coordinate of the allocation-rectangle’s start-edge. If we forget writing mode changes we have the following relation with the content-rectangle: xa = xc - start-indent(property —start-indent is not a trait!) In the majority of cases the formula above will simplify to the following: xa =
Re: Border-separation half in margin-start/end?
On 29.11.2007 13:30:56 Vincent Hennebert wrote: snip/ Studying the spec more carefully I come to the same conclusion as you, but not the same explanation. First, width doesn’t apply to fo:block, so what I said above (“it should then also stick out in the margin”) is non-sense and damn me for adding yet another imprecision. The following: fo:block-container margin-left=0pt width=100% border=solid 5pt blue fo:blockThis is a block!/fo:block /fo:block-container fo:table margin-left=0pt margin-right=0pt table-layout=fixed width=100% border-collapse=separate border=solid 5pt red leads to the same amount of content sticking out in the margin, both for the block-container and the table. I think the explanation is to be found in the XSL Rec instead of CSS since width is mapped to either ipd or bpd. And section 5.3.4, “Overconstrained Geometry” gives the answer. In the present case end-indent is adjusted to a negative value (-10pt). Oh yeah, overconstrained geometry. Now that you mention it, I remember doing stuff in that area. My brain just flushes stuff out when it's not needed anymore for a long time. :-) At least that one is clear! snip/ As indicated above, you were right to notice a mistake on my side here. Your graphic is correct. Padding indeed lies between half the border-separation from the table and half the border-separation from the table-cells. So where should the outermost grid boundary line lie? This is consistent only if it coincides with the table’s padding, and thus has the sickness (oops... thickness) of the padding. I think that's the one remaining question and it's a good one. You know, I've just scanned the whole specification to see if I can find some enlightenment about the relationship between the table grid and the table's content rectangle. I haven't really found one. Also, grid boundary line is just used but not really defined. Intuitively, I'd say the normal box model applies and the table grid takes up exactly the area of the content rectangle (that's what I worked with). But the talk about the grid boundary line says something else. And that's probably exactly what causes the different interpretation. Almost sounds like another case for clarification with the XSL WG. :-/ Some day I'm going on a interoperability crusade for XSL Why does that smell like the HTML wars? ;-) Still, this contradicts with section 6.7.3 (fo:table) of the spec, which doesn’t say where the table’s padding should lie. Indeed it says: “The first [border component], which is placed with the inside edge coincident with the outermost table grid boundary line, has the width of half the value for the border-separation property.” But in the description of table-cell (section 6.7.10), it says: “The first [border component], which is placed with the outside edge coincident with the table grid boundary line, has the width of half the value for the border-separation trait.” And what about the padding? You got it right intuitively by adopting the normal box model. We could resort to user expectations, but the fact is I’m not sure what I would be expecting as a user... Perhaps the behaviour of XSL Formatter (not put half of the border-separation in the margin) is the most reasonable one. I don't have a working trial license of XSL formatter anymore so I can't check what exactly you mean. Anyway, after considering your input and See the simulation on the attached PDF. The formula for the table width would not be the same in each case... Thanks. snip/ Vincent Jeremias Maerki
Re: Border-separation half in margin-start/end?
Hi Jeremias, Thanks for your patience... but I’m still not convinced ;-) Jeremias Maerki wrote: For illustration I have attached an FO file that shows different scenarios with some explanations. This renders correctly in FOP 0.94. There's really no mistake anywhere that I can detect. Well I see two problems: - the second table goes too far in the right margin. IIUC the inner edge of the border-end should coincide with the region-body. Or this is the other way around: the layout of the table would be ok but then it would be wrong for the previous block when adding width=100% on it; it should then also stick out in the margin. By reading the rule for percentage on IPD I’m suddenly not so sure anymore. - there is still missing half of the border-separation around the row of the last table, should it be in the margin or not. Oh, stupid me! Everything's alright like it is. I didn't notice that there is a margin=0pt in the test case. With a border of 5pt, that sets the start-indent to 5pt and that's why the border is inside the content rectangle of the main reference area. margin=0 has a complex mapping to start-indent. margin is not taken directly for indent calculations. It's always mapped to start-indent. And we're only working with start-indent internally. See: http://www.w3.org/TR/xsl11/#refine-margin-space-indent Indeed, you’re right. snip/ Looks like you uncovered one of my past mistakes. Looking again at all this stuff, I have to agree that the table's outer border has to lie outside the table's content-rectangle, and that content-rectangle is inset relative to the parent reference area by start-indent. Like it happens with fo:block. Right now, fo:table (border-collapse=separate) behaves differently from fo:block. There's only a difference here if border-collapse is collapse, but not for the separate case. The stuff about the outermost grid boundary line is covered by the normal FO box model with the speciality that fo:table has no padding. http://www.w3.org/TR/xsl11/#area-stackblock Well I’ve never really understood that section since, to my knowledge, space-start doesn’t apply to block areas. I suspect you've fallen into the property vs. trait trap. start-indent is a trait which is indirectly set through the start-indent property on block-level FOs. The section is mainly about areas and therefore traits. I admit that I made some confusion between trait and property. But re-reading the spec, the question remains: start-indent is not a trait (doesn’t appear in section 4.2.2). space-start is a trait although it’s specified nowhere how its value should be set for block areas. I assume the start-indent property directly maps to the space-start trait. But then the formula still doesn’t make sense, since it is mixing traits and properties! If we consider that traits have already been mapped, then the start-indent and the space-start in the formula cancel each other and lead to the simplification I gave. The formula makes sense only by replacing space-start with start-indent. The sentence would be rephrased like this: “the start-edge of its allocation-rectangle is parallel to the start-edge of the content-rectangle of R (where R is the closest ancestor reference-area of B), and offset from it inward by a distance equal to the block-area's start-intrusion-adjustment (as defined below), minus its border-start and padding-start” Since (assuming writing modes are the same) the start-edge of the content rectangle is offset from the start-edge of the allocation rectangle inward by start-indent, that leads to a sensible result. Do you agree? Sorry, I don't get it. First, you rephrase the spec but go back to the explanation the spec gives in your comment afterwards. Which explanation? Anyway, your rephrased sentence sounds wrong to be as it only takes border and padding into the calculation but not the effects from start-indent/margin-left. Note that this sentence mentions the allocation-rectangle, whose start-edge is offset outward from the start-edge of the content-rectangle by the start-indent. So, indirectly, start-indent plays in the calculation. So according to you the outermost grid boundary line should coincide with the content rectangle? In which case, in addition to the table’s border, half of the border-separation should lie in the margin. This is also my interpretation but that’s not what XSL Formatter is doing. No, half the border-separation lies inside the content-rectangle. The border lies outside the content-rectangle. Or in other words: for the separate border model, the border-separation is part of the content-rectangle of the table, but the table's outer border is not. The specification is maybe a little unlucky since it uses the term border for border plus border-separation. But it specifies exactly where the two parts of the border will lie. Does it?!
