Thanks for your reaction.

On Tue, Sep 12, 2006 at 08:26:49PM +0200, Vincent Hennebert wrote:
> >According to that representation paragraphs with inline text have
> >legal linebreak points. I consider those legal linebreak points also
> >as legal pagebreak points. In addition, there are legal pagebreak
> >points between the vertical elements such as paragraphs and blocks.
> One issue that will have to be addressed is that widow or
> keep-with-previous settings may invalidate some previously believed
> legal breakpoints. In such cases, active nodes which contain those
> breakpoints in their chains will have to be deactivated; if they were
> the chosen best nodes, some other nodes will somehow have to be
> retrieved to replace them. I hope this won't be a too great difficulty.

Indeed, you mentioned it before. It certainly is a complicating factor.
> >In page independent linebreaking, for each feasible breakpoint the
> >best node is retained, which represents the best layout of the
> >paragraph up to that point, and which, due to the dynamic principle,
> >is part of the best layout of the whole paragraph if that layout uses
> >this breakpoint. If line numbers matter, the best node for each line
> >number is retained. In page dependent linebreaking, even that is not
> >enough. We must retain the best node for each vertical offset on the
> >page, because that is the quantity that influences page breaking. This
> Good point. This led me to the following thoughts:
> Currently the iteration over the active nodes is broken into two loops:
> one loop for iterating over the line numbers, one for iterating over the
> active nodes associated to each line number. Why? Because if line widths
> aren't the same they have an influence on the computation of best line
> breaks. Because when considering a given legal breakpoint, we must know
> the width of the line it would end in order to be able to compute the
> shrinking/stretching for that line. In fact we make a distinction
> between line numbers because they determine the /context/ in which
> linebreaks are computed. If all the lines had the same widths such a
> distinction wouldn't be necessary.
> The merging of line- and page-breakings generalizes this problem of
> differing contexts. This time, not only the line number counts, but also
> the page number, the offset from the beginning of the page, the
> out-of-lines to be placed, etc. I think the greatest challenge will be
> to identify all the elements which determine that context, and to be
> able to compare two contexts and say if they are equivalent or not.
> Considering the case 1 you describe on the wiki page, there are only two
> different contexts: page number even or odd. In this case the offset
> from the beginning of the page doesn't count. In other more complex
> documents this may be much more complicated.

Yeah, difficult point. I do not think I understand this aspect well

> >In most cases the whole paragraph will fit on the page, and the legal
> >pagebreak point after it is not feasible. So we do another paragraph,
> >and another. Finally we will reach a feasible pagebreak point, which
> >ends page 1. The corresponding linebreak point ends a line which is
> >able to fill the page height with maximally tolerable stretching. In
> >the next steps we will find more feasible pagebreak points. They
> >correspond to different layouts of the last paragraph that starts on
> >this page, with the same number of lines, and to layouts with more
> >lines, which also fit on the page, until the maximal shrink is
> >exceeded. At this point the starting node is deactivated, and the
> >active page node list only contains nodes that end page 2.
> Unless I've missed something: that end page *1*. Or?

Yes. Thanks.

> >It should be noted that for each feasible pagebreak node, we restart
> >the linebreaking calculations of that page. Of course we must optimize
> >this. We could attach a data structure to the starting page node which
> >records the results of the calculations done. Those results consist of
> >the active line node list, the last linebreak point considered, and
> >the widths calculated up to that point. During uninterrupted linebreak
> >calculation these data are held in loop variables. Now we must store
> >them so that they can be retrieved when we resume the calculation in
> >the consideration of the next current pagebreak point. On the first
> If the main loop were iterating over line breaks, we wouldn't have to do
> this. But perhaps we would have to for pagebreaks then? Which would be
> equivalent, but I can't figure out yet.

I have not thought about the problem in this way. It seems unnatural
to me and also rather equivalent. 

I will update the wiki page as soon as I can reach it again.

Regards, Simon

Simon Pepping
home page:

Reply via email to