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
