You are viewing a plain text version of this content. The canonical link for it is here.
Posted to fop-dev@xmlgraphics.apache.org by Andreas L Delmelle <a_...@pandora.be> on 2006/12/24 09:53:19 UTC
Open issue: table-columns from first row?
Hi all,
Since two replies I sent to Simon's posts seemed to end up in
oblivion, I'll post it as a new message.
Concerns the following issue:
[Simon:]
Uncertain status. The linked bug is resolved, but the description does
not match the description of the bug:
<li>
Omitting fo:table-column or having fo:table-column without a
column-width
and attempting to create columns implicitly from the first
table row is not implemented, yet (<a href="http://
issues.apache.org/bugzilla/show_bug.cgi?id=35656">Bugzilla #35656</a>).
</li>
Just had another look, and it currently only works correctly in case
there is no column-spanning going on in any of the cells in the first
row.
<fo:table>
<fo:table-body>
<fo:table-cell width="2in" number-columns-spanned="2">
...
In this case, two implicit columns are created, but the cell's width
is not yet distributed over the two columns.
I'll add a testcase demonstrating what still goes wrong, but the
issue probably needs to put in a slightly different wording,
indicating that it works apart from the above reservation.
Cheers,
Andreas
Re: Open issue: table-columns from first row?
Posted by Andreas L Delmelle <a_...@pandora.be>.
On Jan 3, 2007, at 10:17, Vincent Hennebert wrote:
Hi Vincent,
<snip />
>>> <fo:table>
>>> <fo:table-body>
>>> <fo:table-cell width="2in" number-columns-spanned="2">
>>> ...
>>>
>>> In this case, two implicit columns are created, but the cell's width
>>> is not yet distributed over the two columns.
>>>
>>> I'll add a testcase demonstrating what still goes wrong, but the
>>> issue
>>> probably needs to put in a slightly different wording, indicating
>>> that
>>> it works apart from the above reservation.
>
> I'm curious about your testcase, actually, because after quick
> testing I
> haven't been able to reproduce it (attached fo file, first table,
> works
> fine).
I see two possibilities:
Either the layoutengine fully compensates for this, or it just
happens to go unnoticed since you have a specified absolute width of
7.5cm for the whole table.
I think I'll put my money on the latter.
Explanation:
By the time layout starts, we'll actually have three table-columns,
all with a default width of 'proportional-column-width(1)' (= FOP's
proprietary default, as this is not mandated by the XSL-FO Rec; the
Rec says the initial value is 'auto' which comes down to the same
thing).
Try setting the table's width to 10cm. If all would go as expected,
we'd have to end up with two columns of 2.5cm and one of 5cm. FOP
currently makes them all about 3.33cm, I think...
>> In the meantime, I've locally patched FOP to correctly deal with
>> this.
>>
>> Patch consists of a few changes in TableBody, TableRow and
>> PercentLength. The latter only because I needed to have some way
>> to be
>> able to get the percentage value of the cell-width, divide it by the
>> number of columns spanned, and construct a new PercentLength with the
>> percentage distributed over the number of columns.
>>
>> Full patch below.
>
> No objection, some code was obviously lacking at that place, anyway
> (nothing done when colspan != 1).
For absolute widths, it is not so much of a hassle to distribute the
widths. When it came to the percentages, however, I began to slow
down... It seems a pesky job to create correct relative-numerics: the
percentages themselves are actually rather simple --percentage value
of the original cell divided by the column-span. It's creating the
LengthBase to go with it that I'm still struggling with (a percentage
of what?)
Not unsolvable, but a bit more work than that tiny patch I proposed
at first.
> That made me think of the testcase showed in the second table in the
> attached file. There is a colspan on the first row, which sets the
> width
> of the first two columns. But we might want to refine that on the
> second
> row, by specifying a different width for each column individually.
> That
> testcase fails...
> WDYT?
Interesting idea, BUT...
One of the key intentions of the fixed table-layout algorithm is
precisely that a formatter is able to determine the column-widths for
the whole table based on the first row.
Strictly speaking, the behaviour you describe --to take into account
the second row as well-- would even violate the rules prescribed by CSS.
In 17.5.2, it says:
"In the fixed table layout algorithm, the width of each column is
determined as follows:
1) A column element with a value other than 'auto' for the 'width'
property sets the width for that column.
2) Otherwise, a cell in the first row with a value other than 'auto'
for the 'width' property sets the width for that column. If the cell
spans more than one column, the width is divided over the columns.
3) Any remaining columns equally divide the remaining horizontal
table space (minus borders or cell spacing)."
In your example, I'd say that following the Rec means ignoring any
width attributes on cells that are not in the first row. The widths
in the second row are not supposed to have any effect.
Cheers,
Andreas
Re: Open issue: table-columns from first row?
Posted by Vincent Hennebert <vi...@anyware-tech.com>.
Hi Andreas,
Andreas L Delmelle a écrit :
> On Dec 24, 2006, at 09:53, Andreas L Delmelle wrote:
>
> <snip />
>> Just had another look, and it currently only works correctly in case
>> there is no column-spanning going on in any of the cells in the first
>> row.
>>
>> <fo:table>
>> <fo:table-body>
>> <fo:table-cell width="2in" number-columns-spanned="2">
>> ...
>>
>> In this case, two implicit columns are created, but the cell's width
>> is not yet distributed over the two columns.
>>
>> I'll add a testcase demonstrating what still goes wrong, but the issue
>> probably needs to put in a slightly different wording, indicating that
>> it works apart from the above reservation.
I'm curious about your testcase, actually, because after quick testing I
haven't been able to reproduce it (attached fo file, first table, works
fine).
> In the meantime, I've locally patched FOP to correctly deal with this.
>
> Patch consists of a few changes in TableBody, TableRow and
> PercentLength. The latter only because I needed to have some way to be
> able to get the percentage value of the cell-width, divide it by the
> number of columns spanned, and construct a new PercentLength with the
> percentage distributed over the number of columns.
>
> Full patch below.
No objection, some code was obviously lacking at that place, anyway
(nothing done when colspan != 1).
That made me think of the testcase showed in the second table in the
attached file. There is a colspan on the first row, which sets the width
of the first two columns. But we might want to refine that on the second
row, by specifying a different width for each column individually. That
testcase fails...
WDYT?
<snip/>
Vincent
Re: Open issue: table-columns from first row?
Posted by Andreas L Delmelle <a_...@pandora.be>.
On Dec 24, 2006, at 09:53, Andreas L Delmelle wrote:
<snip />
> Just had another look, and it currently only works correctly in
> case there is no column-spanning going on in any of the cells in
> the first row.
>
> <fo:table>
> <fo:table-body>
> <fo:table-cell width="2in" number-columns-spanned="2">
> ...
>
> In this case, two implicit columns are created, but the cell's
> width is not yet distributed over the two columns.
>
> I'll add a testcase demonstrating what still goes wrong, but the
> issue probably needs to put in a slightly different wording,
> indicating that it works apart from the above reservation.
In the meantime, I've locally patched FOP to correctly deal with this.
Patch consists of a few changes in TableBody, TableRow and
PercentLength. The latter only because I needed to have some way to
be able to get the percentage value of the cell-width, divide it by
the number of columns spanned, and construct a new PercentLength with
the percentage distributed over the number of columns.
Full patch below.
If no one objects, I'll commit this to the trunk and the release
branch, so this issue is out of the way.
Cheers,
Andreas
Index: src/java/org/apache/fop/fo/flow/TableBody.java
===================================================================
--- src/java/org/apache/fop/fo/flow/TableBody.java (revision
489884)
+++ src/java/org/apache/fop/fo/flow/TableBody.java (working copy)
@@ -40,6 +40,9 @@
import org.apache.fop.fo.properties.CommonAural;
import org.apache.fop.fo.properties.CommonBorderPaddingBackground;
import org.apache.fop.fo.properties.CommonRelativePosition;
+import org.apache.fop.fo.properties.FixedLength;
+import org.apache.fop.fo.properties.LengthProperty;
+import org.apache.fop.fo.properties.PercentLength;
/**
* Class modelling the fo:table-body object.
@@ -80,7 +83,7 @@
/**
* @see FObj#bind(PropertyList)
*/
- public void bind(PropertyList pList) throws FOPException {
+ protected void bind(PropertyList pList) throws FOPException {
commonBorderPaddingBackground =
pList.getBorderPaddingBackgroundProps();
super.bind(pList);
//Used by convertCellsToRows()
@@ -201,9 +204,16 @@
int colSpan = cell.getNumberColumnsSpanned();
Length colWidth = null;
- if (cell.getWidth().getEnum() != EN_AUTO
- && colSpan == 1) {
- colWidth = cell.getWidth();
+ if (cell.getWidth().getEnum() != EN_AUTO) {
+ LengthProperty p = (LengthProperty)
cell.getWidth();
+ if (p instanceof FixedLength) {
+ colWidth = new FixedLength(p.getValue
() / colSpan);
+ } else if (p instanceof PercentLength) {
+ PercentLength pctLength =
(PercentLength) p;
+ double factor = pctLength.getPercentage
() / 100;
+ colWidth = new PercentLength(factor /
colSpan,
+ pctLength.getBaseLength());
+ }
}
for (int i = colNr; i < colNr + colSpan; ++i) {
Index: src/java/org/apache/fop/fo/flow/TableRow.java
===================================================================
--- src/java/org/apache/fop/fo/flow/TableRow.java (revision
489884)
+++ src/java/org/apache/fop/fo/flow/TableRow.java (working copy)
@@ -34,8 +34,11 @@
import org.apache.fop.fo.properties.CommonAural;
import org.apache.fop.fo.properties.CommonBorderPaddingBackground;
import org.apache.fop.fo.properties.CommonRelativePosition;
+import org.apache.fop.fo.properties.FixedLength;
import org.apache.fop.fo.properties.KeepProperty;
+import org.apache.fop.fo.properties.LengthProperty;
import org.apache.fop.fo.properties.LengthRangeProperty;
+import org.apache.fop.fo.properties.PercentLength;
/**
* Class modelling the fo:table-row object.
@@ -74,7 +77,7 @@
/**
* @see org.apache.fop.fo.FObj#bind(PropertyList)
*/
- public void bind(PropertyList pList) throws FOPException {
+ protected void bind(PropertyList pList) throws FOPException {
blockProgressionDimension
= pList.get
(PR_BLOCK_PROGRESSION_DIMENSION).getLengthRange();
commonBorderPaddingBackground =
pList.getBorderPaddingBackgroundProps();
@@ -133,9 +136,16 @@
int colSpan = cell.getNumberColumnsSpanned();
Length colWidth = null;
- if (cell.getWidth().getEnum() != EN_AUTO
- && colSpan == 1) {
- colWidth = cell.getWidth();
+ if (cell.getWidth().getEnum() != EN_AUTO) {
+ LengthProperty p = (LengthProperty) cell.getWidth
();
+ if (p instanceof FixedLength) {
+ colWidth = new FixedLength(p.getValue() /
colSpan);
+ } else if (p instanceof PercentLength) {
+ PercentLength pctLength = (PercentLength) p;
+ double factor = pctLength.getPercentage() /
100;
+ colWidth = new PercentLength(factor / colSpan,
+ pctLength.getBaseLength());
+ }
}
for (int i = colNr; i < colNr + colSpan; ++i) {
Index: src/java/org/apache/fop/fo/properties/PercentLength.java
===================================================================
--- src/java/org/apache/fop/fo/properties/PercentLength.java
(revision 489884)
+++ src/java/org/apache/fop/fo/properties/PercentLength.java
(working copy)
@@ -68,8 +68,8 @@
*
* @return the percentage value
*/
- protected double getPercentage() {
- return factor * 100;
+ public double getPercentage() {
+ return factor * 100.0;
}
/**