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

2005-03-02 Thread Simon Pepping 
On Tue, Mar 01, 2005 at 09:15:37PM -0800, Glen Mazza wrote:
 OH!!!  lightBulb state=on wattage=25/ 
 
 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 TableFooter.java

2005-03-02 Thread 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

2005-03-02 Thread Chris Bowditch 
Glen Mazza wrote:
Hi Glen,
OH!!!  lightBulb state=on wattage=25/ 

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 fo:table-body. 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

2005-03-01 Thread Glen Mazza 
OH!!!  lightBulb state=on wattage=25/ 

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
 
 snip/

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

2005-02-25 Thread Chris Bowditch 
Jeremias Maerki wrote:
On 25.02.2005 07:21:25 Glen Mazza wrote:
snip/
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
snip/

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

2005-02-25 Thread 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' 
(tdnbsp;/td vs. td /td) in order to function correctly.

Cheers!
Web Maestro Clay
--
[EMAIL PROTECTED] - http://homepage.mac.com/webmaestro/
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

2005-02-25 Thread 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:
 snip/
 
 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

2005-02-25 Thread 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

2005-02-25 Thread 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

2005-02-24 Thread 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

2005-02-24 Thread 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-devm=110922603225376w=2

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

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

2005-02-24 Thread Jeremias Maerki 

On 25.02.2005 07:21:25 Glen Mazza wrote:
snip/

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

2005-02-23 Thread 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]

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

2005-02-23 Thread 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=11028610291r=1w=2

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

2005-02-23 Thread 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