lilypond-devel
[Top][All Lists]
Advanced

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

Re: ly:one-page-breaking? plus the cheapest line breaking algorithm


From: David Kastrup
Subject: Re: ly:one-page-breaking? plus the cheapest line breaking algorithm
Date: Fri, 21 Nov 2014 10:46:40 +0100
User-agent: Gnus/5.13 (Gnus v5.13) Emacs/25.0.50 (gnu/linux)

Urs Liska <address@hidden> writes:

> I just had an idea and would like to get your opinion on it.
>
> I just read about the " ly:one-line-breaking" function and thought it
> would be a good idea to have a "ly:one-page-breaking" complement for
> it too.
> This would produce a score with regular line length and paper width,
> but on one long page. This could be interesting for applications that
> intend to scroll scores instead of turning pages, and it would
> completely take away the need for calculating page breaks. This could
> be used in "development mode" context as long as you don't care about
> layout and only deal with the content of a score.

I don't see that this has anything to do with "development mode".  It
seems reasonable as a feature by itself.

> This could be complemented with a mode where LilyPond takes the
> absolutely simplest approach to line breaking, i.e. not trying to
> consider adjacent systems regarding their density but simply fills a
> line until it is completed, stretches it (if not ragged-right = ##t)
> and continues to the next.

That would be awful for applications trying to do vertical scrolling as
the regular representation since then the regular representation would
be sloppy.

> I think both these options could lead to faster compilations in
> context where you don't care about layout (yet).
>
> Any opinions?

It would appear to me that the decisions "no page breaks" and "sloppy
line breaks" should not be coupled.

So it would seem to me like we should likely be able to specify the page
breaking strategy (including none) and the line breaking strategy
(including none) independently.

-- 
David Kastrup



reply via email to

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