On Mon, 2 Jan 2006 12:56 am, Andreas L Delmelle wrote: > On Jan 1, 2006, at 17:15, Manuel Mall wrote: > > The Knuth algorithm (read the paper) deals only with box/pen/glue > > for the purpose of breaking lines and if it breaks a line it takes > > certain actions with respect to discarding pen/glue elements > > directly following > > the break it created. If it doesn't create a line break it leaves > > everything as it is. This means everything at the beginning and end > > of a paragraph is left untouched. line-feed-treatment at the > > beginning and > > end of a paragraph is not influenced by the Knuth algorithm and > > therefore cannot be controlled by whatever sequences we generate. > > Ahem... I do get your point, but the fact of the matter remains that > the trailing spaces should be removed for the reason that they would > end up at the end of a *line-area*, not because they end up at the > end of the *paragraph*. > > I have no trouble grasping the idea that the Knuth algorithm only > creates effective breaks in intermediate positions, and takes certain > actions for those breaks. Ok, so that means the start- or end-of- > paragraph line-break is not created by this algorithm in itself, and > remains out-of-scope here. Would it not be a much easier and much > more straightforward solution to have every paragraph end with an > infinitely low penalty, so that the algorithm eventually treats > trailing spaces in the last line-area just the same as it would for > 'normal' line-breaks?
No, leading and trailing paragraph spaces must be removed BEFORE linebreaking, that is before we get into the Knuth stuff otherwise they may be incorrectly considered as part of the linebreaking line length and adjustment calculations. Therefore when this was done during refinement at the block level it was just the right place IMO. Obviously spaces around formatter generated linebreaks must be dealt with during linebreaking. > > > We can control line-feed-treatment at Knuth generated breaks by > > constructing the proper sequences which we will do eventually. But > > start/end paragraph is outside of that which is why I am keen to > > push it into the FO refinement stage (as it used to be). > > As I said, it's all the same to me. If you (and a few others, of > course) think we were better off before I committed my changes, then > by all means, go ahead and revert... I did my homework, and posted it > as a patch for review first. As I recall, only Finn had anything to > add, and his comment was taken into account. The rest of you remained > silent, which I consider to be at least a '+0' (= go ahead if you > want to, but don't expect any assistance from us, because we already > have our hands full). > That is not the point at all. The previous algorithm was defective in the sense of not dealing with whitespace around markers and possibly other fo's with text content. The task at hand was to extend the whitespace handling to other fo's which were previously omitted, e.g. markers. Your change does that however, it does not preserve the existing functionality. Therefore its progress in one sense and regression in another. What I am asking you to do is to look for a solution were we don't have any regressions and still get the whitespace handling applied to other fos. BTW, if you had mentioned the regression in your patch description I would have raised my objections at that time. You only mentioned it after you applied the patch. > > Cheers, > > Andreas Regards Manuel
