[Top][All Lists]
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: Page and line penalties
From: |
Han-Wen Nienhuys |
Subject: |
Re: Page and line penalties |
Date: |
Fri, 07 Apr 2006 11:55:01 +0200 |
User-agent: |
Thunderbird 1.5 (X11/20060313) |
Joe Neeman wrote:
Suppose we add penalties. Let G(B) be the penalty function for a partition
into lines. G(B) has no nice structure at all. It will probably be zero most
of the time, with a few very large spikes. And we want to minimize F(B) +
G(B). Suppose the user makes a small change:
I believe most of what you say; however, there are some questions:
* IIRC, line breaking is not that stable as you suggest. It tends to
have the same problem. Due to uniform density scoring, two consecutive
line breaks may also have global effects.
* Did you look at penalties for page-breaking at rests, or did you also
put penalties for line-breaking?
* Isn't it possible to devise a G(B) which has a more regular structure?
What kind of G(B)'s did you try? I can imagine it might be
difficult, but have we thought about all the alternatives?
The problem that you sketch is not caused by F(B) being nice and G(B)
not, but rather because their magnitudes are very similar.
For example, what if you adjust the penalty of a page-breaks by using
the max distance to the next/previous rest? Then an isolated rest in a
fully filled score will get a huge bonus, but for scores with more
rests, the penalties will be small, relative to the spacing penalties.
* is there any value in removing page-break penalties? Shouldn't we
rather add a forbid/allow property, and otherwise just use normal
penalties? Then we use forbid/force for user tweaks, with automatic
penalties (ie. restrict the domain of possible B). This doesn't change
the shape of the graph, just the parts that we consider. Of course, this
may still cause jumps of the optimum, but they might be more predictable
LilyPond's algorithm BTW, indeed is very similar to TeX's for line breaking.
PS: This also solves the problem that the penalties are arbitrary values.
Currently, Lilypond might conceivably ignore a user-forced \break if it
causes the forces to work out too badly.
I agree that we have to stop using penalties as a kludge for force/forbid.
--
Han-Wen Nienhuys - address@hidden - http://www.xs4all.nl/~hanwen
LilyPond Software Design
-- Code for Music Notation
http://www.lilypond-design.com
- Re: Page and line penalties, (continued)
- 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
- Re: Page and line penalties, David Feuer, 2006/04/07
- Re: Page and line penalties, Werner LEMBERG, 2006/04/07
Re: Page and line penalties,
Han-Wen Nienhuys <=