RE: More collapsing borders... (RE: cvs commit: xml-fop/src/java/org/apache/fop/layoutmgr/table TableContentLayoutManager.java)
-Original Message- From: Jeremias Maerki [mailto:[EMAIL PROTECTED] Hi, (OK, apologies for my alias turning up... Completely unintended. here's the remainder of the response. Other comments, much longer than the previous one...) On 17.05.2005 23:24:55 Andreas L. Delmelle wrote: snip / The current fact that there's an explicit reference to the border-*styles* in an essentially layout-related class... Well, somehow it does not sit completely right with me --could be a matter of taste, but IMO, layout needs to concern itself only with sizes... That was a natural outcome since there are certain specialities in the collapse model. If you look closely there's a little special case where the collapsed border between two cells has the same style and width but potentially different colors. If you follow through the rules 1 to 5 you end up in rule 5 solid 0.5pt red specified in one cell, solid 0.5pt green in the neighbouring cell. See table-border-collapse1.xml in testcases for an example. There's no rule that says how to decide which of the two wins. Very good point! Still, I would argue in that case that the layout engine only needs to know that the border is going to be 0.5pt wide in case of no breaks/spans. It is, strictly speaking, only when rendering the borders that the implementation has to know for sure which colour to use. If we are at liberty to determine that rule ourselves, I would obviously feel much for an approach like 'before/start cell wins' or 'after/end cell loses', and this as early in the process as possible. That would be very convenient. Another idea is to use the color value to decide, or if you really want a nasty solution that is bound to turn up in a bug report: XOR the color values. A bug?? Shame on you for having no sense of humour! Read the CSS Spec and study your table-border source very closely. It's *all* in there! :-) Furthermore, looking at those rules again, you will see that the style is used to determine winners, styles having implicit precedence values. Yes, but this could also be done when creating the FObjs --the styles map to a numeric constant anyway. If we place them in the right precedence-order in the Constants interface(*), we might not even need to assign precedence values in a separate step. We'd directly use the integer value they map to...? That's why you need them aside from having to pipe such information through to the addAreas() stage where the traits are set. So, I would seem to disagree? Up until the 'aside from': the _latter_ part is obviously necessary... If you're talking about the border resolution you can't avoid looking at the style, too. After that, in the table stepper, only the widths are relevant. Getting hotter, I feel it! :-) snip / I still think you're not quite where I am. Take the following methods: - TableContentLayoutManager.resolveNormalBeforeAfterBordersForRowGroup() - TableRowIterator.resolveStartEndBorders() These are the two isolated places where the border resolution for non-break cases are done. After that, the table stepper simply fetches the table widths from the grid units to do the right calculations. ... and a large part of what happens in the above two methods --in the background-- would already be dealt with in the FOTree, so the *only* parts of the code remaining there would be dealing with the break-cases and the span-cases. Very layout-specific stuff indeed! Quite simply put: if a GridUnit corresponds with exactly one TableCell, in a collapsing model, the *only* border-widths you'd really need to take into account would be those of its TableCell. The rest I see as ruled out at that point, *unless* in the following three cases - after-border = still need to compare that to the Cell/GridUnit immediately below - row/column-spans = check the appropriate TableRow/TableColumn for start- or end-borders - page-breaks = check the TableBody/-Header/-Footer for the before- or after-borders The part where I gave up for now was how exactly to handle the border resolution for break situations and how to bring the values into the overall calculation. Resolution to be done by layout in the break-situations would come down to: * First, compare after-border with GridUnit below. This step is always taken (see above) and yields the after-border in no-break situation. The dominant border is used in the following step. * Then, only before- or after-borders matter here, so either the current GridUnits' TableCell (possibly corrected through the first step) or the TableBody/-Header/-Footer will yield the right border-width. Resolution between TableCell and TableRow would already have been handled in the FOTree. Same goes for the resolution between TableColumn and TableBody/-Header/-Footer. If the order of fo:table-header, -footer and -body is enforced by the Rec --so, header and footer *have* to appear before body in the FO source--, then the same could be
Re: More collapsing borders... (RE: cvs commit: xml-fop/src/java/org/apache/fop/layoutmgr/table TableContentLayoutManager.java)
Hi Andreas On 17.05.2005 23:24:55 Andreas L. Delmelle wrote: -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] Hi Jeremias and others interested in table-borders, (Sorry for the --again-- long post, but...) The following comment in the code (TCLM) got me wondering... //Create empty grid units to hold resolved borders of neighbouring cells //TODO maybe this needs to be done differently (and sooner) ... if we're on the same frequency here --and to avoid re-inventing the wheel ;-) Have you also considered --even if only partly-- normalizing table borders during the FOTree-building? (Or do you only mean 'sooner' in the layout process?) I meant sooner in the layout process, i.e. in the TableRowIterator. I added that in in a sort of ad-hoc fashion when I needed to fix the problem of grid units not being present. This is something I'm still pondering over, as, for instance the following fragment (supposing a collapsing model, easy case: no borders specified higher up): fo:table-row border=solid 4pt fo:table-cell border=solid 2pt !-- block content -- /fo:table-cell !-- more cells -- /fo:table-row fo:table-row fo:table-cell border=solid 3pt !-- block content -- /fo:table-cell !-- more cells -- /fo:table-row AFAICT could be expanded in one go into: (I'm not completely sure, but aren't the shorthands expanded internally? If so, can we use that to our advantage?) AFAIK, they are expanded while setting up the CommonBorderPaddingBackground instances in the FO nodes. This class is already mutable so you could, in theory, manipulate the instances held by the FO nodes. A bigger problem, one I'm working around by working on the grid unit list, is the addition of cells to the FO tree if that's necessary. I experimented with this in another place and dropped it because of the property expansion mechanism. fo:table-row border-before=solid 4pt border-after=solid 4pt border-start=solid 4pt border-end=solid 4pt fo:table-cell border-before=solid 4pt border-after=solid 4pt border-start=solid 4pt border-end=... !-- block content -- /fo:table-cell !-- more cells -- /fo:table-row fo:table-row border-before=solid 4pt border-start=solid 3pt fo:table-cell border-before=solid 4pt border-after=solid 3pt border-start=solid 3pt border-end=... !-- block content -- /fo:table-cell !-- more cells -- /fo:table-row Well, apart from a few liberties I may have taken here, I think the idea is clear enough that, *if* this could be pulled off, this may greatly simplify the related portions in the layout code... Greatly simplified or simply done elsewhere? I keep coming back to handling break cases. Two places in which borders are resolved remain, nonetheless (break vs. non-break). Evidently, at that point we would only be able to compare with cells that were previously read --events already occured--, so at first sight it only solves part of the problem, but anyway... In the simplest cases --i.e. no breaks and no spans-- the right border-widths need only be _read_ by the LM from the FObjs, and the LM only needs to decide whether to add (separated borders) or take into account the one with the highest precedence (collapsing borders). Further motivation: in principle, only the widths of the borders should be relevant to the layout code. That's true, if by layout code you mean only the table stepper, i.e. the generation of the combined element list. The current fact that there's an explicit reference to the border-*styles* in an essentially layout-related class... Well, somehow it does not sit completely right with me --could be a matter of taste, but IMO, layout needs to concern itself only with sizes... That was a natural outcome since there are certain specialities in the collapse model. If you look closely there's a little special case where the collapsed border between two cells has the same style and width but potentially different colors. If you follow through the rules 1 to 5 you end up in rule 5 solid 0.5pt red specified in one cell, solid 0.5pt green in the neighbouring cell. See table-border-collapse1.xml in testcases for an example. There's no rule that says how to decide which of the two wins. Furthermore, looking at those rules again, you will see that the style is used to determine winners, styles having implicit precedence values. That's why you need them aside from having to pipe such information through to the addAreas() stage where the traits are set. If you're talking about the border resolution you can't avoid looking at the style, too. After that, in the table stepper, only the widths are relevant. The only real hard work in layout would be limited to the two difficult cases --breaks/spans--, but
