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 2005/09/15 12:59:54 UTC
Initial values for column-number (commit still pending...)
Hi people,
Just finished implementing the initial values for the column-number
property.
(Subversion still complains about files remaining in conflict, though,
so I'll have to check those out first. Have to go now, but commit will
most likely follow tonight...)
All layout tests passed except for one, to which I had to make a slight
modification.
Test in question: table-cell_various-combinations.xml
Change made: added 'ends-row="true"' to all the cells
Although I can't find any reference in the Rec that enforces this, it
seemed to make sense. Initial value for ends-row is 'false', so I take
this to mean that if one wants one single cell per row, it necessarily
means that ends-row should be explicitly set to 'true' as well.
Question remains of course:
Can it be considered an error to have a cell with starts-row="true" if
there were previous cells, and the preceding cell didn't have
ends-row="true"? I'm inclined to say yes...
If so, this should probably be caught as early as possible.
Cheers,
Andreas
Re: Initial values for column-number (commit still pending...)
Posted by Andreas L Delmelle <a_...@pandora.be>.
On Sep 16, 2005, at 16:31, Andreas L Delmelle wrote:
> YES! Got it.
Ok, so I ended up thoroughly revising my approach, to account for the
starts-row/ends-row issue that was the topic of this thread.
One thing I also hadn't considered, but which I also succeeded in
dealing with now, is out-of-order column-numbers. The note in the Rec
about there not being a requirement for column-numbers to be
'monotonically increasing' also seems to imply that an author is
allowed, in theory, to do the following:
<fo:table>
<fo:table-column column-number="5" />
<fo:table-column column-number="2" />
<fo:table-column column-number="4" />
<fo:table-column column-number="3" />
<fo:table-column column-number="1" />
...
Admitted, I would never, ever do this myself, but it seems to be
permitted, so I thought I'd provide support for this anyway.
In the following case then
<fo:table>
<fo:table-column column-number="5" />
<fo:table-column column-number="2" />
<fo:table-column />
<fo:table-column />
<fo:table-column column-number="1" />
...
the column-numbers for the third and fourth column in the above
sequence would default to '3' and '4' respectively, just as the Rec
mandates: the column-number of the previous column plus one. (Note that
if the column-number of the second column weren't specified, this would
default to '6', and for the third and fourth, the initial values would
then become '7' and '8'...)
One more question before I can wrap this up (about tables without
explicit columns):
Should the number of implicit columns be considered body-per-body?
If not, and the table has no header, but it does have a footer, can the
first row of the footer be considered the basis for determining the
number of implicit columns?
Maybe a quite exotic case, which I personally would avoid, but you
never know...
Perhaps, this isn't even worth considering at that point. We could just
assign the column-numbers on row-per-row basis, and have layout
complain about this in case of fixed table-layout if a row that is not
the first one contains more cells than there are in the first row
(which currently already happens IIC?)
One other issue I didn't solve yet, but this was already a problem
before my modifications, is a specified column-number that is negative
or zero.
Note: one of the consequences of my modifications will be that a
zero-value will only occur in case it was explicitly specified by the
user. Again, I would personally avoid this at all costs, and make the
stylesheet such that this could never occur, but you never know...
According to the Rec, this is no real error. The column-number should,
in that case, be rounded to the nearest integer value greater than or
equal to 1 (which I personally would interpret as: the nearest
available non-occupied column-number). Currently, a PropertyException
is thrown for this in TableColumn.bind().
Now, it's a piece of cake to force the columnNumber instance variable
of the column in question, but in order to make it pass an eventual
FOTree test, this should be dealt with while creating the property
itself --so that it's already correct in the PropertyList. Maybe in
that case, I'd need to provide more than just a custom
PropertyMaker...?
Well, in order to evaluate that, it's probably best to wait until my
commit --finally-- comes through.
Cheers,
Andreas
Re: Initial values for column-number (commit still pending...)
Posted by Andreas L Delmelle <a_...@pandora.be>.
On Sep 16, 2005, at 16:00, Andreas L Delmelle wrote:
> Well, currently you both got me convinced about this. I'm working on
> it --but a bit frustrated, since that was really the *only* case where
> it failed. All other situations are handled nicely including
> row-spans... --even when a user would only use ends-row to indicate
> row-changes, all works as it should.
>
> And now this... Aarrrghh!! :-)
>
> Oh well, give it some time. I'm sure I'll come up with something.
YES! Got it. My initial approach placed too much emphasis on the
FObj.addChildNode() where it should have been handled in the custom
PropertyMaker itself...
Which goes to show: Talking/writing helps :-)
Just a few more lines of code to shift, a few tests to run, and this
can finally be committed.
*deep sigh*
Cheers,
Andreas
Re: Initial values for column-number (commit still pending...)
Posted by Andreas L Delmelle <a_...@pandora.be>.
On Sep 16, 2005, at 12:26, Finn Bock wrote:
> My take is that only a "true" value is used to determine a change in
> row. It makes no difference to the fo-tree or to layout if a default
> "false" or an explicit "false" is found.
FWIW: That was precisely my understanding too, hence my speaking of a
'contradiction'.
> [7.26.15]
> """
> The "starts-row" and "ends-row" properties with a "true" value are
> typically 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.
> """
>
> I found no indication that a "false" value can be used to prevent a
> row change, so there is IMO no real conflict if conflicting values are
> used on sibling cells.
Well, currently you both got me convinced about this. I'm working on it
--but a bit frustrated, since that was really the *only* case where it
failed. All other situations are handled nicely including row-spans...
--even when a user would only use ends-row to indicate row-changes, all
works as it should.
And now this... Aarrrghh!! :-)
Oh well, give it some time. I'm sure I'll come up with something. Have
already tried a quick hack, forcing the column-number, but then the
FOTree tests fail, because the value isn't correctly initialized in the
PropertyList itself (only the TableCell's instance variable is
altered).
Unfortunately no lookahead in the FOTree, otherwise I could just go
if( currentCell.endsRow() || nextCell.startsRow() ) {
//reset columnIndex
}
I'm beginning to see the advantages of XEP's approach to normalize
tables in a pre-processing XSL transform of the FO source document...
Anyway: thanks for your feedback.
Cheers,
Andreas
Re: Initial values for column-number (commit still pending...)
Posted by Finn Bock <bc...@worldonline.dk>.
[Jeremias and Andreas on starts-row & ends-row]
My take is that only a "true" value is used to determine a change in
row. It makes no difference to the fo-tree or to layout if a default
"false" or an explicit "false" is found.
[7.26.15]
"""
The "starts-row" and "ends-row" properties with a "true" value are
typically 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.
"""
I found no indication that a "false" value can be used to prevent a row
change, so there is IMO no real conflict if conflicting values are used
on sibling cells.
regards,
finn
Re: Initial values for column-number (commit still pending...)
Posted by Andreas L Delmelle <a_...@pandora.be>.
On Sep 16, 2005, at 12:15, Jeremias Maerki wrote:
> Absolutely no resentment here. I'm sorry for sending the wrong signals.
> I simply realized that I was not clear enough that the stuff I wrote is
> just my opinion. Stuff like that always happens if I don't want to lose
> too much time. Sigh.
Ok, I'm glad. I just tend to bring in a bit of humor at times, and
sometimes that comes across totally differently (more rudely) than I
intended.
<snip />
> I will probably dial down
> my efforts on FOP just a little bit when the first release is out.
> Don't
> worry: no plans to go a away!
Phew, that's a relief as well! I noticed that you were one of the few
people to actually respond to any of my questions/remarks, so far.
Wouldn't like to lose that. It would be like talking to myself :-)
<snip />
>> If you'd really hate to receive an error message, then don't do it.
>> It's as simple as that. You'll receive that error message once, and
>> you'll immediately know how to avoid it the next time, no?
>
> Yes, sure, but the problem is that in this case I think it's no error.
> I wonder what the others think about this. No other comments so far.
> :-( Everyone is probably avoiding another nasty thread. *bg*
That's probably the key to the above remark. Manuel recently apologized
for not being able to offer a viewpoint because he feared he was not
knowledgeable enough. I don't mind, I just like to hear/consider as
many viewpoints as possible. No matter if you have extensive knowledge
or not, just add any comments. Even if you think they don't help much,
someone else might just get the spark he needs to light the fire.
<snip />
>> So, I'm still wondering whether it wouldn't be more convenient --from
>> the POV of the implementor, not the user-- to simply consider it an
>> error.
>
> That's always dangerous IMO. We should always be focused on the user.
True enough. I'll keep trying to find a solution to it for the time
being.
>> The question remains: how many times does that happen in reality? Do
>> you, personally, use starts-row/ends-row very frequently?
>
> No. I always use table-row.
:-)
<snip />
>> All things considered, we definitely could be relaxing/forgiving for
>> the case where a cell has an explicit ends-row="true" and the next
>> cell
>> lacks an explicit starts-row="true"... I see no problem with that. On
>> the contrary, this would be dealt with automatically. If you'd really,
>> really hate to receive an error message in *that* case, you're really,
>> really going to love this.
>
> Yes, please. I think the idea behind the two properties was really
> simplifying the task for stylesheet developers so they can easily build
> up tables. Nobody will ever explicitely write a "false" value for the
> two properties into his stylesheet. He will only set a "true" value
> when
> he knows that he needs to start (or end) a row (depending on the
> stylesheet logic).
>
> Glen would say we should contact the FO WG for a clarification.
Good idea. FWIW: a quick Google on the topic didn't bring me any closer
to clarifying this issue. Examples seem to be very rare...
Cheers,
Andreas
Re: Initial values for column-number (commit still pending...)
Posted by Jeremias Maerki <de...@jeremias-maerki.ch>.
On 16.09.2005 11:43:37 Andreas L Delmelle wrote:
> On Sep 15, 2005, at 16:05, Jeremias Maerki wrote:
>
> Jeremias,
>
> > Ok, let me then explicitely state that my previous mail contained my
> > own
> > interpretation and no facts. IMO there are certain gaps and
> > inaccuracies
> > in the spec and I tried to take my own expectations and create an
> > interpretation that makes sense.
>
> I could be wrong about this, but I seem to be detecting a hint of
> resentment here. If so, and if this was caused in any way by something
> I said, or my unfortunate way of putting it, please note that the 'No
> offence' part was to be taken literally, really...
Absolutely no resentment here. I'm sorry for sending the wrong signals.
I simply realized that I was not clear enough that the stuff I wrote is
just my opinion. Stuff like that always happens if I don't want to lose
too much time. Sigh.
A fact is that I'm relatively tired. I've spent a lot of time on FOP and
on mailing lists lately and it can wear you out. A long time I made
myself think I had to chime in everywhere to make sure things are
running smoothly, but I'm quite happy to see that things have started to
run by themselves lately. It looks like my mission (and that of my
sponsor) to kickstart FOP again was a success. I will probably dial down
my efforts on FOP just a little bit when the first release is out. Don't
worry: no plans to go a away!
> As for myself, well, I'm quite used to people resenting it when they
> are confronted with facts that deviate from what they'd like to
> hear/see *sigh*
>
> Maybe it has to do with the fact that, from your POV, I'm bothering you
> with a minor issue, since it is "already solved".
Solved yes, but it's not clear if that interpretation was right. Maybe
I'm indeed wrong.
> True enough, it
> works, but IMO the place where this is dealt with is wrong. The
> layout-engine should be able to depend on the initial values for
> column-number instead of having to determine them itself. From the POV
> of layout, your interpretation doesn't pose much of a problem, because
> by that time the table's tree-structure is already fully known.
> I'm concerned with providing the correct initial values for the FObj
> *as* they are added to the tree. This has an advantage, since
> overlapping cells (an error according to the Rec) will be caught
> *before* layout begins for that page-sequence (more or less in the
> spirit of validation of the tree).
>
> (Besides that: providing these column-numbers in the FOTree is vital
> for my collapsing-border strategy, so I fear I'm not completely
> objective here ;-))
:-)
> > Let me just say that I would really,
> > really hate to receive an error message because I didn't specify an
> > ends-row="true" on the cell preceding the one I specified a
> > starts-row="true" on.
>
> Fair enough, but I feel compelled to add that personally, I just
> really, really hate to receive *any* error message whatsoever. I am
> reasonable enough, though, not to expect FOP --or any application for
> that matter-- to compensate for my own deficiencies, whether it be
> typos, laziness or plain stupidity. The line has to be drawn somewhere.
> If you'd really hate to receive an error message, then don't do it.
> It's as simple as that. You'll receive that error message once, and
> you'll immediately know how to avoid it the next time, no?
Yes, sure, but the problem is that in this case I think it's no error.
I wonder what the others think about this. No other comments so far.
:-( Everyone is probably avoiding another nasty thread. *bg*
> Still, I've postponed my commit, trying to come up with ways to
> accommodate you, but I'm having a bit of difficulty to reconcile
> determining the correct initial values for the column-number property
> with ignoring the initial values for other related properties (here:
> ends-row).
>
> Allow me to explain:
> For tables with cells as direct descendants of the table-body, my
> strategy depended on the value of the ends-row property to reset the
> TableBody's columnIndex to the first non-occupied column-number so that
> it is correct by the time the property system has to provide the
> default for the next TableCell. Made perfect sense to me...
> One idea I considered is adding a check to see whether the maximum
> number of columns has been exceeded when increasing the columnIndex.
> Things I don't really like about this:
> a) this would mean adding yet another instance variable to the Table or
> TableBody to keep track of the columnCount, since there is no guarantee
> that the table will have explicit columns (minor inconvenience)
> b) if the table doesn't have explicit columns, this could pose problems
> for the first row, since that's where that maximum column-number will
> have to be determined (so, this maximum will be exceeded for every
> cell) (difficult problem from the POV of the FOTree)
> c) even if I do get it to work, this would still break in case a given
> row doesn't have as many cells (including column-spans) as there are
> columns, and the mentioned contradiction between ends-row/starts-row
> occurs (difficult problem from the POV of the FOTree)
>
> So, I'm still wondering whether it wouldn't be more convenient --from
> the POV of the implementor, not the user-- to simply consider it an
> error.
That's always dangerous IMO. We should always be focused on the user.
> The question remains: how many times does that happen in reality? Do
> you, personally, use starts-row/ends-row very frequently?
No. I always use table-row.
> Well, I don't
> --since I was a 0.20.5 user, which didn't provide this functionality--,
> but when I do, I would tend to balance out starts-row/ends-row (because
> that is my interpretation of the Rec)
>
> All things considered, we definitely could be relaxing/forgiving for
> the case where a cell has an explicit ends-row="true" and the next cell
> lacks an explicit starts-row="true"... I see no problem with that. On
> the contrary, this would be dealt with automatically. If you'd really,
> really hate to receive an error message in *that* case, you're really,
> really going to love this.
Yes, please. I think the idea behind the two properties was really
simplifying the task for stylesheet developers so they can easily build
up tables. Nobody will ever explicitely write a "false" value for the
two properties into his stylesheet. He will only set a "true" value when
he knows that he needs to start (or end) a row (depending on the
stylesheet logic).
Glen would say we should contact the FO WG for a clarification.
Jeremias Maerki
Re: Initial values for column-number (commit still pending...)
Posted by Andreas L Delmelle <a_...@pandora.be>.
On Sep 15, 2005, at 16:05, Jeremias Maerki wrote:
Jeremias,
> Ok, let me then explicitely state that my previous mail contained my
> own
> interpretation and no facts. IMO there are certain gaps and
> inaccuracies
> in the spec and I tried to take my own expectations and create an
> interpretation that makes sense.
I could be wrong about this, but I seem to be detecting a hint of
resentment here. If so, and if this was caused in any way by something
I said, or my unfortunate way of putting it, please note that the 'No
offence' part was to be taken literally, really...
As for myself, well, I'm quite used to people resenting it when they
are confronted with facts that deviate from what they'd like to
hear/see *sigh*
Maybe it has to do with the fact that, from your POV, I'm bothering you
with a minor issue, since it is "already solved". True enough, it
works, but IMO the place where this is dealt with is wrong. The
layout-engine should be able to depend on the initial values for
column-number instead of having to determine them itself. From the POV
of layout, your interpretation doesn't pose much of a problem, because
by that time the table's tree-structure is already fully known.
I'm concerned with providing the correct initial values for the FObj
*as* they are added to the tree. This has an advantage, since
overlapping cells (an error according to the Rec) will be caught
*before* layout begins for that page-sequence (more or less in the
spirit of validation of the tree).
(Besides that: providing these column-numbers in the FOTree is vital
for my collapsing-border strategy, so I fear I'm not completely
objective here ;-))
> Let me just say that I would really,
> really hate to receive an error message because I didn't specify an
> ends-row="true" on the cell preceding the one I specified a
> starts-row="true" on.
Fair enough, but I feel compelled to add that personally, I just
really, really hate to receive *any* error message whatsoever. I am
reasonable enough, though, not to expect FOP --or any application for
that matter-- to compensate for my own deficiencies, whether it be
typos, laziness or plain stupidity. The line has to be drawn somewhere.
If you'd really hate to receive an error message, then don't do it.
It's as simple as that. You'll receive that error message once, and
you'll immediately know how to avoid it the next time, no?
Still, I've postponed my commit, trying to come up with ways to
accommodate you, but I'm having a bit of difficulty to reconcile
determining the correct initial values for the column-number property
with ignoring the initial values for other related properties (here:
ends-row).
Allow me to explain:
For tables with cells as direct descendants of the table-body, my
strategy depended on the value of the ends-row property to reset the
TableBody's columnIndex to the first non-occupied column-number so that
it is correct by the time the property system has to provide the
default for the next TableCell. Made perfect sense to me...
One idea I considered is adding a check to see whether the maximum
number of columns has been exceeded when increasing the columnIndex.
Things I don't really like about this:
a) this would mean adding yet another instance variable to the Table or
TableBody to keep track of the columnCount, since there is no guarantee
that the table will have explicit columns (minor inconvenience)
b) if the table doesn't have explicit columns, this could pose problems
for the first row, since that's where that maximum column-number will
have to be determined (so, this maximum will be exceeded for every
cell) (difficult problem from the POV of the FOTree)
c) even if I do get it to work, this would still break in case a given
row doesn't have as many cells (including column-spans) as there are
columns, and the mentioned contradiction between ends-row/starts-row
occurs (difficult problem from the POV of the FOTree)
So, I'm still wondering whether it wouldn't be more convenient --from
the POV of the implementor, not the user-- to simply consider it an
error.
The question remains: how many times does that happen in reality? Do
you, personally, use starts-row/ends-row very frequently? Well, I don't
--since I was a 0.20.5 user, which didn't provide this functionality--,
but when I do, I would tend to balance out starts-row/ends-row (because
that is my interpretation of the Rec)
All things considered, we definitely could be relaxing/forgiving for
the case where a cell has an explicit ends-row="true" and the next cell
lacks an explicit starts-row="true"... I see no problem with that. On
the contrary, this would be dealt with automatically. If you'd really,
really hate to receive an error message in *that* case, you're really,
really going to love this.
Cheers,
Andreas
Re: Initial values for column-number (commit still pending...)
Posted by Jeremias Maerki <de...@jeremias-maerki.ch>.
Ok, let me then explicitely state that my previous mail contained my own
interpretation and no facts. IMO there are certain gaps and inaccuracies
in the spec and I tried to take my own expectations and create an
interpretation that makes sense. Let me just say that I would really,
really hate to receive an error message because I didn't specify an
ends-row="true" on the cell preceding the one I specified a
starts-row="true" on.
On 15.09.2005 15:51:47 Andreas L Delmelle wrote:
> On Sep 15, 2005, at 13:50, Jeremias Maerki wrote:
>
> <snip />
> > But it should be clear that an explicitely defined property should
> > override the default on the other corresponding property.
>
> Hmmm... 'should be clear'? No offence, but that is interpretation, not
> fact.
>
> The term 'corresponding property' is clearly non-applicable here.
> Corresponding properties, as defined in the Rec, refer to properties of
> *one and the same* formatting object (i.e. one and the same
> table-cell).
>
> Fact: at the time the tree is constructed, when one cell is added, you
> don't know yet whether the next cell will have starts-row="true", so
> you *have to* assume "ends-row" will receive its initial value, which
> is "false".
> (IOW: It *is* clear that to assume otherwise would be an error )
>
> > 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,
>
> Here's where our interpretations differ the most, I guess. I see the
> initial values as replacements for non-specified values --in the sense
> that if a value is non-specified, any implementation should at least be
> able to depend on the property having the initial value.
> Also, initial values are a convenience for the end-user, in that the
> user doesn't need to specify explicit values if he/she is satisfied
> with the default.
>
> > ...it's a contradiction by the user. We probably need to look at these
> > properties like corresponding properties.
>
> Again: 'probably'? Interpretation, not fact.
>
> > 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.
>
> Why "bad"? At most, a minor inconvenience if one expects a processor to
> be forgiving WRT one's own absurdities (whether implicit or explicit)
> :-)
> At the very least, it would do away with any possible ambiguity...
>
> I'd be very interested to know what the competition (XEP/AntennaHouse)
> does in these cases. Will have a look later on.
>
> > I think the spec is simply not 100% unambiguous in the description.
>
> At least we agree on that :-)
>
>
> Cheers,
>
> Andreas
Jeremias Maerki
Re: Initial values for column-number (commit still pending...)
Posted by Andreas L Delmelle <a_...@pandora.be>.
On Sep 15, 2005, at 13:50, Jeremias Maerki wrote:
<snip />
> But it should be clear that an explicitely defined property should
> override the default on the other corresponding property.
Hmmm... 'should be clear'? No offence, but that is interpretation, not
fact.
The term 'corresponding property' is clearly non-applicable here.
Corresponding properties, as defined in the Rec, refer to properties of
*one and the same* formatting object (i.e. one and the same
table-cell).
Fact: at the time the tree is constructed, when one cell is added, you
don't know yet whether the next cell will have starts-row="true", so
you *have to* assume "ends-row" will receive its initial value, which
is "false".
(IOW: It *is* clear that to assume otherwise would be an error )
> 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,
Here's where our interpretations differ the most, I guess. I see the
initial values as replacements for non-specified values --in the sense
that if a value is non-specified, any implementation should at least be
able to depend on the property having the initial value.
Also, initial values are a convenience for the end-user, in that the
user doesn't need to specify explicit values if he/she is satisfied
with the default.
> ...it's a contradiction by the user. We probably need to look at these
> properties like corresponding properties.
Again: 'probably'? Interpretation, not fact.
> 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.
Why "bad"? At most, a minor inconvenience if one expects a processor to
be forgiving WRT one's own absurdities (whether implicit or explicit)
:-)
At the very least, it would do away with any possible ambiguity...
I'd be very interested to know what the competition (XEP/AntennaHouse)
does in these cases. Will have a look later on.
> I think the spec is simply not 100% unambiguous in the description.
At least we agree on that :-)
Cheers,
Andreas
Re: Initial values for column-number (commit still pending...)
Posted by Jeremias Maerki <de...@jeremias-maerki.ch>.
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
Re: Initial values for column-number (commit still pending...)
Posted by Andreas L Delmelle <a_...@pandora.be>.
On Sep 15, 2005, at 13:35, 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 mean, for instance:
6.7.8 fo:table-body
"...or alternatively fo:table-cell (one or more).
In the latter case cells are grouped into rows using the starts-row and
ends-row properties."
Note "and" not "or".
Cheers,
Andreas
Re: Initial values for column-number (commit still pending...)
Posted by Andreas L Delmelle <a_...@pandora.be>.
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...
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?
Cheers,
Andreas
Re: Initial values for column-number (commit still pending...)
Posted by Jeremias Maerki <de...@jeremias-maerki.ch>.
On 15.09.2005 12:59:54 Andreas L Delmelle wrote:
> Hi people,
>
> Just finished implementing the initial values for the column-number
> property.
> (Subversion still complains about files remaining in conflict, though,
> so I'll have to check those out first. Have to go now, but commit will
> most likely follow tonight...)
>
> All layout tests passed except for one, to which I had to make a slight
> modification.
>
> Test in question: table-cell_various-combinations.xml
> Change made: added 'ends-row="true"' to all the cells
>
> Although I can't find any reference in the Rec that enforces this, it
> seemed to make sense. Initial value for ends-row is 'false', so I take
> this to mean that if one wants one single cell per row, it necessarily
> means that ends-row should be explicitly set to 'true' as well.
>
> Question remains of course:
> Can it be considered an error to have a cell with starts-row="true" if
> there were previous cells, and the preceding cell didn't have
> ends-row="true"? I'm inclined to say yes...
> If so, this should probably be caught as early as possible.
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.
Jeremias Maerki