DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG· RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT <http://issues.apache.org/bugzilla/show_bug.cgi?id=40271>. ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND· INSERTED IN THE BUG DATABASE.
http://issues.apache.org/bugzilla/show_bug.cgi?id=40271 ------- Additional Comments From [EMAIL PROTECTED] 2006-09-09 11:50 ------- Patrick, I have reviewed your patch. These are my remarks: columns.columns and columns2.columns contain the same TableColumn objects, columns.colWidths and columns2.colWidths contain the same TableColLength objects: columns ColumnSetup (id=79) columns ArrayList<E> (id=96) [0] TableColumn (id=104) [1] TableColumn (id=105) [2] TableColumn (id=102) colWidths ArrayList<E> (id=97) [0] null [1] TableColLength (id=114) [2] TableColLength (id=115) [3] TableColLength (id=108) maxColIndexReferenced 0 table Table (id=85) columns2 ColumnSetup (id=81) columns ArrayList<E> (id=98) [0] TableColumn (id=104) [1] TableColumn (id=105) [2] TableColumn (id=102) colWidths ArrayList<E> (id=99) [0] null [1] TableColLength (id=114) [2] TableColLength (id=115) [3] TableColLength (id=108) maxColIndexReferenced 0 table Table (id=85) Consequently, in 'copy column setup' column and column2 are the same object. Apparently there is no need for columns2. One can set the column widths, use them for the auto table layout calculations, and set them again to the calculated widths. In TableContentLayoutManager.createElementsForRowGroup, the call to determineAutoColumnWidths may be too early. The construction of the element list of the primary is not yet finished. Cf. the call to the ElementListObserver. In LineLayoutManager.collectInlineKnuthElements minMaxW is not correctly calculated when an LM has multiple child LMs. Each child LM overwrites the results of its previous sibling, and the last one remains. The same is true for the calls to minMaxTextWidths() in BlockStackingLM and TableContentLM, when they have multiple child LMs. This would be a possible scenario: The BlockLevelLMs implement minMaxTextWidths(). Basically they request the same from their child LMs, and return the combined results. TableContentLM calls minMaxTextWidths() on all the TableCellLMs and combine the results per column. LineLM implements minMaxTextWidths() as collectKnuthElements and returns the combined results for minMaxW of its paragraphs and inline blocks. LineLM keeps the constructed element lists in knuthParagraphs (check). When the proper column widths have been calculated, getNextKnuthElements is called. In this call, LineLM uses the constructed element lists (check). In this way, the column width calculations are done without invoking the table stepper algorithm, and the element lists are constructed only once. Ideally it would be programmed such that a call to minMaxTextWidths() is optional, that is, if it is called, the Knuth element lists are kept for reuse in getNextKnuthElements(), and if it is not, getNextKnuthElements() constructs the element lists as it does now. The difficult part will be in TableContentLM, taking spanned cells into account and reusing existing methods while bypassing the grid unit construction. Implementing without spanned cells is the first approximation. Perhaps a simplified version of getKnuthElementsForRowIterator is needed: you want to dive into the table cells without bothering about vertical cell alignments and page breaks. Alternatively, the grid units are constructed without line breaking in the cells, and reused in the call to getNextKnuthElements(). (pgus should be a member of TableContentLM?) Simon -- Configure bugmail: http://issues.apache.org/bugzilla/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are the assignee for the bug, or are watching the assignee.
