On Sun, Jan 15, 2006 at 11:56:54AM +0100, Andreas L Delmelle wrote:
>On Jan 12, 2006, at 21:55, gerhard oettl wrote:
>>>from  Andreas L. Delmelle
>>>I see you made the same mistake (?) in interpretation of the
>>>Rec that I initially made: the Rec states literally that "the
>>>column-number for a fo:table-column is 1 plus the column-number
>>>of the previous column"
>>Literaly you are absolutly right especially if reading the spec
>>to column-number (7.26.8) first. My main argument against this is
>>the description of number-columns-repeated (7.26.12) that says:
>Yeah, I remember we discussed this at the time I was implementing  
>these in the FOTree, 

I expected this and searched, but did not succeed.
The MARC archive findes nothing (but also not this thread) and the 
apache eyebrowse link points to a non-existent page. So if you
know the timeframe (some month more or less don't matter) where
I can look in the archive it would be nice to let me know.

>and we took this to be an inconsistency in the Rec...

Here I can fully agree. 
But the implementation of fop should not ;-) I can life with every
sight, but want to show some pros and cons and want to know which
part of the inconsitent Rec should be canceled to adopt the
from-table-column function.

I see the spec a little overcrowded here by trying to put two 
features into the table-column element in general and to the 
number-columns-spanned property in special:
I) background information (pointing to "column groups" in CSS2
   for determining the background - in the notes for fo:table)
II) as a container for informations that can be used by 

For II) it would be best to have all column-number /
number-columns-spanned pairs allowed (what was in contrast to the
table-cell spec not explicitly forbidden and what would mean to
have the same column-number used more than once) but I think it a
nightmare for I) because how to decide which background-color to use?
- and it was not explicitly allowed too.

On the other hand the "first fallback" described in the
from-table-column function (retry with
number-columns-spanned="1") is useless if every column-number can
only be used once. If there is a table-column with the same
column-number as the table-cell has you always end at this
table-column regardless of the number-columns-spanned on the
table-column or on the table-cell. It only would make sense if
there are more table-columns with the same column-number but with
different number-columns-spanned. Could make everything more
complicated than it is already ;-)

I am astonished that XSL 1.1 does not clarify anything here.

>The main issue, I think, that kept me from following the definition  
>under 7.26.12, is that you could end up with a situation where a  
>given table-cell has column-number="2", while there is no column that  
>has that column-number...
>In your example, the column-number "2" is not assigned to any column.  
>What would you do if a bit further down in the tree, there is a  
>fo:table-cell with column-number="2" ?

IMHO it should take the information from the spanned range, if it
spannes 1 column or otherwise the default value for the property in
question. My base is the (maybe also to freely interpreted) sentence
from 7.26.13 that says: 'For an fo:table-column the
"number-columns-spanned" property specifies the number of columns
spanned by table-cells that may use properties from this
fo:table-column formatting object using the from-table-column()
function.' - which i read "every cell that has a spanned range
(begincol to endcol) that is within the range spanned by the
table-column" - and which I used as "second fallback".

>With number-columns-repeated="N", you create the effect of separate  
>columns occupying column-numbers "I" to "I + N - 1", where I is the  
>initial-value (the parent FO's currentColumnIndex = the previous  
>column's number plus 1). I would distinguish number-columns- 
>spanned="M", precisely by having it not occupy M column indices. 

Though I argue against, I have to say that it is a fully legal
point of view.

>If not, what would be the point in having two separate properties?

Very right. This is a question I asked myself more than once without
any realy answer. The only case I could think where they differ is:
<fo:table-column column-number="1" number-columns-spanned="5"
<fo:table-column column-number="6" number-columns-spanned="2"/>
<fo:table-cell column-number="4" number-columns-spanned="3">
  <fo:block text-align="from-table-column()">

Here not all columns spanned by the cell (column 4 to 6) are
spanned by the first table-column definition and no table-column
with the column-number "4" exists (first fallback-rule for
from-table-colum), so it falls back to the default ("start").
With the current implementation of number-columns-repeated it
would end up with "center".

>Any table-cell having column-number="1" will occupy the first two  
>columns (because of number-columns-spanned="2" on its corresponding  
>table-column). If no cell has been assigned column-number="1", then a  
>cell having column-number="2" will occupy column 2 and the next,  
>whatever column-span (or column-number!) is specified on that next  

Sorry, but here I do not understand what you would like to
show. Neither with the current implementation nor by using the
explicit rule of 7.26.12 is the colspan of the table-cell
affected by the number-columns-spanned of the table-column.

Looks like I overrated the usefullness of the from-table-column
construct and it is hard to say goodby to all the possibilities I
saw there.

Nevertheless - the from-table-column patch follows (tomorrow).


 .''`.   gerhard oettl   on   Debian/Gnu Linux
: :'  :  
`. `'`   gpg key: 1024D/D59131AA 2002-06-18

Reply via email to