Hi guys,
As you may have noticed I have started to work on the table layout code.
For now I have just made some small improvements, mainly added javadoc
comments and renamed variables into names I believe are more explicit.
Please tell me if there are changes or javadoc comments you don't agree
with.
Now I'd have a first bunch of questions for those who are familiar with
that part of the code. Here they are:
- in TableContentLayoutManager.getKnuthElementsForRowIterator: when a
new row-group is fetched, its possible break-before seems to be taken
into account only if the current Knuth element list ends with a
penalty item. I suspect this is a bug, but would like to have
confirmation.
- in TableRowIterator.java:
- when the end of a table-part (table-header, -footer, -body) is
reached and there are pending spans, a new EffRow is created to
contain the remaining spans. Is that really desirable? When there
are no explicit table-row elements in the table I agree with that
behavior. But when table-rows are explicit and a cell in the last
row must span over several rows, I would bet this is an error in the
input FO file (the 1.1 recommendation states that spans over several
table parts are forbidden). Wouldn't it be better to raise an error
in such a case?
- if there are several table-bodies, LAST_IN_PART will be set only on
the last row of the last table-body. Is that behavior really
intended? I would say no as AFAIU this flag is used for border
resolution
- IIUC, a PrimaryGridUnit is meant to be the before-start (top-left)
grid unit of a spanned cell, while GridUnit is for the other grid
units (and thus only appear in spanned cells). Is that a design
choice, or just a side-effect? I'd like to add an explanation of that
in the javadoc of PrimaryGridUnit.
- I seem to have seen somewhere that normalizing tables when building
the FO tree would ease life; that is, table-row FO objects would be
created for tables which don't contain any (and rely on the
starts-row/ends-row properties). Apparently that's not done in the
current code. Just to know, is it due to a lack of time, or a design
decision? With my current understanding of the whole issue it seems to
me that that would indeed ease things at the layout stage, but I may
have missed something.
- it seems that the getNextKnuthElements method is meant to return each
time a forced break is encountered. Is that a design requirement? Can
I add that point to the method's javadoc?
That's it for now. But get ready for a second whole bunch later ;-)
Thanks,
Vincent
