Hi Andreas

On 17.05.2005 23:24:55 Andreas L. Delmelle wrote:
> > -----Original Message-----
> >
> 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

> The only real hard work in layout would be limited to the two difficult
> cases --breaks/spans--, but exactly because only these two would need to be
> handled during layout, they would become clearly outlined in the code
> --and because the lion's share of the decisions are already made before the
> LMs kick off, even this 'hard work' could turn out to be quite
> straightforward.

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.

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.

I get the impression that you're trying to solve a problem that is
already solved, but if you find a better solution (i.e. one that makes
the code faster and/or less memory consuming and/or clearer/easier) then
I'm all for it. I've taken the straight-forward approach creating a data
structure (grid units in EffRows) where I have all the information

> What would it mean for layout if large parts of the 'determineWinner()'
> functionality would actually shift somewhere to the Property subsystem and
> the FOTree (? where they are ultimately still accessible to Layout if
> needed?)

For layout, probably not much. It simply gets its information from a
different source. But going down this road I don't see how you solve
border resolution for break conditions.

Anyway, I designed the CollapsingBorderModel and subclass (one
additional subclass to be added later for collapse-with-precedence) so
it is completely isolated from the other layout code and can easily be
used for both non-break and break conditions.

> Anyway, the more I read the parts in the XSL-FO and CSS Rec about borders,
> the more I get the impression that the collapsing model works:
> - partly on the level of the bare properties/FOTree
>   the question: which borders are dominant in the general cases?

That's the question you came up with to optimize border resolution. As I
said, that might be helpful. My current implementation dumbly takes all
sources together, every time.

> - and partly on the level of layout
>   the question: what is the size of the space assigned
>                 to the applicable borders in this case?

This I don't get. Sorry.

> ATM it's only a thought. Just checking to see if, in anyone's opinion, it
> would be worth digging deeper into... if treating the above two questions
> separately helps to avoid (or even merely alleviate) certain headaches, all
> the better.

We should ask a pharma company for sponsoring. As a nice side-effect we
might get free headache pills for the team. :-)

Joke aside, if you see a way to make the current approach considerably
faster and less wasteful, then yes, it's worth digging deeper. But
before you do that, make sure you understand what the collapsing model
together with break conditions have as consequence for the table stepper.
On the paper (i.e. in our example on the Wiki) the problem is already
solved. What I had trouble with was not the border resolution, but the
step after that. I guess it should be functionality before speed,
especially when most of the issues are already solved in some way.


Jeremias Maerki

Reply via email to