Re: Table processing question
Andreas L. Delmelle wrote: Hmm.. Yes, but... these properties are not specifically meant for the rows themselves. They are meant to be propagated to/combined with those defined on the table-cells contained by it. Good point. ( IIC, resolving the possible conflicts WRT backgrounds/borders can be settled, for a large part, at FOTree building time. ) I also have a hunch that this would be very convenient WRT managing rowspans... In that case, TableCells could be added to the TableRow directly, but only temporarily, to defer their finishing (?) Conversely, what about column spans specific just to one row !?! They will be stored in the table-cells, just as they are now. Another good point. doesnt mean dont consider optimization, I just mean working layout takes priority over an optimized one. And it looks like it will be harder to achieve a working layout with your suggested changes. Something I'm very concerned about, which is why I haven't started any work on it yet... wanted to gather your opinions first. Theres no harm in doing work locally and then formulating a patch for review. Right now, I just have a very clear-cut idea on what exactly needs to be done, and if I'm not mistaken, the required changes to Layout will be minimal (see the upcoming follow-up message: will post that one later tonight). For the most part, it will work exactly as it does now, only the code for *creating* the Row and Cell LM's will need a little adjusting (serveTableRow() and serveTableCell() in AddLMVisitor?) Chris
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
Andreas L. Delmelle wrote: snip/ Now, I'm wondering, since the spec states that an fo:table-row doesn't generate any reference areas and since it can contain only TableCells, whether it wouldn't be more interesting (heap-wise :) ) to create just one TableRow object per TableBody, use it to process the TableCell objects in sets, but add the latter objects directly to the TableBody and reset the TableRow every time. IIC, a similar adjustment should then also be made to the Row LM. Definitely worth considering. IOW: as I understand it, right now processing the TableBody iterates over the TableRows (i.e. simply catches the SAX events and blindly maps them to the corresponding Tree structure), as opposed to using a TableRow (catching a first SAX Event into a mutable member variable?) and iterate over groups of TableCells. Since the spec does provide for the starts-row property for fo:table-cells, it shouldn't be that difficult to set these to true to allow the Body and Row LM to determine which Cells are returned by the fo:table-row... The properties of the fo:table-row can be stored in the separate TableCells where applicable (there are no properties specifically meant for fo:table-rows; this occasion could also be used to settle background and border issues). Huh? This is not true. Follow the link you provided to the spec. table-rows can have background and border properties (when border-collapse is on) I also have a hunch that this would be very convenient WRT managing rowspans... In that case, TableCells could be added to the TableRow directly, but only temporarily, to defer their finishing (?) Conversely, what about column spans specific just to one row !?! If I judge correctly this could save a significant amount in memory usage in case of tables with a large number of rows, and could make implementing the table layout algorithms as defined in the CSS spec a lot easier (--at least, it seems more natural, since it's possible that there are no fo:table-rows specified at all, to consider them as optional, rather than having to perform all sorts of ugly tricks to be able to process a fo:table without them --which is a wall I bounced into) OTOH: I do see a challenge in the break-* and keep-* properties on table-rows, but I guess these could as well be stored in the row-starting cells somehow. yes, keep-* properties also apply to rows. On reflection I'm inclided to say it looks easier to stay as we are at the moment. Your idea is definitely worth considering, but since its primary goal is optimization, and at this time our primary objective really should be to get a working layout. That doesnt mean dont consider optimization, I just mean working layout takes priority over an optimized one. And it looks like it will be harder to achieve a working layout with your suggested changes. snip/ Chris
RE: Table processing question
-Original Message- From: Chris Bowditch [mailto:[EMAIL PROTECTED] Hi Chris, snip / Huh? This is not true. Follow the link you provided to the spec. table-rows can have background and border properties (when border-collapse is on) Hmm.. Yes, but... these properties are not specifically meant for the rows themselves. They are meant to be propagated to/combined with those defined on the table-cells contained by it. ( IIC, resolving the possible conflicts WRT backgrounds/borders can be settled, for a large part, at FOTree building time. ) I also have a hunch that this would be very convenient WRT managing rowspans... In that case, TableCells could be added to the TableRow directly, but only temporarily, to defer their finishing (?) Conversely, what about column spans specific just to one row !?! They will be stored in the table-cells, just as they are now. snip / OTOH: I do see a challenge in the break-* and keep-* properties on table-rows, but I guess these could as well be stored in the row- starting cells somehow. yes, keep-* properties also apply to rows. On reflection I'm inclided to say it looks easier to stay as we are at the moment. Your idea is definitely worth considering, but since its primary goal is optimization, and at this time our primary objective really should be to get a working layout. That doesnt mean dont consider optimization, I just mean working layout takes priority over an optimized one. And it looks like it will be harder to achieve a working layout with your suggested changes. Something I'm very concerned about, which is why I haven't started any work on it yet... wanted to gather your opinions first. Right now, I just have a very clear-cut idea on what exactly needs to be done, and if I'm not mistaken, the required changes to Layout will be minimal (see the upcoming follow-up message: will post that one later tonight). For the most part, it will work exactly as it does now, only the code for *creating* the Row and Cell LM's will need a little adjusting (serveTableRow() and serveTableCell() in AddLMVisitor?) Later, 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
Table processing question
Hi fellas, As I awoke recently, trying to pick up where I left off end of January this year (see bug 25933), and started digging deeper into the current status of table-processing in HEAD, noticed the following in the FO Tree: A TableRow FONode is created for every fo:table-row, and it is added as child to the TableBody corresponding to the parent fo:table-body. The TableCell objects are added as children to the TableRow nodes. Since you have to access the column-widths of the parent Table, you have to create a reference to its columns List for each of the TableRows. Now, I'm wondering, since the spec states that an fo:table-row doesn't generate any reference areas and since it can contain only TableCells, whether it wouldn't be more interesting (heap-wise :) ) to create just one TableRow object per TableBody, use it to process the TableCell objects in sets, but add the latter objects directly to the TableBody and reset the TableRow every time. IIC, a similar adjustment should then also be made to the Row LM. IOW: as I understand it, right now processing the TableBody iterates over the TableRows (i.e. simply catches the SAX events and blindly maps them to the corresponding Tree structure), as opposed to using a TableRow (catching a first SAX Event into a mutable member variable?) and iterate over groups of TableCells. Since the spec does provide for the starts-row property for fo:table-cells, it shouldn't be that difficult to set these to true to allow the Body and Row LM to determine which Cells are returned by the fo:table-row... The properties of the fo:table-row can be stored in the separate TableCells where applicable (there are no properties specifically meant for fo:table-rows; this occasion could also be used to settle background and border issues). I also have a hunch that this would be very convenient WRT managing rowspans... In that case, TableCells could be added to the TableRow directly, but only temporarily, to defer their finishing (?) If I judge correctly this could save a significant amount in memory usage in case of tables with a large number of rows, and could make implementing the table layout algorithms as defined in the CSS spec a lot easier (--at least, it seems more natural, since it's possible that there are no fo:table-rows specified at all, to consider them as optional, rather than having to perform all sorts of ugly tricks to be able to process a fo:table without them --which is a wall I bounced into) OTOH: I do see a challenge in the break-* and keep-* properties on table-rows, but I guess these could as well be stored in the row-starting cells somehow. Related links: http://www.w3.org/TR/xsl/slice6.html#fo_table-row http://www.w3.org/TR/REC-CSS2/tables.html#propdef-table-layout Does this make sense? Any thoughts? Greetz, Andreas
