Sorry for the delay. On 24.11.2006 19:51:41 Vincent Hennebert wrote: > 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.
I don't think so, unless you can come up with an example that proves me wrong. If I remember correctly, there's always a BreakElement between row groups. > - 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? The implementation is based on XSL 1.0 where there's no such restriction. In light of XSL 1.1 this is not correct. > - 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 Can't tell without looking into this deeper. Please write a test case and verify. > - 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. That's by design. I needed a distinction between the two cases. > - 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. My memory is bad but I think it was Andreas who suggested it. I think I may have resisted against some of his ideas at some point. Some he has implemented. ATM, I simply don't have all the details present. My mind is overloaded with other issues. Sorry. Maybe the mailing list archives help here. At any rate, when I implemented table layout I thought it more difficult to do FO tree normalization instead of adapting the differences in TableRowIterator. > - 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? No, it's a bug (or rather an easy shortcut during the mind-boggling task of implementing table layout in the first place). I mentioned this before but I never got around to fixing it. > > That's it for now. But get ready for a second whole bunch later ;-) > Thanks, > Vincent Jeremias Maerki