lilypond-user
[Top][All Lists]
Advanced

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

Re: RFC: new vertical layout engine


From: Cameron Horsburgh
Subject: Re: RFC: new vertical layout engine
Date: Tue, 16 Jun 2009 22:32:47 +1000
User-agent: Wanderlust/2.15.6 (Almost Unreal) SEMI/1.14.6 (Maruoka) FLIM/1.14.9 (Gojō) APEL/10.7 Emacs/23.0.94 (i486-pc-linux-gnu) MULE/6.0 (HANACHIRUSATO)

At Mon, 15 Jun 2009 18:25:54 +0300,
Joe Neeman <address@hidden> wrote:
> 
> [1  <multipart/alternative (7bit)>]
> [1.1  <text/plain; ISO-8859-1 (7bit)>]
> 
> [1.2  <text/html; ISO-8859-1 (quoted-printable)>]
> I've started working on a new system for doing vertical layout in one pass 
> (ie. positioning and
> stretching the systems simultaneously). This should give better default 
> behaviour than the
> current code and it should also allow easier and more useful overrides. I 
> plan to merge the code
> after 2.14 is released, so it should appear in the 2.16 stable version. The 
> code is currently in
> the dev/jneeman git branch. It basically works (I hope), but it is missing a 
> lot of previously
> existing functionality. I'm interested in hearing from people who like to 
> override vertical
> spacing stuff (even more so if they can compile from git and test things): 
> what sort of
> overrides do you use and what sort of overrides would you like to have 
> available? Also, are
> there any "high-level" overrides that would free you from having to position 
> systems manually?
>

I produce a lot of conductor's scores (with one system to a page) but
I've always found the spacing to detract a lot from the overall
excellence of the typesetting. I've just tried out the new code on one
of my scores and I must say I am very impressed with the result. In
fact, I'm going to print my most recent score and replace the one I
delivered a couple of weeks ago. It is far, far better.

I don't usually use a lot of the fancier layout stuff, so I'm
wondering what you have removed from this version. However, I would
most certainly use some of the grouping schemes Reinhold mentioned in
his message.

I have noticed one thing---the vertical positioning of the system
seems to be very much at the mercy of what is going on in the top
staff. I assume this is because the margin is fairly hard. In this
particular case the top staff is a flute line. If there are notes
above the staff, the whole staff (and thus the system) is pushed down
so the notes fit below the margin.

> My current plans:

(snip)

> - replace alignment-offsets with alignment-distances (ie. you have to specify 
> the distances
> between adjacent staves rather than the absolute offsets). The reasoning: I 
> can't see how to
> implement (alignment-distances . (#f #f #f 40)) in a sane way (it's easy to 
> do it in a naive
> way: do automatic spacing and then override the position of the last staff in 
> the system, but
> that would give weird results since the next system will be spaced assuming 
> that the last staff
> in the current system is in the automatic position, rather than the 
> overridden position).
 
What I would ideally like (for systems-per-page = #1) is for the top
line of the top staff and the bottom line of the bottom staff to be
the same for every page, and everything suitably spread out
between. In other words, the top and bottom staves should be given
absolute positions and everything else is calculated afterwards.

Or am I being a little bit naive?

-- 

Cameron Horsburgh

Blog: http://spiritcry.wordpress.com/




reply via email to

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