Re: wish: ly:cheapest-breaking (or whatever name)

2015-01-23 Thread Ralph Palmer
On Mon, Jan 19, 2015 at 9:33 AM, Urs Liska u...@openlilylib.org wrote:

 Hi list,

 following up on a thread that I started some time ago (
 http://lists.gnu.org/archive/html/lilypond-devel/2014-11/msg00139.html)
 I'd like to draw the conclusions from that and ask for an additional
 breaking algorithm.


Hi, Urs and List - At the risk of creating noise, but hoping to help keep
it from getting lost, I've submitted this as a feature request : Issue 4271
https://code.google.com/p/lilypond/issues/detail?id=4271. Please let me
know if this was impertinent or unnecessary.
Ralph
___
bug-lilypond mailing list
bug-lilypond@gnu.org
https://lists.gnu.org/mailman/listinfo/bug-lilypond


Re: wish: ly:cheapest-breaking (or whatever name)

2015-01-23 Thread Urs Liska


Am 23.01.2015 um 13:35 schrieb Ralph Palmer:
On Mon, Jan 19, 2015 at 9:33 AM, Urs Liska u...@openlilylib.org 
mailto:u...@openlilylib.org wrote:


Hi list,

following up on a thread that I started some time ago
(http://lists.gnu.org/archive/html/lilypond-devel/2014-11/msg00139.html)
I'd like to draw the conclusions from that and ask for an
additional breaking algorithm.


Hi, Urs and List - At the risk of creating noise, but hoping to help 
keep it from getting lost, I've submitted this as a feature request : 
Issue 4271 https://code.google.com/p/lilypond/issues/detail?id=4271. 
Please let me know if this was impertinent or unnecessary.

Ralph


??
No, that was the intention of my post ;-)

Best
Urs
___
bug-lilypond mailing list
bug-lilypond@gnu.org
https://lists.gnu.org/mailman/listinfo/bug-lilypond


wish: ly:cheapest-breaking (or whatever name)

2015-01-19 Thread Urs Liska

Hi list,

following up on a thread that I started some time ago 
(http://lists.gnu.org/archive/html/lilypond-devel/2014-11/msg00139.html) 
I'd like to draw the conclusions from that and ask for an additional 
breaking algorithm.


It would be nice to have a compilation mode that doesn't care about 
optimizing page layout through calculating good line and page breaks 
(or page turns) but that rather fills a line until it's full and then 
inserts a break at the latest allowed moment. The line can then be 
spread out to fill the line width or not, depending on the ragged setting.


The idea behind it is: While working on the *content* of a score one 
doesn't necessarily have to care about the beauty of the page layout at 
all, and so it would make sense to speed up compilation by not having 
LilyPond to care about it either.


There is another idea behind it which is related to another wish I'll 
post separately. Such a compilation mode would make it less likely that 
small changes in the input cause changes in the line (and page) 
breaking. These would only occur when the current system actually 
becomes longer or shorter by half a measure (in a simplified view).


I can't imagine that this should be too hard to implement, but I don't 
have a clue where this would have to start, presumably in the C++ part?


Urs

___
bug-lilypond mailing list
bug-lilypond@gnu.org
https://lists.gnu.org/mailman/listinfo/bug-lilypond