bug-lilypond
[Top][All Lists]
Advanced

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

[Priorities]: Issue 884 is a regression


From: Alexander Kobel
Subject: [Priorities]: Issue 884 is a regression
Date: Wed, 02 Jun 2010 15:35:53 +0200
User-agent: Mozilla/5.0 (X11; U; Linux x86_64; en-US; rv:1.9.1.9) Gecko/20100423 Lightning/1.0b1 Thunderbird/3.0.4

[ Sorry, attachments were to large in the first attempt - see the link below. ]

Dear bug squad,


following the discussion "spacing/breaking issue" on -user, I'm sure that issue 884 <http://code.google.com/p/lilypond/issues/detail?id=884> is a regression, but not classified as such. For verification, I [attached] created output from 2.12.3 (Ubuntu Lucid stable) and 2.13.22 for the very snippet in the bug tracker; 2.12.3 renders two pages as expected, 2.13.22 makes it four. Check out the files under <http://lists.gnu.org/archive/html/lilypond-user/2010-06/msg00001.html>; they're just too big to post them on -bug.

IMHO, the earlier variant is the expected one, so it should not be a documentation issue as mentioned in the bug report: Even _if_ you wanted to specify a certain number of pages between \pageBreaks, you often don't want the _same_ number between all manual breaks (which is what you actually specify via page-count as of 2.13.x). Rather, you want to add \pageBreak at "critical" points like the beginning of a new section or a really good page turn for performances, and leave the rest up to Lilypond. Besides, page-count just implies that you specify the total number of pages, doesn't it?

As an additional enhancement request, it'd be nice to have a "localized" variant of page-count between \pageBreaks. E.g., I could imagine to allow the definition of page-count either as an integer that gives the total number of pages (expected behaviour until 2.12.x), or as a list of integers specifying the number of pages between consecutive \pageBreaks. If \pageBreak really divides the piece into different chunks, as Chris suggested in the bug report, the latter might actually be easier to implement than the first variant.


Cheers,
Alexander



reply via email to

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