DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT <http://nagoya.apache.org/bugzilla/show_bug.cgi?id=25933>. ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND INSERTED IN THE BUG DATABASE.
http://nagoya.apache.org/bugzilla/show_bug.cgi?id=25933 [PATCH] Fix for handling column-spanning ( and a few column props ) ------- Additional Comments From [EMAIL PROTECTED] 2004-01-10 00:25 ------- OK, I think I found the solution to the first case (as already mentioned to Finn off-list): The first patch adds a for-loop to Table.addChild(). In case of a 3-column-span this created 1 column with i.e. column-number = 1, but increased the index of the following column to 4. However, further on, in the Row LM, a cell in the spanning column would need access to column 1, 2 and 3 for their respective widths. The latter two weren't created... so an AIOOBE was thrown. Fixed this by adding an inner for-loop to create the 'table-grid' columns, so now in the same case 3 columns would be added as children to the table ( while only one has been specified in the FO; in case <fo:table-column number-columns-spanned="3" number-columns-repeated="3" /> I believe 9 columns should be created to allow the Row LMs to calculate the cell-widths, if not specified). The second case I believe to have been partially caused/resolved by the patch Glen applied earlier today (bugzilla ref. 25809)... IIC, Finn was already using the altered version at home/work, so that would explain why this was working before. *But* an NPE gets thrown anyway because the TableRow would need access to the TableColumns, and Finn's patch adds the 'column' in AddLMVisitor, so it would not yet be available at FO Tree stage. Revised patch will be posted (I hope) later this weekend.
