Re: Table processing question - follow-up
Andreas L. Delmelle wrote: comments below: Posting this as a follow-up to my earlier ponderings. If we don't get it implemented, or postpone this one indefinitely, at least we'll have it nicely summed up for possible future use... (Who knows, maybe parts of these remarks can be used to implement the starts-row and ends-row properties for table-cells) snip/ If we manage to make it possible for the Layout Managers to deal with the latter, this would allow us to support tables with or without explicitly defined rows with greater ease (i.e. one strategy fitting both situations). Difference: in a 700-row table, you'd only have one TableRow FObj instead of 700 that remain referenced until the page-sequence is completed... (admitted: it does enlarge the TableCell objects a bit...) Yes, just what I was thinking. TableCell would be quite complicated. Although it is hard to gauge by just talking about it. snip/ While we're at it, add an implementation for the starts-row and ends-row properties. Still mapped to fop.fo.properties.ToBeImplementedProperty, so for starters, change the mapping in fop.fo.FOPropertyMapping to make an EnumProperty for them. In fop.fo.flow.TableCell, add the necessary code to the doSetup() method to make it possible to actually use them... (is there another step I'm missing?) (Come to think of it: the 'width' property for table-cells seems also unimplemented for the moment) This makes sense - what effect would you expect width on table cell to have? I maybe missing something, but the width is derived from table column and cant be overridden for a single cell. Modifications in Layout: as already indicated, I think there are not that many. It will continue to work as it does now. It's only the LM *creation* process that will need a little tweaking... As there will always be a TableRow child present, even if there was none specified in the source FO, the first Row LM will be created anyway. It will just be a matter of adding the Cell LMs as children of the current Row LM, and generating a new Row LM when the Cell in question starts a row. So, for those of you that have read closely (--and have been able to keep awake ;) ): Indeed, it seems as if I'm making things more complicated, since the rows are removed in the FOTree, but are re-introduced in Layout... This is because, AFAICT, the problem with big tables is mainly the creation of the FObj's, so this goes a little step towards solving that one. On top of that, while building the FOTree, it is hardly ever necessary to peek into preceding/following Rows, so the work over there (IMHO) doesn't really *need* multiple TableRow objects for one TableBody. There may be a need to peek at surrounding rows when implementing border-collapse algorithms. Not sure if this peeking will need to be done in FO Tree or layout or both. Just food for thought... hope someone enjoys :) On the whole a very well thought out idea. I dont want you to think I'm discouraging you. You have answered my initial concerns, so why dont you go ahead and make the changes locally and then create a patch for review. It will be easier to discuss pros/cons in more depth by looking at the patch file. Chris
RE: Table processing question - follow-up
-Original Message- From: Chris Bowditch [mailto:[EMAIL PROTECTED] Hi Chris, snip / This makes sense - what effect would you expect width on table cell to have? I maybe missing something, but the width is derived from table column and cant be overridden for a single cell. Indeed, but the columns can be absent in the source FO. In which case they're actually to be considered present, and their widths are determined by the cells in the first row (--or, but I didn't dare consider that possibility just yet, in case of auto-layout, by the cell 'in' that column that has the content with the largest width). snip / On the whole a very well thought out idea. I dont want you to think I'm discouraging you. You have answered my initial concerns, so why dont you go ahead and make the changes locally and then create a patch for review. It will be easier to discuss pros/cons in more depth by looking at the patch file. That was what I meant by 'Now, back to work' :) IOW: expect a patch-proposal for this one of the coming days... Cheers, Andreas
RE: Table processing question - follow-up
Andreas L. Delmelle [EMAIL PROTECTED] wrote on 18.05.2004 18:09:15: Indeed, but the columns can be absent in the source FO. In which case they're actually to be considered present, and their widths are determined by the cells in the first row (--or, but I didn't dare consider that possibility just yet, in case of auto-layout, by the cell 'in' that column that has the content with the largest width). As far as I understand the spec, table-column elements with a column-width property are mandatory for tables with fixed table layout. From the spec: 7.26.9.: The column-width property must be specified for every column, unless the automatic table layout is used. To me, this means not only that column-width is mandatory in fixed-layout *if* table-column elements exist, but also that a table-column needs to exist for each column. Since they don't talk about a derived trait, but of a column-width property that also isn't inherited, I can only conclude that must be specified for every column means: 1. In fixed-layout, there MUST be a table-column element for each column. AND 2. In fixed-layout, the column-width property must be set in all table-column elements. Arnd -- Arnd Beißner Cappelino Informationstechnologie GmbH Bahnhofstr. 3, 71063 Sindelfingen, Germany Tel.: +49-7031-763863-11, Fax: +49-7031-763863-99 Mobile: +49-173-3016917
RE: Table processing question - follow-up
-Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] Hi Arnd, snip / As far as I understand the spec, table-column elements with a column-width property are mandatory for tables with fixed table layout. *Vry* good point! Yup, got me there... I was mixing the two layout modes (a bit too focused on CSS2). Would this mean that it's actually (a bit) easier than it looks? I'll have to reconsider... Thanks for this effort-saving remark! Cheers, Andreas
RE: Table processing question - follow-up
-Original Message- From: Andreas L. Delmelle [mailto:[EMAIL PROTECTED] Posting this as a follow-up to my earlier ponderings. If we don't get it implemented, or postpone this one indefinitely, at least we'll have it nicely summed up for possible future use... (Who knows, maybe parts of these remarks can be used to implement the starts-row and ends-row properties for table-cells) The requirements for this I see up to here are roughly as follows: In fop.fo.flow.TableBody - add a protected TableRow member variable, and - override fop.fo.FObj.addChild to assign the caught row event to it, instead of creating an FObj child for every encountered row and adding it to its children ArrayList (=default FObj behaviour). If a child to be added to the TableBody is a TableCell and the first child, insert one TableRow anyway --will come in handy further downstream. Also in fop.fo.flow.TableBody, introduce a variable to hold the current cell being added. In fop.fo.flow.TableRow, override fop.fo.FObj.addChild, and make it : - add the child to its parent TableBody when it starts a row, or - assign the child as next cell to the TableBody's currentCell The idea being that the cells are added to the TableBody as chains. Only the row-starting cells are direct children of the TableBody. The others are referenced by a nextCellInRow variable in the previous cell (--dunno for sure about this :/ ) What it comes down to, is trading this structure TableBody TableRow (-columns: ArrayList of TableColumns) TableCell TableCell ... TableRow (-columns: ArrayList of TableColumns) TableCell TableCell ... for TableBody TableRow (-columns: ArrayList of TableColumns) TableCell (-nextCellInRow: TableCell (-nextCellInRow: null)) TableCell (-nextCellInRow: TableCell (-nextCellInRow: null)) If we manage to make it possible for the Layout Managers to deal with the latter, this would allow us to support tables with or without explicitly defined rows with greater ease (i.e. one strategy fitting both situations). Difference: in a 700-row table, you'd only have one TableRow FObj instead of 700 that remain referenced until the page-sequence is completed... (admitted: it does enlarge the TableCell objects a bit...) In case the Table didn't have any columns specified, this is where they can be added/derived. If the TableRow's columns ArrayList is set to reference the one from the parent Table in the TableRow's constructor or init(), we could test in addChild() whether it is null: in this case create the columns and add them to the TableRow's column List as the TableCells are added. In the TableRow.end() method, set the columns List for the parent Table if it is still null. For each subsequent TableRow being processed, the columns List will be readily available from the parent Table. (IOW: this facilitates implementing the 'columns-are-determined-by-cells-in-the-first-row' part) ? My question here is whether this can be done in TableRow.addChild() by a simple: TableColumn col = new TableColumn( (FONode)getParentTable() ); /* set width from current cell if known, else defer this setting /* until the List is passed back to the Table, and use a /* formula like: Table.OptIPD / ColumnCount, possibly /* refined to include widths of other Columns that *were* /* explicitly set /* DON'T add the column to the Table just yet ... */ columns.add( col ); then later on in TableRow.end(), something like: getParentTable().setColumns( columns ); ? While we're at it, add an implementation for the starts-row and ends-row properties. Still mapped to fop.fo.properties.ToBeImplementedProperty, so for starters, change the mapping in fop.fo.FOPropertyMapping to make an EnumProperty for them. In fop.fo.flow.TableCell, add the necessary code to the doSetup() method to make it possible to actually use them... (is there another step I'm missing?) (Come to think of it: the 'width' property for table-cells seems also unimplemented for the moment) Modifications in Layout: as already indicated, I think there are not that many. It will continue to work as it does now. It's only the LM *creation* process that will need a little tweaking... As there will always be a TableRow child present, even if there was none specified in the source FO, the first Row LM will be created anyway. It will just be a matter of adding the Cell LMs as children of the current Row LM, and generating a new Row LM when the Cell in question starts a row. So, for those of you that have read closely (--and have been able to keep awake ;) ): Indeed, it seems as if I'm making things more complicated, since the rows are removed in the FOTree, but are re-introduced in Layout... This is because, AFAICT, the problem with big tables is mainly the creation of the FObj's, so this goes a little step towards solving that one. On top of that, while building the FOTree, it is hardly ever necessary to peek into preceding/following Rows, so the work over there (IMHO)
RE: Table processing question - follow-up
BTW, Andreas, sorry for not responding to your emails on this thread, I'm juggling a bit much right now, both FOP and non-FOP--thankfully Chris at least has been able to comment on your work, and hopefully I and/or a few others will be able to add something later. Thanks for helping us out with the tables. Glen --- Andreas L. Delmelle [EMAIL PROTECTED] wrote:
RE: Table processing question - follow-up
-Original Message- From: Glen Mazza [mailto:[EMAIL PROTECTED] BTW, Andreas, sorry for not responding to your emails on this thread, I'm juggling a bit much right now, Well, don't worry about that... Just posting this all to see if it's just in my head, or all crazy talk --and if not the latter, maybe it will give someone else some ideas, or make them see the light, so to speak. If it is crazy, and I'm not interpreting the process correctly, at least someone will feel compelled to correct me ... in time (--we all hope :) ) Greetz, Andreas
