-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

Hi all,

First of all: many, many thanks to Finn for taking care of the default border-precedence values!
Secondly: sorry for the rather long post.

This message is solely intended to keep you guys (and other interested parties) informed about my progress in this matter, and perhaps, more importantly, to give other devs the opportunity to yell 'STOP!' if they see something that could be considered a Very Bad Thing (as Java programming is still a leisure activity for me, it's all based on theory rather than hands-on experience).

Ok, here goes:

* The first step I took was moving much of the logic that is currently in CollapsingBorderModelEyeCatching (in the layout package) to CommonBorderPaddingBackground. More precisely: I created a subclass of the BorderInfo inner class. This subclass, TableBorderInfo, provides two versions of a collapse() method: one for eye-catching collapsing, and an overloaded one that allows for passing in precedence values. Their signatures are:

public void collapse( BorderInfo, boolean );
public void collapse( BorderInfo, boolean, int, int );

The idea here is to make this functionality available to the FOTree as well as Layout without moving essentially layout-related code into the FOTree (or vice versa). I'm not absolutely sure that subclassing BorderInfo is the appropriate approach, since the collapse() methods could just as easily be added to BorderInfo itself. Personally, I did this to make the distinction, as those methods do not apply to borders on non-table FOs (but in the end, the other FOs simply won't call this method, so there would be little harm in that). In any case, the ultimate goal is to have layout only access the collapse() methods for the situations where the FOTree lacks the necessary context. The most obvious ones: breaks, spans and multiple bodies. But for a simple table with one body that has no row- or column-spanning cells and that is small enough to fit on one page, layout would only read the border-info from the FOs appropriate for the given situation. The layout classes will still need to decide which FO is the appropriate one, but once that decision has been made, all they need to do is read the border-info and use the width (no additional comparison/collapsing needed). The collapse-method does not need to concern itself with which sides the borders are on, as this depends on the types of FO the borders belong to. (For example: when comparing header and body, the header's after-border needs to be compared to the body's before-border, but when comparing header and table, the pair is before/before) All it does is compare its BorderInfo instance to another that is being passed in, and modify the style/width/color values if and where necessary. The 'side' issue should be dealt with at another level. The primary function of the boolean parameter is to allow/prohibit the property values to be replaced by those of the BorderInfo that is being passed in as a parameter. If the parameter BorderInfo wins, it simply keeps its own set of values, and depending on this flag, forces these values onto the base BorderInfo for which collapse() was called. If the parameter BorderInfo loses, its values are *always* discarded and replaced. The boolean flag comes in handy, for example when Table.omitHeaderAtBreak() is true. When resolving border-conflicts between header and body, the body's border cannot be discarded/replaced since it could still be relevant for all but the first page (or column) that is spanned by the table.

This first step is as good as complete in my local sandbox.
[As a side-note: I'm also thinking of providing two getCollapsed() methods that return the winning BorderInfo instance instead of actually replacing one with the other. This might come in handy when the table has more than one body, and may also prove useful for the layout-classes, since it's not always desirable to actually change the BorderInfo.]

* I added a class named TableBorderConflictResolver to the fo.flow package. One of these will be instantiated for/enclosed by each Table instance that doesn't have separated borders. This class is currently under heavy construction, so I can't offer a lot of details yet. The main idea here is to provide a set of overloaded versions of a resolve() method that resolves the border-conflicts between the enclosing Table instance and its descendants (one parameter) or between two of the Table's descendants (two parameters). These methods are the ones that will sort out the 'sides' issue. They will call TableBorderInfo.collapse() for each pair of applicable sides (start/start, end/end, before/before, after/before etc.)

* Evidently, Table then needs to allow its descendants to use the TableBorderConflictResolver. I don't think this access needs to be public, as the layout-classes have access to the FOs BorderInfo, so they can call collapse() (or possibly getCollapsed()) directly when they need to.


Other ideas are still a bit too remote/vague for me to able to give an accurate description of them. I roughly see the resolving taking place in two phases: once before the FOEventHandler.startXXX() is fired, and once immediately before the endXXX() event. Those two phases each will consist of two stages: - - the first stage, called from TableBody/TableHeader/TableFooter, resolves border conflicts between Table/TableHeader/TableFooter/TableBody (and maybe TableColumn), so could be described as working downwards/inwards - - the second stage, called from TableCell, resolves the conflicts between TableCells/TableRow/TableColumn/TableBody, so works upwards/outwards


That's it for now. Probably more to follow during or after the weekend.

Cheers,

Andreas
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.1 (Darwin)

iD8DBQFDD1pZyHTbFO9b8aARAtrrAKDFXqdD+RVeTq+tlP7QqSCEDgp9nACfXI7M
xoA6intyi/edMxKXiMWHcfY=
=Pl9G
-----END PGP SIGNATURE-----

Reply via email to