Re: svn commit: r289865 - in /xmlgraphics/fop/trunk/src/java/org/apache/fop: fo/ fo/flow/ fo/properties/ layoutmgr/table/

2005-09-19 Thread Jeremias Maerki

On 19.09.2005 23:19:46 Andreas L Delmelle wrote:
> On Sep 19, 2005, at 18:03, Andreas L Delmelle wrote:
> 
> > On Sep 19, 2005, at 11:08, Jeremias Maerki wrote:
> >
> >> Looks ok on first glance, though I've got a request: Would you please
> >> consider installing a checkstyle plug-in into your IDE and configuring
> >> the rules file for FOP? Thanks!
> >
> > Dammit! And I thought I had all bases covered... :-(
> >
> > My apologies for this. I hope it didn't cause too much inconvenience.
> 
> Ok, corrected most of my violations.

Thanks!

> BTW: is it necessary for the FOTree tests to have an Apache header as 
> well? Let me know, and I'll add them too...

Yes. http://www.apache.org/dev/apply-license.html says:

"The license is applied to each source file (code and documentation, but
excluding the LICENSE and NOTICE files) by including a short copyright
notice at the top, as demonstrated by the boilerplate notice provided in
the appendix."

In theory, all our files should have a license header where the format
allows it (i.e. it's obviously difficult for bitmap etc.).

Jeremias Maerki



Re: svn commit: r289865 - in /xmlgraphics/fop/trunk/src/java/org/apache/fop: fo/ fo/flow/ fo/properties/ layoutmgr/table/

2005-09-19 Thread Andreas L Delmelle

On Sep 19, 2005, at 18:03, Andreas L Delmelle wrote:


On Sep 19, 2005, at 11:08, Jeremias Maerki wrote:


Looks ok on first glance, though I've got a request: Would you please
consider installing a checkstyle plug-in into your IDE and configuring
the rules file for FOP? Thanks!


Dammit! And I thought I had all bases covered... :-(

My apologies for this. I hope it didn't cause too much inconvenience.


Ok, corrected most of my violations.

BTW: is it necessary for the FOTree tests to have an Apache header as 
well? Let me know, and I'll add them too...


Cheers,

Andreas



Re: svn commit: r289865 - in /xmlgraphics/fop/trunk/src/java/org/apache/fop: fo/ fo/flow/ fo/properties/ layoutmgr/table/

2005-09-19 Thread Andreas L Delmelle

On Sep 19, 2005, at 11:08, Jeremias Maerki wrote:


Looks ok on first glance, though I've got a request: Would you please
consider installing a checkstyle plug-in into your IDE and configuring
the rules file for FOP? Thanks!


Dammit! And I thought I had all bases covered... :-(

My apologies for this. I hope it didn't cause too much inconvenience.


Cheers,

Andreas



Re: svn commit: r289865 - in /xmlgraphics/fop/trunk/src/java/org/apache/fop: fo/ fo/flow/ fo/properties/ layoutmgr/table/

2005-09-19 Thread Jeremias Maerki
Looks ok on first glance, though I've got a request: Would you please
consider installing a checkstyle plug-in into your IDE and configuring
the rules file for FOP? Thanks!

On 18.09.2005 02:10:48 Andreas L Delmelle wrote:
> On Sep 18, 2005, at 01:59, [EMAIL PROTECTED] wrote:
> 
> > Author: adelmelle
> > Date: Sat Sep 17 16:59:25 2005
> > New Revision: 289865
> >
> > URL: http://svn.apache.org/viewcvs?rev=289865&view=rev
> > Log:
> > Implementation for initial values of the column-number property
> 
> Ok, after a whole lot of talking, here it is then --finally...
> 
> Since this is my first substantial contribution, if there's anything 
> the Java geeks around here have to add or if I made any serious errors, 
> please don't shoot me :-)
> 
> Passed all regression tests, so nothing should break for the common 
> cases. If anyone comes up with cases that break this approach, just add 
> them to the FOTree testsuite. I've added a few rather exceptional cases 
> myself to make sure it was as generic as possible.
> Don't hesitate to ask further info if something is not quite clear WRT 
> the logic/theory.
> 
> Thanks to everyone --especially Jeremias-- for your patience, and for 
> the FOTree testsuite, without which I'd probably still be analyzing 
> numerous log.debug() messages... :-)
> 
> Hope it meets with your approval.
> 
> Cheers,
> 
> Andreas



Jeremias Maerki



Re: svn commit: r289865 - in /xmlgraphics/fop/trunk/src/java/org/apache/fop: fo/ fo/flow/ fo/properties/ layoutmgr/table/

2005-09-18 Thread Andreas L Delmelle

On Sep 18, 2005, at 21:58, Finn Bock wrote:

Hi Finn,


+if( pList.getExplicit(PR_COLUMN_NUMBER) != null ) {
+((TableFObj) parent).setCurrentColumnIndex(
+
pList.getExplicit(PR_COLUMN_NUMBER).getNumeric().getValue());

+}


Why is explit specified values different? In all other cases in FOP, 
the fo object only needs the computed values.


Normally, if the value wasn't explicitly specified and the 
column-number received the initial value in ColumnNumberPropertyMaker 
(via the call to getCurrentColumnIndex()), the current column index for 
the parent at that point --whether it's a TableRow or a TableBody-- 
will obviously be the very same as the property's value.


It's only in the case where a column-number was explicitly specified on 
the FO, that the parent's columnIndex will be 'out-of-sync'. The 
column-number for the next cell should be the current cell's 
column-number plus it's number-columns-spanned. The 'plus 
number-columns-spanned' part is dealt with automatically when the cell 
is added to the parent's list of child nodes.


Earlier on, I had tried to solve this by comparing the current cell's 
column-number with the parent's columnIndex, but this didn't work for 
all cases... So I needed a way to check whether the value was generated 
as a default, and bumped into getExplicit() which turned out to be the 
answer.


But I think I know what you mean: apart from the check *whether* the 
explicit value is null,

maybe it's better to use
setCurrentColumnIndex(columnNumber.getValue()).

Sorry, I have a tendency to make things more complicated than they 
actually are :-)


Does this address your concern?


Cheers,

Andreas



Re: svn commit: r289865 - in /xmlgraphics/fop/trunk/src/java/org/apache/fop: fo/ fo/flow/ fo/properties/ layoutmgr/table/

2005-09-18 Thread Finn Bock

[adelmelle]


Author: adelmelle
Date: Sat Sep 17 16:59:25 2005
New Revision: 289865

URL: http://svn.apache.org/viewcvs?rev=289865&view=rev
Log:
Implementation for initial values of the column-number property

Modified: xmlgraphics/fop/trunk/src/java/org/apache/fop/fo/flow/TableCell.java
URL: 
http://svn.apache.org/viewcvs/xmlgraphics/fop/trunk/src/java/org/apache/fop/fo/flow/TableCell.java?rev=289865&r1=289864&r2=289865&view=diff
==
--- xmlgraphics/fop/trunk/src/java/org/apache/fop/fo/flow/TableCell.java 
(original)
+++ xmlgraphics/fop/trunk/src/java/org/apache/fop/fo/flow/TableCell.java Sat 
Sep 17 16:59:25 2005

...

+if( pList.getExplicit(PR_COLUMN_NUMBER) != null ) {
+((TableFObj) parent).setCurrentColumnIndex(
+
pList.getExplicit(PR_COLUMN_NUMBER).getNumeric().getValue());
+}


Why is explit specified values different? In all other cases in FOP, the 
fo object only needs the computed values.


Perhaps it is needed here for table objects, but I find it very strange.

regards,
finn


Re: svn commit: r289865 - in /xmlgraphics/fop/trunk/src/java/org/apache/fop: fo/ fo/flow/ fo/properties/ layoutmgr/table/

2005-09-17 Thread Andreas L Delmelle

On Sep 18, 2005, at 01:59, [EMAIL PROTECTED] wrote:


Author: adelmelle
Date: Sat Sep 17 16:59:25 2005
New Revision: 289865

URL: http://svn.apache.org/viewcvs?rev=289865&view=rev
Log:
Implementation for initial values of the column-number property


Ok, after a whole lot of talking, here it is then --finally...

Since this is my first substantial contribution, if there's anything 
the Java geeks around here have to add or if I made any serious errors, 
please don't shoot me :-)


Passed all regression tests, so nothing should break for the common 
cases. If anyone comes up with cases that break this approach, just add 
them to the FOTree testsuite. I've added a few rather exceptional cases 
myself to make sure it was as generic as possible.
Don't hesitate to ask further info if something is not quite clear WRT 
the logic/theory.


Thanks to everyone --especially Jeremias-- for your patience, and for 
the FOTree testsuite, without which I'd probably still be analyzing 
numerous log.debug() messages... :-)


Hope it meets with your approval.

Cheers,

Andreas