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 ) Summary: [PATCH] Fix for handling column-spanning ( and a few column props ) Product: Fop Version: 1.0dev Platform: All OS/Version: All Status: NEW Severity: Normal Priority: Other Component: page-master/layout AssignedTo: [EMAIL PROTECTED] ReportedBy: [EMAIL PROTECTED] This patch as a more extensive tryout ( apart from a few superfluous diffs caused by a local styling of the code, I think it's even quite okay ) Table support in HEAD seems very basic up to here, so ... Following changes were made: - added an instance variable 'colcnt' to fop.fo.flow.Table: this allows for convenient support for the FO properties column-number / number-columns-spanned ( on columns ) / number-columns- repeated (see Table.addChild() --thanks again, Chris) - added a few accessors to fop.fo.flow.TableCell for properties column-number / number- columns-spanned, and to fop.fo.flow.TableColumn additionally for number-columns-repeated - a few changes to fop.fo.flow.TableRow: not too sure about the way this is handled, considering the multiple casts; also the 'convenience method' I added seems to be a bit ugly too --Is there a more 'clever' way of doing this? Any pieces of code in particular I can look at to get the idea? - then, of course, the layout managers: fop.layoutmgr.table.Cell, where mods analogous to TableCell had to be made and fop.layoutmgr.table.Row, for which I have already discussed the changes here : http://marc.theaimsgroup.com/?l=fop-dev&m=107307084723834&w=2 After these changes, still lacking any support for rowspan: basic logic for this would be, as described earlier, to increase the column-indexes of the affected cells at the time the FO tree is built. The cell LM can then take care of the cell-height adjustment of spanned cells. By having the column-indexes set correctly earlier, the row LM will be able to calculate the reference IPD for the affected cells based upon the correct column ( see added private method computeCellRefIPD() ) Enjoy!
