Dear Wiki user, You have subscribed to a wiki page or wiki category on "Xmlgraphics-fop Wiki" for change notification.
The following page has been changed by VincentHennebert: http://wiki.apache.org/xmlgraphics-fop/TableLayout The comment on the change is: Small refreshing of the content to reflect the current situation ------------------------------------------------------------------------------ * the explicit BPD specified on cells and/or rows (*) * the resolved border width (see note below) - '''Note:''' Depending on the chosen break position the border width for the after edge of the cells (or rather grid units) in the last row before a table-footer may be different than without the table-footer present (the before edge of the table-footer has an influence). It also depends on whether a row is the last row or not (the after edge of the table and body have an influence). This has a consequence on the design of the table layout, meaning that the border resolution cannot simply be done before laying out the table. It has to be done on-the-fly as is subject to backtracking. + '''Note:''' Depending on the chosen break position the border width for the after edge of the cells (or rather grid units) in the last row before a table-footer may be different than without the table-footer present (the before edge of the table-footer has an influence). It also depends on whether a row is the last row or not (the after edge of the table and body have an influence). The border resolution can still be made at the FO tree building stage, but a grid unit must hold 3 possible values for its before and after border: + * one for the normal case (table unbroken); + * one for when it starts/ends a page (the table is broken just before/after its containing row); then the resolution must not include the preceding/following row, but must be made against the header/footer if any. + * one for the case where the break occurs ''inside'' the row; then the resolution is the same as in the previous point, plus the border conditionalities must be taken into account. == Notes on column spanning == - Column spanning is relatively easy. Each row manages a list of all grid units and their content. (See also {{{Row.CellInfo}}}) + Column spanning is relatively easy. Each row manages a list of all grid units and their content. (See also {{{o.a.f.fo.flow.table.FixedColRowGroupBuilder}}}) - - == Notes on row spanning == - - Layout for a cell spanning in row direction has to be started on the first row it occupies. The idea to defer layout to the last row occupied by a cell won't work since in the mean-time a page might be full and some of the content may already be needed on that page. That means that for collapsing border model the start and end borders for each grid unit have to be determined prior to starting layout (getNextBreakPoss) in the first row occupied by a cell. Each grid unit may have its own border and the widest of the border segments determines the left and right indent for the content rect. This makes it necessary to do a prefetching of rows in the body LM. For each of the prefetched rows the grid units are set up and the start and end border segments of each grid unit determined. The before and after border segments are later determined (and sometimes redetermined) during layout because these borders may depend on break decisions. == Illustrations == --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
