Re: More on row and column span (was: RE: (Changing Vote) etc.)
Andreas L. Delmelle wrote: Another detail overlooked is the column-number property, ... Which is, for the moment quite ... unimplemented (--should've checked this sooner :) ), so that explains why the spec isn't being followed when setting the default value to 0. This makes me think that much of colspan and rowspan could already be managed at FO Tree level, so the LM's already get supplied the correct value at least for colnr from interrogating their FObj. I would judge this approach to be much cleaner... Any thoughts on this? it would be easy to determine col number in Table.addChild. This number could then be replaced in TableColumn.doSetup only if Column Number has actually been specified in the FO. I'm not sure I would be keen on working out any spanning related stuff in the FO Tree classes as it seems the wrong place for such computations. But that is just an opinion. With the current modifications I have made to the cell row LM's (--more on these soon), it should work... when support for the column-number property would be available. That is: for the moment, I have column-span working correctly apart from the fact that the column-number is always 0. If this is not the case, as I could see when hacking this support into the row LM in setupCells(), the cellIPD and xoffset for the following cells are being calculated correctly, based upon the correct table-column. (This was done in such a way that we can easily pick up the column-number from the corresponding TableCell afterwards, if and when we figure out how to correctly set the defaults for this.) Understood. The RowSpanMgr in maintenance *is* indeed very interesting... still no luck here, though I dont follow, could you elaborate? Chris
Re: More on row and column span (was: RE: (Changing Vote) etc.)
Andreas L. Delmelle wrote: -Original Message- From: Andreas L. Delmelle [mailto:[EMAIL PROTECTED] I guess the riddle I'm still trying to solve is: How do I access the LM's for the subsequent rows at this point? AFAICT, I have overlooked (at least) the following note in the spec (6.7.1 Table Formatting Objects - Introduction): - a cell that is spanned may have a different background in each of the grid units it occupies Ahh... I can see why this would complicate things somewhat. Perhaps you could still just have a single Cell occupying each grid unit but allow each LM to render multiple backgrounds. Reading this, I'm totally unsure of the solution I have proposed... As it is, I think it would 'expand' the background props in the first grid unit, and use them as background for the whole spanned cell. In order to achieve this effect, it may be necessary to have the body LM add dummy cells to the following rows. So the child areas of a spanned cell need to be laid out to fill the full range the cell spans, while the specified background may only be used on the first grid unit... Quite a bit harder than I initially thought, but we'll keep looking. Another detail overlooked is the column-number property, which would perfectly fulfill the role of my proposed cspanPrev variable. It is defined in TableCell, but not according to the default defined in the spec. (It's set to 0, but should be set to: q the first column to be spanned by the table-cell. The initial value is the current column-number. For the first table-cell in a table-row, the current column is 1. For other table-cells, the current column-number is the column-number of the previous table-cell in the row plus the number of columns spanned by that previous cell. /q) I didnt read your posts in the correct order, so my earlier reply on column-number is meaningless, sorry. I was thinking of TableColumn not the TableCell. But you could still work out column number in the FO Tree classes as you proposed. You may want to override the FObj.addChild method on TableRow in a similar manner to the Table class. In the meantime, if anyone can provide me with any pointers, be sure to post them! (C'mon, ya layout-geeks, where are you? :) ) Chris
RE: More on row and column span (was: RE: (Changing Vote) etc.)
-Original Message- From: Chris Bowditch [mailto:[EMAIL PROTECTED] snip / it would be easy to determine col number in Table.addChild. This number could then be replaced in TableColumn.doSetup only if Column Number has actually been specified in the FO. I'm not sure I would be keen on working out any spanning related stuff in the FO Tree classes as it seems the wrong place for such computations. But that is just an opinion. No, I guess you're right that the computations themselves should be left to Layout, although *that* seems a bit silly if the respective property values are already given in their absolute form at parse time. To explain what I do see handled at FOTree level: in case of rowspan (r), the cells with index = the current cell in the subsequent (r-1) rows should have their column-number increased by a value of colspan. I think this could definitely be tracked when the FOTree is built... Then further on in the Layout process, the xoffsets for all cells in the row can be very quickly derived from the column-number ( sum of all column-widths cell-column-number ) snip / The RowSpanMgr in maintenance *is* indeed very interesting... still no luck here, though Maintenance has a class (lemme see, ...) in fop.fo.flow called RowSpanMgr, which I don't see reappearing in HEAD (unless someone has put it in a less obvious location... Glen? You been moving some stuff around again??? ;) Jus' kidding, of course...) This class seems to be used to keep track of all rowspans. Haven't studied in detail yet, but I guess one of these gets created for every table (body/header/footer?), and it looks like the kind of thing I had in mind to handle rowspans, so lucky me :) Does anyone recall a thread where such was discussed? Or were tables something 'to be figured out at an indefinite point in the future'? Well then: No time like the present! Cheers, Andreas
RE: More on row and column span (was: RE: (Changing Vote) etc.)
-Original Message- From: Andreas L. Delmelle [mailto:[EMAIL PROTECTED] Just to keep everyone up to date about my excursions: snip / Another detail overlooked is the column-number property, ... Which is, for the moment quite ... unimplemented (--should've checked this sooner :) ), so that explains why the spec isn't being followed when setting the default value to 0. This makes me think that much of colspan and rowspan could already be managed at FO Tree level, so the LM's already get supplied the correct value at least for colnr from interrogating their FObj. I would judge this approach to be much cleaner... Any thoughts on this? With the current modifications I have made to the cell row LM's (--more on these soon), it should work... when support for the column-number property would be available. That is: for the moment, I have column-span working correctly apart from the fact that the column-number is always 0. If this is not the case, as I could see when hacking this support into the row LM in setupCells(), the cellIPD and xoffset for the following cells are being calculated correctly, based upon the correct table-column. (This was done in such a way that we can easily pick up the column-number from the corresponding TableCell afterwards, if and when we figure out how to correctly set the defaults for this.) The RowSpanMgr in maintenance *is* indeed very interesting... still no luck here, though Cheers, Andreas
RE: More on row and column span (was: RE: (Changing Vote) etc.)
-Original Message- From: Andreas L. Delmelle [mailto:[EMAIL PROTECTED] I guess the riddle I'm still trying to solve is: How do I access the LM's for the subsequent rows at this point? AFAICT, I have overlooked (at least) the following note in the spec (6.7.1 Table Formatting Objects - Introduction): - a cell that is spanned may have a different background in each of the grid units it occupies Reading this, I'm totally unsure of the solution I have proposed... As it is, I think it would 'expand' the background props in the first grid unit, and use them as background for the whole spanned cell. In order to achieve this effect, it may be necessary to have the body LM add dummy cells to the following rows. So the child areas of a spanned cell need to be laid out to fill the full range the cell spans, while the specified background may only be used on the first grid unit... Quite a bit harder than I initially thought, but we'll keep looking. Another detail overlooked is the column-number property, which would perfectly fulfill the role of my proposed cspanPrev variable. It is defined in TableCell, but not according to the default defined in the spec. (It's set to 0, but should be set to: q the first column to be spanned by the table-cell. The initial value is the current column-number. For the first table-cell in a table-row, the current column is 1. For other table-cells, the current column-number is the column-number of the previous table-cell in the row plus the number of columns spanned by that previous cell. /q) In the meantime, if anyone can provide me with any pointers, be sure to post them! (C'mon, ya layout-geeks, where are you? :) ) Thanks, Andreas
