Re: Tables, Columns... : FOTree or Layout?
On 10.09.2005 01:41:05 Andreas L Delmelle wrote: -BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Hi all, In my attempt to facilitate an implementation of the collapsing border model on tables by moving the lion's share of the logic from layoutmgr.table over to the fo.flow package, I stumbled upon some other parts that are currently dealt with at layout stage while I feel they don't really belong there. To put it generally: there are questions about a table's structure that can be answered by looking *solely* at the tree structure itself (i.e. no details about the how, when or even if of layout are required). The other ones I encountered so far: implicit columns (from cells in first row), column-number and number-columns-repeated. Especially the second seems out of place in layout, since it is needed by the (currently unimplemented) function from-table-column(). If the column-numbering is deferred until layout, it seems to become all the more difficult to provide an eventual implementation for this function. The other two are closely related to this, since they are necessary to get the column-numbers right. Point. But I somehow share Simon's reservation about moving table normalization into the FO tree. I share his view that the FO tree should represent the FO document like a DOM. On the other side, the FOEventHandlers (RTF, for example) could profit from the table normalization available on the FO tree level. But then the FOEventHandler could easily reuse the TableRowIterator. I'm not a big help here but after all I think the current table normalization works fine except that the from-table-column() method will be difficult to implement. This kind of on-the-fly normalization of the tree structure has advantages for layout in that the table-grid co-ordinates will be readily available (no interpretation needed, just pick up the cells as building-blocks and map them onto the grid without too much effort). Huh? But that's already the case with the TableRowIterator!? The only downside is that certain information is lost. The tree structure won't be the structure as specified in the source document, but will actually correspond to another structure that yields exactly the same results. Another related issue then, is that of storing the columns as a List. Currently, in layoutmgr.table.ColumnSetup, an error message is logged when there is a gap (i.e. non-occupied column-numbers). According to the Rec, this is no error, since there is no need for column-numbers to be monotonically increasing from one formatting object to the next (see: 7.26.8 column-number) This is probably why no exception is thrown (?) Yes, that should actually be no error, only maybe a hint to the user that default values will be used for a certain column. The problem is creating a TableColumn instance for the gaps. The case that more columns a required than are defined is handled differently by returning the last specified TableColumn. I take this to mean that an author can decide to number the first column as 3, and specify a number of 7 for the next. Yes. To allow for a straightforward way to map between the List index and the column-number, we'd need to create a List containing 7 elements, 5 of which aren't real elements at all... and that's still leaving number-columns-spanned out of the picture. Remember that number-columns-spanned on table-column don't actually span cells but only define column groups and provide a value for from-table-column(). The larger the gaps and the more spanning columns, the more unnecessary nulls to add. Right, but how many times does it happen? So, basically two questions here: 1) Anyone opposed to moving column-numbering, number-columns-repeated, implicit columns over to the FOTree side? (I already have a pretty good idea of what needs to be done, so I can start immediately on that.) Not opposed, but I don't really see how exactly you are going to do it. 2) Anyone opposed to using a Map to store the columns instead of a List? (Key = Integer or Numeric (column-number); Value = TableColumn) I wonder if the Map not actually uses more space or creates more object instances than the List approach with a few null values. Jeremias Maerki
Re: Tables, Columns... : FOTree or Layout?
On Sep 11, 2005, at 11:52, Jeremias Maerki wrote: Hi, On 10.09.2005 01:41:05 Andreas L Delmelle wrote: This kind of on-the-fly normalization of the tree structure has advantages for layout in that the table-grid co-ordinates will be readily available (no interpretation needed, just pick up the cells as building-blocks and map them onto the grid without too much effort). Huh? But that's already the case with the TableRowIterator!? Yes, but that class is situated in the layout package. So, this doesn't exactly provide the TableCell or TableColumn with the correct initial value for column-number (as described in the Rec). It leaves this up to the layout engine. In the short-term, this may not be too much of a problem, but if the long-term goal is still to provide the possibility of plugging in different layout engines, any such engine would have to take into account that FOP's tree structure will be lacking the correct initial property values here... snip / To allow for a straightforward way to map between the List index and the column-number, we'd need to create a List containing 7 elements, 5 of which aren't real elements at all... and that's still leaving number-columns-spanned out of the picture. Remember that number-columns-spanned on table-column don't actually span cells but only define column groups and provide a value for from-table-column(). OK, I overlooked this tiny detail... Thanks for pointing that out. Even then, I guess my concern was the combination of number-columns-spanned and number-columns-repeated. If you have a spanning column that is repeated, the column-numbers for the repeated columns will have to consider the value for number-columns-spanned. see: Rec 7.26.12 number-columns-repeated The 'column-number' property, for all but the first, is the column-number of the previous one plus its value of the 'number-columns-spanned' property. The larger the gaps and the more spanning columns, the more unnecessary nulls to add. Right, but how many times does it happen? Yep. Precisely the reason I'm asking... So, basically two questions here: 1) Anyone opposed to moving column-numbering, number-columns-repeated, implicit columns over to the FOTree side? (I already have a pretty good idea of what needs to be done, so I can start immediately on that.) Not opposed, but I don't really see how exactly you are going to do it. For the column-numbers: tracking the columns as they are added to the tree, and increasing the column index should do the trick. The default value for the column-number property will be available as the column index of the parent table. In case a column-number was explicitly specified, and deviates from the initial value (the column index), the index will be forced to that column's column-number, so that it is correct for the next column. For the repeating columns: insert new TableColumns immediately into the tree structure. The only problem I'm facing here is that the properties can't actually be the same instances as those of the first column --this is currently the only case that will break the border-collapsing strategy I have in mind. (not going into details here; expect a separate post on that) For creating columns from the cells in the first row: still investigating... 2) Anyone opposed to using a Map to store the columns instead of a List? (Key = Integer or Numeric (column-number); Value = TableColumn) I wonder if the Map not actually uses more space or creates more object instances than the List approach with a few null values. Exactly why I'm asking. If this doesn't occur too much, it would indeed be a waste of resources... All things considered, this may indeed not be such a good idea. Thanks for your input. Cheers, Andreas
Re: Tables, Columns... : FOTree or Layout?
On 11.09.2005 12:47:03 Andreas L Delmelle wrote: On Sep 11, 2005, at 11:52, Jeremias Maerki wrote: Hi, On 10.09.2005 01:41:05 Andreas L Delmelle wrote: This kind of on-the-fly normalization of the tree structure has advantages for layout in that the table-grid co-ordinates will be readily available (no interpretation needed, just pick up the cells as building-blocks and map them onto the grid without too much effort). Huh? But that's already the case with the TableRowIterator!? Yes, but that class is situated in the layout package. So, this doesn't exactly provide the TableCell or TableColumn with the correct initial value for column-number (as described in the Rec). It leaves this up to the layout engine. In the short-term, this may not be too much of a problem, but if the long-term goal is still to provide the possibility of plugging in different layout engines, any such engine would have to take into account that FOP's tree structure will be lacking the correct initial property values here... There's nothing special about FOP's tree structure. It's just the exact representation of the FO file without any normalization. Anyway, if I hadn't introduced the TableCellLM in the PrimaryGridUnit you could simply move TableRowIterator and the GridUnit classes into the FO package because they have no dependency on the layout classes except for the little exception above. I imagine you will need to reproduce exactly what I implemented in TableRowIterator again in the FO tree. snip / To allow for a straightforward way to map between the List index and the column-number, we'd need to create a List containing 7 elements, 5 of which aren't real elements at all... and that's still leaving number-columns-spanned out of the picture. Remember that number-columns-spanned on table-column don't actually span cells but only define column groups and provide a value for from-table-column(). OK, I overlooked this tiny detail... Thanks for pointing that out. Even then, I guess my concern was the combination of number-columns-spanned and number-columns-repeated. If you have a spanning column that is repeated, the column-numbers for the repeated columns will have to consider the value for number-columns-spanned. see: Rec 7.26.12 number-columns-repeated The 'column-number' property, for all but the first, is the column-number of the previous one plus its value of the 'number-columns-spanned' property. Hmm, to me that sounds like a mistake in the spec. This is completely illogical. At the very least, this sentence is in the wrong place. It doesn't even refer to the number-columns-repeated property. IMO this sentence creates a conflict between number-columns-repeated, number-columns-spanned and column-number for table-column. Note that the same sentence is also found in XSL 1.1WD. What do I miss? The larger the gaps and the more spanning columns, the more unnecessary nulls to add. Right, but how many times does it happen? Yep. Precisely the reason I'm asking... Ok, to answer my question: IMO not so often. So, basically two questions here: 1) Anyone opposed to moving column-numbering, number-columns-repeated, implicit columns over to the FOTree side? (I already have a pretty good idea of what needs to be done, so I can start immediately on that.) Not opposed, but I don't really see how exactly you are going to do it. For the column-numbers: tracking the columns as they are added to the tree, and increasing the column index should do the trick. The default value for the column-number property will be available as the column index of the parent table. In case a column-number was explicitly specified, and deviates from the initial value (the column index), the index will be forced to that column's column-number, so that it is correct for the next column. For the repeating columns: insert new TableColumns immediately into the tree structure. The only problem I'm facing here is that the properties can't actually be the same instances as those of the first column --this is currently the only case that will break the border-collapsing strategy I have in mind. (not going into details here; expect a separate post on that) That's also the big problem I see. I never actually figured out how to properly and manually create FO nodes. I'm sure there's an answer to that. For creating columns from the cells in the first row: still investigating... I don't think this is a big problem. Just check for the availability of a column set once the first row is available and create the column setup if necessary. 2) Anyone opposed to using a Map to store the columns instead of a List? (Key = Integer or Numeric (column-number); Value = TableColumn) I wonder if the Map not actually uses more space or creates more object instances than the List approach with a few null values. Exactly why I'm asking. If
Re: Tables, Columns... : FOTree or Layout?
On Sun, 11 Sep 2005 09:01 pm, Andreas L Delmelle wrote: On Sep 11, 2005, at 13:19, Jeremias Maerki wrote: On 11.09.2005 12:47:03 Andreas L Delmelle wrote: snip/ But anyway, currently the balance is: +2 for having the tree structure exactly resemble the FO source document versus +1 for performing normalization as the tree is built Apologies, but my understanding of this area is far too limited to give an opinion either way. Manuel
Re: Tables, Columns... : FOTree or Layout?
On 11.09.2005 15:01:30 Andreas L Delmelle wrote: On Sep 11, 2005, at 13:19, Jeremias Maerki wrote: On 11.09.2005 12:47:03 Andreas L Delmelle wrote: There's nothing special about FOP's tree structure. ... except that it currently doesn't provide the correct initial values for the mentioned properties :-) Right, sorry. It's just the exact representation of the FO file without any normalization. Anyway, if I hadn't introduced the TableCellLM in the PrimaryGridUnit you could simply move TableRowIterator and the GridUnit classes into the FO package because they have no dependency on the layout classes except for the little exception above. I imagine you will need to reproduce exactly what I implemented in TableRowIterator again in the FO tree. That may be an idea worth investigating: only implement it in the FOTree, and make it available to the layout package, so that layout can also use it --*if* it still needs to... IMO this would make the layout code massively more transparent. But anyway, currently the balance is: +2 for having the tree structure exactly resemble the FO source document versus +1 for performing normalization as the tree is built I think the first doesn't necessarily exclude the second. Maybe the normalized structure can be made available through the table element. This way you'd still have the normalized table available in the FO tree and to the FOEventHandlers while preserving the original FO tree. Plus my +1 on the first item is not a full +1, only perhaps a +0.5 as I'm fully aware that certain problem can only be resolved if some of the normalization happens in the FO tree already. We probably still haven't found the right design. Based on that, if no other devs jump in to support me, it seems I may have to abandon my plans for collapsing borders there altogether, as this would also mean that the BorderInfos for the table elements are altered (so they wouldn't correspond exactly to what was specified in the source document) :-( WRT efficiency, I still think it would be worthwhile to end up with a table tree structure with elements referring to the very same BorderInfo instance for a given side (losing BorderInfo instances for certain elements would be immediately discarded and replaced with a reference to the winning BorderInfo) Think of a table with 100+ rows, with the table's start-border dominating over all other elements' start-borders. First table-column, every table-body, every table-row, and all the first cells in every row would simply get a reference to the table's BorderInfo for that side. The idea behind it is that: a) the user shouldn't have supplied the losing border-specs in the first place (i.e. it would make no difference if he hadn't --his source document would produce exactly the same result), but b) this is often not under the user's control --think of a stylesheet that conveniently uses the same attribute-set for all cells in a given row, regardless of whether they share an edge with higher table-elements. I'm feeling stupid but I keep having problems following you. Maybe it would be worthwhile if you put your work in a branch so everyone could have a look. snip/ Jeremias Maerki
Re: Tables, Columns... : FOTree or Layout?
Andreas, You are asking a lot of questions. To most I have no answer, but I have one reservation. On Sat, Sep 10, 2005 at 01:41:05AM +0200, Andreas L Delmelle wrote: The other ones I encountered so far: implicit columns (from cells in first row), column-number and number-columns-repeated. Especially the second seems out of place in layout, since it is needed by the (currently unimplemented) function from-table-column(). If the column-numbering is deferred until layout, it seems to become all the more difficult to provide an eventual implementation for this function. The other two are closely related to this, since they are necessary to get the column-numbers right. This kind of on-the-fly normalization of the tree structure has advantages for layout in that the table-grid co-ordinates will be readily available (no interpretation needed, just pick up the cells as building-blocks and map them onto the grid without too much effort). The only downside is that certain information is lost. The tree structure won't be the structure as specified in the source document, but will actually correspond to another structure that yields exactly the same results. This bothers me. It may hinder proper calculation of property value inheritance, which follows the tree as given by the user. We do property refinement on the tree; other than that it is a precise reflection of the user's fo document. I am reluctant to change that. Regards, Simon -- Simon Pepping home page: http://www.leverkruid.nl
Tables, Columns... : FOTree or Layout?
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Hi all, In my attempt to facilitate an implementation of the collapsing border model on tables by moving the lion's share of the logic from layoutmgr.table over to the fo.flow package, I stumbled upon some other parts that are currently dealt with at layout stage while I feel they don't really belong there. To put it generally: there are questions about a table's structure that can be answered by looking *solely* at the tree structure itself (i.e. no details about the how, when or even if of layout are required). The other ones I encountered so far: implicit columns (from cells in first row), column-number and number-columns-repeated. Especially the second seems out of place in layout, since it is needed by the (currently unimplemented) function from-table-column(). If the column-numbering is deferred until layout, it seems to become all the more difficult to provide an eventual implementation for this function. The other two are closely related to this, since they are necessary to get the column-numbers right. This kind of on-the-fly normalization of the tree structure has advantages for layout in that the table-grid co-ordinates will be readily available (no interpretation needed, just pick up the cells as building-blocks and map them onto the grid without too much effort). The only downside is that certain information is lost. The tree structure won't be the structure as specified in the source document, but will actually correspond to another structure that yields exactly the same results. Another related issue then, is that of storing the columns as a List. Currently, in layoutmgr.table.ColumnSetup, an error message is logged when there is a gap (i.e. non-occupied column-numbers). According to the Rec, this is no error, since there is no need for column-numbers to be monotonically increasing from one formatting object to the next (see: 7.26.8 column-number) This is probably why no exception is thrown (?) I take this to mean that an author can decide to number the first column as 3, and specify a number of 7 for the next. To allow for a straightforward way to map between the List index and the column-number, we'd need to create a List containing 7 elements, 5 of which aren't real elements at all... and that's still leaving number-columns-spanned out of the picture. The larger the gaps and the more spanning columns, the more unnecessary nulls to add. So, basically two questions here: 1) Anyone opposed to moving column-numbering, number-columns-repeated, implicit columns over to the FOTree side? (I already have a pretty good idea of what needs to be done, so I can start immediately on that.) 2) Anyone opposed to using a Map to store the columns instead of a List? (Key = Integer or Numeric (column-number); Value = TableColumn) Cheers, Andreas -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.1 (Darwin) iD8DBQFDIh2byHTbFO9b8aARAmxiAJwOmZ20noM4AASe1yX+NEEJQFCT5wCdGdK0 l5ruWzp04zIKuFakiBQMr6I= =dpCF -END PGP SIGNATURE-
