On 06/30/2010 01:04 AM, David Kastrup wrote:
until after line-breaking. Also, the vertical collision avoidance means
that in { c1^"long long markup" c1^"long long markup" }, we cannot
calculate the height of the second bar without considering the first bar
too (and the answer will change if they are on different lines).
Maybe I am dull, but we need the line heights (or skyline) for a given
line breakpoint sequence, and a given line breakpoint sequence has a
given skyline for each line.
Correct. And there is O(2^N) breakpoint sequences for N possible
breakpoint places (roughly, for N bars); so we need O(2^N)
heights/skylines and page breakings. The dynamic programming algorithm
deals with this complexity, but even though there are less than O(2^N)
actual configurations to calculate a demerit score for, it is still
prohibitively expensive to perform a full layout every time we need a
demerit score.
Maybe the problem can be alleviated by not associating a fixed line
height/skyline with each bar, but something that is dependent on the
current breakpoint sequence being considered.
Not sure what you mean. We do not and can not have a fixed line height
/ skyline for each bar -- as Joe just explained. For example, consider
music in the G clef; if a particular bar comes after a line break, it
will have a clef, making the bar much taller. So I am not sure what you
have in mind here... something else that I do not see?
Originally, the skyline was approximated by its bounding rectangle. In
other words, there was only one measurement: the "line height". About a
year ago, to address the problem with G clefs, Joe added the distinction
between "begin-" and "rest-of-line", for inter-staff, intra-system
space. (So instead of one point we have two). This worked reasonably
well for music with many staves per system; but for music on one staff
(e.g. instrument parts, or monody) this does no good, because all the
space is inter-system. So about two months ago I introduced the
"begin/rest" distinction for inter-system space (i.e. for computing
pure-height of a whole system). This still left some unaddressed things
like 1062, which is what today's discussion is about.
Boris
_______________________________________________
lilypond-devel mailing list
lilypond-devel@gnu.org
http://lists.gnu.org/mailman/listinfo/lilypond-devel
