Re: cvs commit: xml-fop/src/java/org/apache/fop/fo/flow TableBody.java

[Chris Bowditch]

Glen Mazza wrote:
Hi Glen,
OH!!!   

Yes, you're right, Chris--now I see the issue.  I
implemented validation for about 80% of the FOs, but
80% is not 100%.  fo:table-body never had any
validation implemented, hence the NPE's that were
occurring.  
I'm glad this issue has finally been resolved, thanks for taking the time to 
research a bit deeper.

Sorry, Jeremias, I thought you had just gratuitously
*removed* the validation from fo:table-body -- I
should have researched that it wasn't there to begin
with.
Well, that would have been a bit rude, but like you said there wasnt any 
validation on . Now hopefully we are all a bit more comfortable 
with the situation.

Thanks,
Glen
Chris

Re: cvs commit: xml-fop/src/java/org/apache/fop/fo/flow TableBody.java TableFooter.java

[Glen Mazza]

Thanks Simon.

Glen

--- [EMAIL PROTECTED] wrote:
>
> spepping2005/03/02 13:03:25
> 
>   Modified:src/java/org/apache/fop/fo/flow
> TableBody.java
> TableFooter.java
>   Log:
>   Corrected a validation problem. Made TableFooter
> use TableBody's validation.
>   

Re: cvs commit: xml-fop/src/java/org/apache/fop/fo/flow TableBody.java

[Simon Pepping]

On Tue, Mar 01, 2005 at 09:15:37PM -0800, Glen Mazza wrote:
> OH!!!   
> 
> Yes, you're right, Chris--now I see the issue.  I
> implemented validation for about 80% of the FOs, but
> 80% is not 100%.  fo:table-body never had any
> validation implemented, hence the NPE's that were
> occurring.  

Your new validation code invalidates valid fo files. If you would have
run the layoutengine tests, you would have noticed. The test file
table-body1.xml no longer passes. I have committed a correction. I
have also made TableFooter use TableBody's validation code, as
TableHeader does.

Regards, Simon

-- 
Simon Pepping
home page: http://www.leverkruid.nl

Re: cvs commit: xml-fop/src/java/org/apache/fop/fo/flow TableBody.java

[Glen Mazza]

OH!!!   

Yes, you're right, Chris--now I see the issue.  I
implemented validation for about 80% of the FOs, but
80% is not 100%.  fo:table-body never had any
validation implemented, hence the NPE's that were
occurring.  

Sorry, Jeremias, I thought you had just gratuitously
*removed* the validation from fo:table-body -- I
should have researched that it wasn't there to begin
with.

Thanks,
Glen


--- Chris Bowditch <[EMAIL PROTECTED]> wrote:
> 
> Glen:
> 
> All Jeremias was doing was changing the code to
> prevent a rather nasty NPE in 
> the event of an empty fo:table-body. Surely you
> cannot be arguging that the 
> NPE be restored?!?
> 
> Chris
> 
> 
> 
> 

Re: cvs commit: xml-fop/src/java/org/apache/fop/fo/flow TableBody.java

[Glen Mazza]

Simon,

Thanks for reading and responding to my concerns.  I
appreciate it.  Your endorsement of this change is
sufficient for me--I am withdrawing my veto.

Regards,
Glen

--- Simon Pepping <[EMAIL PROTECTED]> wrote:

> On Thu, Feb 24, 2005 at 10:21:25PM -0800, Glen Mazza
> wrote:
> > 
> > Jeremias, I'm going to veto (-1) your change.  I
> would
> > like the content model restored to the XSL
> standard
> > and the FONode.removeNode() method removed.
> 
> I support Jeremias' change, and vote +1.
>  

Re: cvs commit: xml-fop/src/java/org/apache/fop/fo/flow TableBody.java

[Simon Pepping]

On Thu, Feb 24, 2005 at 10:21:25PM -0800, Glen Mazza wrote:
> 
> Jeremias, I'm going to veto (-1) your change.  I would
> like the content model restored to the XSL standard
> and the FONode.removeNode() method removed.

I support Jeremias' change, and vote +1.
 
> Technical reasons:
> 
> 2.)  You failed to explain how an empty fo:table-body
> could possibly be of use to stylesheet writers, or how
> it would simplify their work.  I was able to debunk
> what you wrote in my response[2].  All you did say was
> that it is illegal and not useful, basically
> strengthening my argument.

An application should serve its users. It may try to educate them
regarding valid input, but it should not be obnoxious about it. If the
interpretation of the input is unequivocal, the application may warn
the user, but should continue. 

I am not sure that an empty table-body falls in this category. If the
other elements of a table are there, an empty table-body feels like a
genuine error, which may not silently be passed over. Especially for
unattended environments a warning is rather weak, and easily goes
unnoticed. Could this present users with documents in which tables are
missing without the author being aware of it?

On the other hand, if ignoring an empty table-body has been the actual
situation for a long time, this is not the time for Jeremias to change
that. Therefore, I am in favour of leaving Jeremias' change as it is,
and wait for someone else to implement a more proper solution.
 
> 3.)  As I explained to you, due to the new
> relationship between FO's and LM's, our architecture
> no longer supports FO's deciding whether or not to be
> attached to a LM.  I gave you the opportunity to
> discuss moving back to the older architecture, but you
> chose to ignore it--instead challenging me to find a
> better way.  That was my question: do we need to move
> back to the old method?

It is the task of the FO module to create a data structure that
represents the fo input, so that the LM module can use it as its input
for the layout. That data structure is the FO tree with the property
values. The FO module should do everything that is needed for this
task: validating input, sending corresponding warning or error
messages to the user, deciding that a piece of input does not require
representation in the data structure and possibly removing
corresponding data that has already been created. Therefore I believe
that FONode.removeChild() is a proper task for the FO module.

You have a tendency to react to other people's coding by saying that
this is not the ideal final solution. If a person is solving one
problem, he cannot solve all related problems at the same time. Such
problems can be tackled at another time, and perhaps by another team
member. So, please, do not say that a solution is not everything, but
take the opportunity and tackle the problem that remains. Or, if you
have no time, watch it sit there and suffer. :)
 
Regards, Simon

-- 
Simon Pepping
home page: http://www.leverkruid.nl

Re: cvs commit: xml-fop/src/java/org/apache/fop/fo/flow TableBody.java

[Glen Mazza]

Jeremias,

My veto still stands, along with the seven technical
reasons given for it.

Glen

--- Jeremias Maerki <[EMAIL PROTECTED]> wrote:

> 
> On 25.02.2005 07:21:25 Glen Mazza wrote:
> 
> 
> For the moment I'm not going to answer the veto
> itself. Your veto makes
> this situation a one against one. I have presented
> my reasons for the
> change and therefore, I request feedback from the
> rest of the committers
> on this matter even if it's just a short message.
> 
> > Jeremias, I gave you a full, thorough, and
> > respectfully written explanation of the issues
> > involved.  Not only did you mostly ignore it, but
> in
> > your response you chose to use my earlier smaller
> > email in order to give others the impression that
> I
> > had nothing more to say.  This is terrible
> leadership
> > on your part--railroading a change without
> discussion
> > and refusal to discuss the change afterwords.  I
> > simply can't support this behavior, hence my veto.
> 
> It may well be that I'm overreacting here. If that
> is so, then I'd like
> an honest feedback from additional members in the
> team. You must see
> that with your history I learned to treat your
> vetoes with caution
> because of the many times you changed a -1 to a +1
> later after a long
> discussion and a lot of power spent. There's tension
> between us two and
> that's bad. ATM I don't know how to resolve it. I
> tried to be as open as
> possible and to address any concerns you have. You
> have repeatedly
> brought very good points and for that I'm glad but
> you had to withdraw
> several vetoes after starting to realize that you
> were wrong and I've
> also seen behaviour from your part that I don't
> like. For example,
> starting sentences with "Mein Freund, bla bla" and
> then later accusing
> someone else in a different thread of being
> disrespectful. I didn't say
> anything about it then. (Also, apologies to Renaud
> for not speaking up.
> I didn't want to pour any oil into the fire at that
> time.) I tried to
> overlook that, but I have my limits. I sometimes
> wonder if you're not
> more of a blocker in this project than a pusher. I
> don't think I'm the
> only one thinking like this. You know what happend
> during the creation
> of the XML Graphics PMC.
> 
> > BTW, letting yourself be known to the W3C by
> writing
> > to them on occasion would appear to be a smart
> move
> > for you--I don't know why you are fighting this.
> 
> I'm not fighting this. I've had no compelling reason
> and spare time to
> do this, yet. The current issue is no reason for me
> to write anything to
> the WG.
> 
> Jeremias Maerki
> 
> 

Re: cvs commit: xml-fop/src/java/org/apache/fop/fo/flow TableBody.java

[The Web Maestro]

On Feb 24, 2005, at 10:21 PM, Glen Mazza wrote:
--- Jeremias Maerki <[EMAIL PROTECTED]> wrote:
I have nothing more to say about this. I want to
spend my time on more
productive things now.
Jeremias, I'm going to veto (-1) your change.  I would
like the content model restored to the XSL standard
and the FONode.removeNode() method removed.
The change gets a +1 from me.
I'm all for helping our community grow, and I believe that it takes a 
supportive environment for that to happen. Anything we can do to foster 
improvement can help, be it providing help on this list, or not scaring 
the bejeebers out of someone when we throw an NPE their way (a NPE? an 
NPE? who cares! :-)). Many of my early errors threw warnings instead of 
NPEs (overflowing table-cell content, unsupported [yet] attributes, 
etc.) helped me greatly. Some of them I chose to fix, and others I 
chose to ignore at the time, as the output worked.

I can understand the reasoning for a veto... As an avid reader of A 
List Apart, and some of the other gung-ho standards proselytizers, I 
respect the desire to have well-written code. At the same time, I also 
am guilty of throwing the occasional box-model hack or Mozilla-specific 
CSS extension into my CSS (e.g., -moz-border-radius-topright: 20px;).

However, I tend to err on the side of the supportive, hence my 
reasoning for supporting this change. I've long been annoyed that some 
browsers require a non-breaking space instead of a normal 'space' 
(  vs.  ) in order to function correctly.

Cheers!
Web Maestro Clay
--
<[EMAIL PROTECTED]> - 
My religion is simple. My religion is kindness.
- HH The 14th Dalai Lama of Tibet

Re: cvs commit: xml-fop/src/java/org/apache/fop/fo/flow TableBody.java

[Chris Bowditch]

Jeremias Maerki wrote:
On 25.02.2005 07:21:25 Glen Mazza wrote:

For the moment I'm not going to answer the veto itself. Your veto makes
this situation a one against one. I have presented my reasons for the
change and therefore, I request feedback from the rest of the committers
on this matter even if it's just a short message.
Jeremias:
your change gets +1 from me.
Glen:
All Jeremias was doing was changing the code to prevent a rather nasty NPE in 
the event of an empty fo:table-body. Surely you cannot be arguging that the 
NPE be restored?!?

Chris

Re: cvs commit: xml-fop/src/java/org/apache/fop/fo/flow TableBody.java

[Jeremias Maerki]

On 25.02.2005 07:21:25 Glen Mazza wrote:


For the moment I'm not going to answer the veto itself. Your veto makes
this situation a one against one. I have presented my reasons for the
change and therefore, I request feedback from the rest of the committers
on this matter even if it's just a short message.

> Jeremias, I gave you a full, thorough, and
> respectfully written explanation of the issues
> involved.  Not only did you mostly ignore it, but in
> your response you chose to use my earlier smaller
> email in order to give others the impression that I
> had nothing more to say.  This is terrible leadership
> on your part--railroading a change without discussion
> and refusal to discuss the change afterwords.  I
> simply can't support this behavior, hence my veto.

It may well be that I'm overreacting here. If that is so, then I'd like
an honest feedback from additional members in the team. You must see
that with your history I learned to treat your vetoes with caution
because of the many times you changed a -1 to a +1 later after a long
discussion and a lot of power spent. There's tension between us two and
that's bad. ATM I don't know how to resolve it. I tried to be as open as
possible and to address any concerns you have. You have repeatedly
brought very good points and for that I'm glad but you had to withdraw
several vetoes after starting to realize that you were wrong and I've
also seen behaviour from your part that I don't like. For example,
starting sentences with "Mein Freund, bla bla" and then later accusing
someone else in a different thread of being disrespectful. I didn't say
anything about it then. (Also, apologies to Renaud for not speaking up.
I didn't want to pour any oil into the fire at that time.) I tried to
overlook that, but I have my limits. I sometimes wonder if you're not
more of a blocker in this project than a pusher. I don't think I'm the
only one thinking like this. You know what happend during the creation
of the XML Graphics PMC.

> BTW, letting yourself be known to the W3C by writing
> to them on occasion would appear to be a smart move
> for you--I don't know why you are fighting this.

I'm not fighting this. I've had no compelling reason and spare time to
do this, yet. The current issue is no reason for me to write anything to
the WG.

Jeremias Maerki

Re: cvs commit: xml-fop/src/java/org/apache/fop/fo/flow TableBody.java

[Glen Mazza]

--- Jeremias Maerki <[EMAIL PROTECTED]> wrote:
>
> I have nothing more to say about this. I want to
> spend my time on more
> productive things now.
> 

Jeremias, I'm going to veto (-1) your change.  I would
like the content model restored to the XSL standard
and the FONode.removeNode() method removed.

Technical reasons:

1.)  Your content model change is not in agreement
with either the 1.0 or 1.1 spec.  You did not make a
request to the W3C recommending that they make the
change to the specification.  Our responsibility is to
implement the standard, if we need to diverge from it
we need to inform them first.

I already explained to you[1], via fo:wrapper and
fo:page-sequence-wrapper, that they already make
allowances in order to ease coding.  (Even though I
may not like those changes personally.)

We are not like a commercial product where we can just
ignore the content models, we have a charter and a
community responsibility to fulfill.

2.)  You failed to explain how an empty fo:table-body
could possibly be of use to stylesheet writers, or how
it would simplify their work.  I was able to debunk
what you wrote in my response[2].  All you did say was
that it is illegal and not useful, basically
strengthening my argument.

3.)  As I explained to you, due to the new
relationship between FO's and LM's, our architecture
no longer supports FO's deciding whether or not to be
attached to a LM.  I gave you the opportunity to
discuss moving back to the older architecture, but you
chose to ignore it--instead challenging me to find a
better way.  That was my question: do we need to move
back to the old method?

4.)  The change involved would leave vague of how to
implement a table header if there is no table-body,
worse, it would lead to abuse of the fo:table to just
have headers printed.  None of this is backed up by
the spec--we would be in fantasyland on how to
interpret fo:tables without fo:table-bodies.

5.)  You're relying a dubious distinction of strict
vs. relaxed validation, which has no basis in the
spec.  The content models for the FO's form the
contract of the language that the XSL processor is to
accept.  Not validating at the source requires more &
repeated checking downstream, clogging the logic in
those places, and creating far more sources of error. 
All this for an item that you yourself say is of no
practical use?

6.)  Adhering to the XSL model makes the Apache FOP
process the gold standard of validators--an XSL file
is not legitimate unless FOP accepts it.  Painting FOP
as a reference implementation will do wonders for us,
just as it has for Tomcat.  I *will* support
divergences from it, but we have to (1) discuss it
beforehand, (2) there has to be a legitimate reason
for it--not just saving someone a five-line XSLT
template that should be properly written anyway--(3)
and explain to the W3C our suggestion first.

7.)  I already implemented the official validation. 
You cannot remove it and then tell me if I want it I
have to reimplement it again in a different manner. 
The burden is on you for that.  Our validation unit
has to be able to support the spec.  

Jeremias, I gave you a full, thorough, and
respectfully written explanation of the issues
involved.  Not only did you mostly ignore it, but in
your response you chose to use my earlier smaller
email in order to give others the impression that I
had nothing more to say.  This is terrible leadership
on your part--railroading a change without discussion
and refusal to discuss the change afterwords.  I
simply can't support this behavior, hence my veto.

BTW, letting yourself be known to the W3C by writing
to them on occasion would appear to be a smart move
for you--I don't know why you are fighting this.

Glen

[1] 
http://marc.theaimsgroup.com/?l=fop-dev&m=110922603225376&w=2

[2]
http://marc.theaimsgroup.com/?l=fop-dev&m=110930040205336&w=2

Re: cvs commit: xml-fop/src/java/org/apache/fop/fo/flow TableBody.java

[Glen Mazza]

--- Jeremias Maerki <[EMAIL PROTECTED]> wrote:
>
> 2. Empty
> table-bodies make no
> sense but it makes life easier for stylesheet
> writers not to have to
> work around them.

I don't see the benefits.  In XSLT, one does a test to
see if there is data in the source XML that would
constitute a fo:table-row.  If so, then you activate a
template that creates the fo:table.  Next, within the
template that creates the fo:table (and assorted other
fo's including the fo:table-body), you call another
template for each fo:table-row.  This is standard XSLT
programming -- an empty fo:table-body wouldn't be
needed, and doesn't appear to be useful for the
developer.

If there aren't any to-be fo:table-rows in the input
XML, the template that creates the fo:table is never
called, and so there is no empty fo:table-body
necessary.

Glen

Re: cvs commit: xml-fop/src/java/org/apache/fop/fo/flow TableBody.java

[Jeremias Maerki]

FOP 0.20.5 ignores an empty table-body, no error message.
XEP 4 displays a validation error and continues.
AltSoft Xml2PDF does the same.
FOP CVS HEAD now does the same.

The justifications for both changes are in the commit message. If you
prefer a hard exception in the case of an empty table-body then add a
flag on the user agent for strict vs. relaxed validation testing.

As for removeChild(): Remove that method yourself and try to fix the
layout managers. You'll quickly see that my fix is probably the cleanest
and quickest solution for fixing the problem if we are to allow empty
table-bodies. It removes the trouble maker before it can cause any
problems in the layout engine.

And: As for suggesting a change in the spec. I don't want that. 1. We
have to cope with what we have: XSL 1.0. 2. Empty table-bodies make no
sense but it makes life easier for stylesheet writers not to have to
work around them.

I have nothing more to say about this. I want to spend my time on more
productive things now.

On 24.02.2005 00:01:05 Glen Mazza wrote:
> Jeremias,
> 
> This should not be done.  If someone has a problem
> with it--and I've never heard a complaint--they can
> send an email to xsl-editors, for them to adjust the
> content model for fo:table accordingly.  (If they
> don't, they don't.)
> 
> Note that the editors are very reasonable about
> this--for example, fo:page-sequence-wrapper and
> fo:wrapper are allowed to have no children for
> programmatic convenience, even though it doesn't make
> sense for these items to be empty.
> 
> BTW, what is FONode.removeChild() for anyway?  Why is
> this helpful--we haven't needed such a method for
> years.


Jeremias Maerki

Re: cvs commit: xml-fop/src/java/org/apache/fop/fo/flow TableBody.java

[Glen Mazza]

--- Glen Mazza <[EMAIL PROTECTED]> wrote:
>
> Jeremias,
> 
> This should not be done.  If someone has a problem
> with it--and I've never heard a complaint--they can
> send an email to xsl-editors, for them to adjust the
> content model for fo:table accordingly.  (If they
> don't, they don't.)
> 

To elaborate, I also frequently have problems with
certain content models, but what I do is send requests
to the xsl-editors list[1] when I have them (for
example, [2, #61], and several others).  I think it
would be best for you to do that before considering
making the change with FOP.  It may also encourage
others to endorse your suggestion on the ML.

But making the change without informing the W3C of
what you see as an error doesn't help improve the
standard.  Also, IMO we should be encouraging unhappy
users to register their complaints with the W3C so
that they will indeed make these changes.  (10, 15
complaints, they will!)  In this way, FOP plays the
role of a true reference implementation, with a nice
circular, ongoing feedback with the W3C, and all
FOP-accepted stylesheets will be guaranteed to work
with other processors.

We validate also to show newbie users what they are
doing wrong.  It gives nice correction and feedback to
the user, just like compilation errors in Java give
feedback to newbie developers.  Validation serves a
good purpose.

[1]
http://lists.w3.org/Archives/Public/xsl-editors/2005JanMar/

[2]
http://lists.w3.org/Archives/Public/xsl-editors/2005JanMar/0011.html


> Note that the editors are very reasonable about
> this--for example, fo:page-sequence-wrapper and
> fo:wrapper are allowed to have no children for
> programmatic convenience, even though it doesn't
> make
> sense for these items to be empty.
> 

And in #61, you can see I don't like empty
fo:page-sequence-wrappers or fo:wrappers either.  ;)


> BTW, what is FONode.removeChild() for anyway?  Why
> is
> this helpful--we haven't needed such a method for
> years.
> 

Sorry, I was wrong here--we have indeed needed such a
method, until about December ([3], emails 9, 7, 6). 
We used to have addLayoutManager() in the FO's in
which the FO would determine whether or not it was
empty, and if not, attach itself to a Layout Manager. 
(Email #9)  I kind of preferred this implementation,
as it allowed us to keep the internal state of each FO
internal, rather than need to expose its internal
variables to another object that would subsequently
read inside it to make the empty-or-not determination
for the FO.

Simon moved us away from that (Email #7 of [3])
because he didn't want the FO's to have knowledge of
layout managers, and wanted to move us from (1) having
the FO decide whether or not to attach itself to a LM
to (2) having a layout manager decide whether or not
to process an empty FO.  This is not my preferred
implementation, but it seems an acceptable
interpretation.

But your removeNode() function seems to be bouncing
back to the original implementation now: let the FO
decide.  Can we make a decision and settle on one or
the other here?  Do we really have to do both?

Also, my main problem with Simon's implementation, was
that (as mentioned above) the FO's needed to expose
their internal state more to the LayoutManagerMaker
object so the latter could determine if it needed to
process that FO.  I think Simon saw that a little as
well, and what I recommended in Email #6 was that we
have an boolean FONode.isEmpty() that the
LayoutManagerMakers can read, and if it returns true,
to not process the FO.  Question: can we use a boolean
isEmpty() instead of your removeNode()?  We can then
much better encapsulate each FO (i.e., instead of
having a LMM read variable a, b, and c of an FO to see
if it needs processing, it can just check isEmpty()).

Sorry for the long post.

Thanks,
Glen

[3] http://marc.theaimsgroup.com/?t=11028610291&r=1&w=2

Re: cvs commit: xml-fop/src/java/org/apache/fop/fo/flow TableBody.java

[Glen Mazza]

Jeremias,

This should not be done.  If someone has a problem
with it--and I've never heard a complaint--they can
send an email to xsl-editors, for them to adjust the
content model for fo:table accordingly.  (If they
don't, they don't.)

Note that the editors are very reasonable about
this--for example, fo:page-sequence-wrapper and
fo:wrapper are allowed to have no children for
programmatic convenience, even though it doesn't make
sense for these items to be empty.

BTW, what is FONode.removeChild() for anyway?  Why is
this helpful--we haven't needed such a method for
years.

Thanks,
Glen


--- [EMAIL PROTECTED] wrote:

> jeremias2005/02/23 14:04:01
> 
>   Modified:src/java/org/apache/fop/fo FObj.java
> FONode.java
>src/java/org/apache/fop/fo/flow
> TableBody.java
>   Log:
>   An empty table-body is illegal but we'll allow it
> to make things easier for stylesheet writers.
>   Empty table-body elements are removed from their
> parent so they can't cause any nasty effects in the
> LMs.
>   
>   Revision  ChangesPath
>   1.92  +7 -0 
> xml-fop/src/java/org/apache/fop/fo/FObj.java
>   
>   Index: FObj.java
>  
>
===
>   RCS file:
>
/home/cvs/xml-fop/src/java/org/apache/fop/fo/FObj.java,v
>   retrieving revision 1.91
>   retrieving revision 1.92
>   diff -u -r1.91 -r1.92
>   --- FObj.java   3 Feb 2005 08:18:27 -   1.91
>   +++ FObj.java   23 Feb 2005 22:04:01 -  1.92
>   @@ -170,6 +170,13 @@
>}
>}
>
>   +/** @see
>
org.apache.fop.fo.FONode#removeChild(org.apache.fop.fo.FONode)
> */
>   +public void removeChild(FONode child) {
>   +if (childNodes != null) {
>   +childNodes.remove(child);
>   +}
>   +}
>   +
>/**
> * Find the nearest parent, grandparent, etc.
> FONode that is also an FObj
> * @return FObj the nearest ancestor FONode
> that is an FObj
>   
>   
>   
>   1.54  +10 -0
> xml-fop/src/java/org/apache/fop/fo/FONode.java
>   
>   Index: FONode.java
>  
>
===
>   RCS file:
>
/home/cvs/xml-fop/src/java/org/apache/fop/fo/FONode.java,v
>   retrieving revision 1.53
>   retrieving revision 1.54
>   diff -u -r1.53 -r1.54
>   --- FONode.java 1 Feb 2005 21:21:28 -   1.53
>   +++ FONode.java 23 Feb 2005 22:04:01 -  1.54
>   @@ -198,6 +198,15 @@
>}
>
>/**
>   + * Removes a child node. Used by the child
> nodes to remove themselves, for
>   + * example table-body if it has no children.
>   + * @param child child node to be removed
>   + */
>   +public void removeChild(FONode child) {
>   +//nop
>   +}
>   +
>   +/**
> * @return the parent node of this node
> */
>public FONode getParent() {
>   @@ -410,5 +419,6 @@
>public int getNameId() {
>return Constants.FO_UNKNOWN_NODE;
>}
>   +
>}
>
>   
>   
>   
>   1.38  +8 -1 
>
xml-fop/src/java/org/apache/fop/fo/flow/TableBody.java
>   
>   Index: TableBody.java
>  
>
===
>   RCS file:
>
/home/cvs/xml-fop/src/java/org/apache/fop/fo/flow/TableBody.java,v
>   retrieving revision 1.37
>   retrieving revision 1.38
>   diff -u -r1.37 -r1.38
>   --- TableBody.java  21 Feb 2005 21:52:14 -  1.37
>   +++ TableBody.java  23 Feb 2005 22:04:01 -  1.38
>   @@ -88,6 +88,11 @@
> */
>protected void endOfNode() throws
> FOPException {
>getFOEventHandler().endBody(this);
>   +if (childNodes == null ||
> childNodes.size() == 0) {
>   +getLogger().error("fo:table-body must
> not be empty. "
>   ++ "Expected:
> (table-row+|table-cell+)");
>   +getParent().removeChild(this);
>   +}
>convertCellsToRows();
>}
>
>   @@ -98,7 +103,9 @@
> */
>private void convertCellsToRows() throws
> FOPException {
>try {
>   -if (childNodes.size() == 0 ||
> childNodes.get(0) instanceof TableRow) {
>   +if (childNodes == null 
>   +|| childNodes.size() == 0 
>   +|| childNodes.get(0)
> instanceof TableRow) {
>return;
>}
>//getLogger().debug("Converting cells
> to rows...");
>   
>   
>   
> 
>
-
> To unsubscribe, e-mail:
> [EMAIL PROTECTED]
> For additional commands, e-mail:
> [EMAIL PROTECTED]
> 
>