Dear Wiki user,

You have subscribed to a wiki page or wiki category on "Xmlgraphics-fop Wiki" 
for change notification.

The following page has been changed by JeremiasMaerki:
http://wiki.apache.org/xmlgraphics-fop/AutoTableLayout

The comment on the change is:
Brain dump complete :-)

New page:
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.

---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

Reply via email to