lilypond-devel
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: Page and line penalties


From: Joe Neeman
Subject: Re: Page and line penalties
Date: Fri, 7 Apr 2006 19:17:59 +1100
User-agent: KMail/1.8.3

On Fri, 7 Apr 2006 16:31, Werner LEMBERG wrote:
> TeX has exactly the same problem.
Does TeX allow the user to arbitrarily assign penalties for inserting a line 
break at the end of any word?

> Interestingly, Knuth seems to have 
> accepted this.  Isn't it possible to provide default values for the
> badness, stretchable and shrinkable space, and other parameters which
> ensure a certain layout stableness?
I admit to not knowing a great deal about TeX's breaking algorithm. But the 
description on the wikipedia page on TeX suggests that it is very similar to 
what ours would be if we got rid of penaties. Lily already does nice things 
with stretchable/shrinkable space and badness calculations. I'm not proposing 
changing this.

>
> > [...] I think the unpredictability and instability of the result
> > make it not worthwhile trying to do this automatically.
>
> I disagree.  Dense typesetting (this is, not having much shrinkable
> horizontal space) will *always* cause large shifts of system and page
> breaks.
OK, so the solution will always have a certain level of instability. Just to 
put some idea of scale on my previous example graphs, it's possible that 
LilyPond will be tossing up between using 5 systems and using 10 systems. 5 
systems provides much better spacing but 10 systems has less penalties. The 
total badness is _slightly_ less for 5 systems so Lily goes with that.

Then the user inserts an extra bar and the number of systems doubles. I think 
that instability shouldn't occur on this scale.

Now, I haven't been playing around with any line penalties, but I have done 
experiments with page turn penalties and I have seen scores go from 5 to 8 
pages with only small changes.

I should also be clear that I'm not suggesting changing the _current_ 
algorithm to make it more stable. Currently we only use _huge_ positive and 
negative penalties that have a fairly predictable effect -- these would just 
be replaced (10001 -> FORBID, 0 -> ALLOW, -10001 -> FORCE) so current usage 
wouldn't change. I only want to restrict it so that the current usage of 
penalties will be the only usage.

Joe




reply via email to

[Prev in Thread] Current Thread [Next in Thread]