On 30.09.2005 10:17:24 Simon Pepping wrote:
> Hi,
> Some thoughts about the space resolution implementation notes.
> I believe that borders and padding are not unresolvable elements. They
> can always be determined by their LM because they do not interact with
> the borders and padding of other LMs. They do influence space
> resolution. They act as fences and break space sequences into several
> separate stacking constraints. This can be taken into account by the
> Space Resolver if the Knuth elements for the borders and padding make
> it clear that they are a fence to stacking constraints.

I make a distinction between unresolvable and unresolved. I agree with
the above but found it easier to work with border and padding as
"unresolved elements". Note that this only describes that the resolution
is done at a different time. I assume it could be done without the
special elements for borders and paddings. Maybe it will be changed

> And some (perhaps irrelevant) observations about break possibility
> building.
> The situation regarding retained borders and padding resembles the
> situation of table headers and footers closely. Nevertheless, Jeremias
> presents a Knuth element list which is simpler:
> penalty(pb-after) glue(-pb-before) box PENALTY glue(pb-before)
> According to the table header/footer treatment, the list would be:
> penalty(pb-before + pb-after) at each break possibility, representing
> the border and padding on the page before the break.
> glue(pb-before + pb-after) at the end, representing the single
> occurrence of the border and padding that occurs without any break.
> This solution would be especially more complicated for borders and
> paddings of nested blocks.
> I am wondering why the element list for borders and paddings can be
> constructed in a simpler way than that for table headers/footers. I
> think it is due to the fact that glue can be undone, while boxes
> cannot.

I'm going to look at this more closely this week. For the moment I
ignore spaces and conditional lengths surrounging a table. So I'll come
back to this later. As my next step I'll review my code and will upload
my changes in a temporary branch. Starting from there I'll jump into
handling tables.

Jeremias Maerki

Reply via email to