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 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? the paragraph right after your rephrased spec extract reads to me like it was in the original in the spec. I got the impression that you accept what's written in the spec but you still rephrase the spec but by doing that you change the meaning. And that's what confused me. > >> 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. Ok, but then that's dangerous as like in my case it lead me to believe that start-indent is not part of the whole thing. IMO, the wording in the spec is still the best way to describe what's going on. > >>> 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?! Actually your use of padding in your examples just adds > a parameter to the equations that I didn’t think of... > Re-thinking about it my opinion is that the only correct interpretation > is the following: for tables with the separate border model the borders > (traits) differ from the common case and are made of two components: > - the border property specified on the table; > - half of the border-separation. > If we consider that the formula above, applying to areas, is using > traits then that means that half of the border-separation should lie in > the margin, and the other half in the table’s content rectangle as it is > associated to cells. > If the formula above refers to properties, then that half of > border-separation should not lie in the margin as it would not be > included in the calculation. In the area tree the table’s padding would > be inserted /between/ the two halves of border-separation (see attached > picture, too confusing to just make ascii-art). 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. > 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 the spec carefully (much more carefully than yesterday), I would say that following the graphic you created would lead to the result described in the spec. BTW, going for user expectation is probably what causes most of the interoperability issues. Like with the indent inheritance problem. So that's dangerous. > >>>> Out of this follows: The following test cases have to be revisited: > >>>> table_border-collapse_separate_border-spacing_1.xml > >>>> table_border-collapse_separate_border-spacing_2.xml > >>> That’s quite strange because not specifying any margin on the table, you > >>> get the outer border in the margin (but the border-separation is > >>> currently not taken into account —indeed half of it is missing in the > >>> table’s outer border). > >> Yeah, that's where I noticed my mistake (the one of today). But if you > >> remove the margin, that simply resets the start-indent to its inherited > >> value which moves padding and border outside the visible area (or rather > >> the content rect of the main reference area. > >> > >>> As soon as you specify margin=0 like in the above > >>> testcases the layout goes wrong. Hmmm... > >> No, it's actually right. I seem to have designed the test that way. Now > >> that I've seen that I used "margin", everything's clear again. > > Agreed now, apart from the fact that half of the border-separation is > missing. Yes, or more specifically, half the border-separation contributed by the table is missing, not the half from the table-cells. Phew! :-) Jeremias Maerki
table-indented.fo
Description: Binary data
