Differences between revisions 1 and 2
Revision 1 as of 2005-12-11 18:10:07
Size: 2248
Comment: Brain dump complete :-)
Revision 2 as of 2009-09-20 23:52:45
Size: 2248
Editor: localhost
Comment: converted to 1.6 markup
No differences found!

This page contains information about the implementation of the "auto table layout" in Apache FOP.

Some Random Ideas

Today, FOP works with the Knuth element model in both inline- and block-progression-directions. For the auto table layout, we can make use of the inline Knuth element lists generated for content in table-cells. Before the line-breaking is done all the elements are gathered. By finding the largest/widest non-breakable sequence in an element list we can determine the minimal width of a column. By determining the full (unbroken) length of each element list involved we know how wide a column would have to be to accomodate the content without breaking it. Ideally, that latter value is used for the column width but if all the columns together would make the table wider than it can be, the column widths have to be reduced, in an extreme situation, down to the minimum established by the former value. I don't want to suggest any details on how to determine what effective width a column should get. The only purpose of the above is to give an idea for an approach to implement auto table layout.

So, in order to determine the column widths, the element lists have to be available early. The TableRowIterator already supports preflying a full table. The problem starts with actually getting at the element lists. Currently, LineLayoutManager directly starts line-breaking in getNextKnuthElements() when the element lists are available. This would have to be split, so table layout code could access the element lists separately. ATM I'm unsure if block-level content in inlines pose a problem to this. That will have to be looked at closely. Anyway, it should be taken care that an element list doesn't have to be recreated later to do the line-breaking. The number of objects created for an element list is already high enough. Creating objects is expensive.

Another topic might be whether to fly over the whole table or only the first n rows to determine the column layout. To make it even more complicated, the table layout could be recalculated for each page which makes the restart mechanism mandatory that we will need when we want to implement support for differring available IPD among different pages.

AutoTableLayout (last edited 2009-09-20 23:52:45 by localhost)