Re: Vertical spacing regression !?

[Joe Neeman]

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