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

Reply via email to