In
TablePlugin, the
databg
colors are shifted by one. Witness:
%TABLE{headerrows="1" footerrows="1" databg="#FFFF00,#FF0000,#33FF00,#FFFFFF"}%
|*A*|*B*|
|1|yellow|
|2|red|
|3|green|
|4|white|
|1|yellow|
|2|red|
|3|green|
|4|white|
|*D*|*E*|
yields
A |
B |
D |
E |
1 |
yellow |
2 |
red |
3 |
green |
4 |
white |
1 |
yellow |
2 |
red |
3 |
green |
4 |
white |
but one would expect
A |
B |
D |
E |
1 |
yellow |
2 |
red |
3 |
green |
4 |
white |
1 |
yellow |
2 |
red |
3 |
green |
4 |
white |
--
TW
The color sequence is correct if there are no header rows, e.g. the plugin needs to be made aware of header rows.
4 |
white |
1 |
yellow |
2 |
red |
3 |
green |
4 |
white |
1 |
yellow |
2 |
red |
3 |
green |
The spec can be tricky, what is considered a header row? A single cell can be a header cell. What if only some cells in a row are header cells?
Example:
1 |
one |
x |
10 |
ten |
x |
2 |
two |
x |
3 |
three |
x |
4 |
four |
x |
5 |
five |
x |
6 |
six |
x |
7 |
seven |
x |
8 |
eight |
x |
9 |
nine |
x |
--
PTh
You are right, but I think the solution is clear here: If you have an attribute
headerrows="1"
in the tag, that means there is 1 headerrow, etc. If there is no such attribute, I can accept that the result is not determined.
On the spec question, I do recall that somewhere in the code there is a definition that says: if all cells in a row are bolded, then it is considered a header row. --
TW
This is not a requirement. Changing to Enhancement.
What
would be the desired handling of colored rows?
AC
OK. I realized that I misunderstood "requirement" (I thought it meant "deviation from the specification").
But clearly this is a bug, not an enhancement. The spec describes that the colors for data rows are taken from the
databg
attribute. Clearly the user expects that the colors follow what was defined in this attribute.
The desired handling is that the data rows are colored in the order shown in the
databg
attribute, starting with the
first value matching the
first data row and continue on, restarting from the first value when there are more data rows than values in the attribute. The specification is undefined as to what happens when there are header rows interspersed in the data rows. --
TW
I do not see that this has been fixed. Reopening. --
TW
This has been fixed but your examples are out of date. The first table is now exactly as your example second table, but the current second table has changed along.
For each
complete header row, the color iteration is reset.
AC
I've switched the default color order as well (topic setting). Tables now should look the same as before the header color fix.
AC
This last change needs to be accounted for in
RenderFormTests.pm
(r12278).
HJ
4.1.0 released
KJL