On 19.04.2005 22:05:26 Simon Pepping wrote: > Jeremias, > > On Mon, Apr 18, 2005 at 05:08:36PM +0200, Jeremias Maerki wrote: > > Thanks to Luca, lists are essentially dealt with. After an easy fix the > > current test cases for lists all pass. > > > > What remains of the crucial parts for the Knuth approach is the border > > handling for tables. I don't think I can do that until Wednesday. > > Tomorrow I have appointments almost all day and I'll be off-line during > > Thursday and maybe Friday. We've now collected some experience with the > > Knuth approach and I'd say although the remaining problem is quite > > complicated I think we can make it work. That would mean we can merge > > the Knuth branch back into CVS HEAD. But I'd like to hear your opinions, > > too. There's still a slight chance of hitting a dead end with tables > > which makes me a bit uneasy. So I'd rather extend the deadline for > > about 10 days just to be sure. > > I have not had the time to probe the new code to a great extent. What > I see looks good. > > I noticed that each line in a paragraph has the height of the first > line of that paragraph. That is not correct, and may invalidate test > files.
Thanks for the hint. We'll need to create a test case for that. > I also noticed that the whole page sequence is read before pages are > created. Is that going to change, as discussed some time ago? I've given that some thought and put it off for now. There are a few points to consider here: - The generation of Knuth elements would have to be restartable at arbitrary points. - For changing available IPD we need a tracking mechanism that decides that enough elements are generated to create content up to the page after which the available IPD changes. This needs to be as optimal as possible to avoid too many discarded created elements. - Not handling the whole page-sequence at once kills the benefits for optimal page breaking for book style documents. The algorithm is reduced to a first/best fit. This is no problem for business documents however. The points above are probably not trivial to handle. > > Does anyone see any other possible issues with the branch that I may > > have forgotten? > > I am worried about performance. Knuth elements are passed up and down > the LM tree, and at each step the Position is wrapped or > unwrapped. That probably occurs very many times, and together these > operations could require considerable processing time. Perhaps it can > be avoided. I do not see a fundamental reason why the whole stack of > ancestral LMs should be contained in a Knuth element. Good point. With just a little additional flexibility in the addAreas() methods we can probably get rid of the wrapping. A good thing would certainly be a speed comparison between 0.20.5, current CVS HEAD and the Knuth branch. I'll see if I can do a short investigation next week, just to see if we're way off. Jeremias Maerki
