On Mon, 2010-06-28 at 06:34 -0400, Boris Shingarov wrote: > On 06/27/2010 01:25 PM, Joe Neeman wrote: > > On Sun, 2010-06-27 at 06:56 -0400, Boris Shingarov wrote: > > > > > This was discussed on this list only a few weeks ago. I think we > > are on > > > our way to get rid of global page*line breaking. > > > > Although I am happy to have an option to do full line-breaking before > > page-breaking, I am very much against getting rid of the line and > > page-breaking interaction. For example, if we did that then we would > > have to scrap the new vertical layout since it relies on being able to > > stretch the systems after the pages are determined. And while I have a > > personal bias against scrapping the vertical layout (since I wrote it), > > I do think that it is a big improvement over the previous layout > > algorithm and I have heard comments to that effect on the lists too. > > Also, the page-turn-breaker can't function without some interaction > > between line- and page-breaking. > I understand the bad effects of divorcing line- from page-breaking. > Another one (of those which I personally care about) is that it will > negate the window/orphan handling feature I added. At least to my > users, this is important. And yes, I do agree that the new layout > algorithm *is* a big improvement over the previous one. > > But what do we do about the height estimation problems?
For one thing, we can add an option to do the full horizontal layout first. system-count used to have this effect, so it isn't even very hard (see issue 325). > No matter how > important the positive effects of line/page-breaking interaction are, a > score with staves cut at the bottom, is unusable. Agreed. There used to be a feature that would detect an overfull page and try to lay it out again without any padding between staves, but it didn't make it into the new page layout algorithm. It could be reinstated. > And a score with the > opposite problem, is equally unusable. I don't entirely agree with this one. Unless you have ragged-bottom=##t, underfilling the page by a single system is hardly noticeable (whereas overfitting by a single system is, of course). > Can we realistically hope to fix > enough bugs so that real publications will look usable? I have seen real publications that use 2.12 (which also used height-estimation). There are workarounds (like the page-breaking-between-system-spacing variable) and there could be more workarounds (like an option for doing the horizontal layout first). And the complaints from the lists have died down a lot compared to when the page-breaking*line-breaking was first introduced (2.9, IIRC), so I think we are converging on something that works consistently. > I don't know. > I started working on the estimations because the user's book suffered > the problem. I fixed five, and pulled your fixes for a few. And yet > the book is still suffering the same problem. I know what causes it > *now*, but I do not know if this is going to be the last one *for this > book*, and I am now facing problems of customer value when talking about > fixing height estimation bugs. > > So what are we going to do, keep fixing these bugs, under the theory > that there is only finite number of them? One thing that makes me > nervous is that a lot of the time the fixes involve increase of > computational complexity. We are moving from simple height estimation > to more and more complex height estimation; can it be that as we > approach being more and more correct in our estimation, the complexity > also approaches that of full layout? We are still very far from full layout. As long as we avoid horizontal spacing (and all the layout that it requires), I think we're ok. Cheers, Joe _______________________________________________ lilypond-devel mailing list lilypond-devel@gnu.org http://lists.gnu.org/mailman/listinfo/lilypond-devel
