[Top][All Lists]
[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
- Re: Page and line penalties, Joe Neeman, 2006/04/06
- Re: Page and line penalties, Werner LEMBERG, 2006/04/07
- Re: Page and line penalties,
Joe Neeman <=
- Re: Page and line penalties, Juergen Reuter, 2006/04/07
- Re: Page and line penalties, Han-Wen Nienhuys, 2006/04/07
- Re: Page and line penalties, Joe Neeman, 2006/04/07
- Re: Page and line penalties, Han-Wen Nienhuys, 2006/04/07
- Re: Page and line penalties, Joe Neeman, 2006/04/07
- Re: Page and line penalties, Han-Wen Nienhuys, 2006/04/09
- Re: Page and line penalties, David Feuer, 2006/04/07
- Re: Page and line penalties, Joe Neeman, 2006/04/07
- Re: Page and line penalties, Han-Wen Nienhuys, 2006/04/07
- Re: Page and line penalties, Joe Neeman, 2006/04/07