lilypond-devel
[Top][All Lists]
Advanced

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

Re: Vertical spacing regression !?


From: Boris Shingarov
Subject: Re: Vertical spacing regression !?
Date: Wed, 30 Jun 2010 04:21:04 -0400
User-agent: Mozilla/5.0 (X11; U; Linux x86_64; en-US; rv:1.9.1.9) Gecko/20100423 Thunderbird/3.0.4

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




reply via email to

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