Re: Space resolution implementation and break possibility building
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
Space resolution implementation and break possibility building
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
