On 15.09.2005 13:35:20 Andreas L Delmelle wrote:
> On Sep 15, 2005, at 13:18, Jeremias Maerki wrote:
> 
> > There are no hints in the spec that indicate that the lack of an 
> > ends-row
> > is an error if someone uses starts-row. You can perfectly split a bag
> > full of cells into tables with only the starts-row or the ends-row
> > properties. These two properties are simply indicators to the
> > implementation where to split rows.
> 
> Indeed not, but the Rec does indicate that the two of them should be 
> used together...

I don't see that. It merely says:

"The "starts-row" and "ends-row" properties can be used when the input
data does not have elements containing the cells in each row, but
instead, for example, each row starts at elements of a particular type."

and

"...cells are grouped into rows using the starts-row and ends-row
properties."

It doesn't say that you have to use both.

> On top of that: not specifying ends-row seems to lead to a contradiction
> 
> <fo:table-cell starts-row="true">
> </fo:table-cell>
> <fo:table-cell starts-row="true">
> </fo:table-cell>
> 
> is the same as (due to initial value for ends-row)
> 
> <fo:table-cell starts-row="true" ends-row="false">
> </fo:table-cell>
> <fo:table-cell starts-row="true" ends-row="false">
> </fo:table-cell>
> 
> See what I mean?

Yes. But it should be clear that an explicitely defined property should
override the default on the other corresponding property. If ends-row on
the first cell and starts-row on the second cell were explicitely
defined like in your example, this would indeed be an error, but because
it's a contradiction by the user. We probably need to look at these
properties like corresponding properties. And we probably need to do
some kind of over-constrained relaxing giving "true" values the higher
priority. It would be bad IMO to force users to properly specify the
proper ends-row property whenever they use starts-row.

I think the spec is simply not 100% unambiguous in the description.

Jeremias Maerki

Reply via email to