Space resolution implementation and break possibility building

[Simon Pepping <sp...@leverkruid.nl>]

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.

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.

Regards, Simon

-- 
Simon Pepping
home page: http://www.leverkruid.nl

Re: Space resolution implementation and break possibility building

[Jeremias Maerki <de...@jeremias-maerki.ch>]

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
later.

> 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