On Fri, Apr 14, 2017 at 1:38 AM, Urs Liska <u...@openlilylib.org> wrote: > > > Am 13.04.2017 um 16:48 schrieb David Nalesnik: >> On Tue, Apr 11, 2017 at 5:54 PM, Urs Liska <u...@openlilylib.org> wrote: >>> >>> Am 11.04.2017 um 21:04 schrieb tisimst: >>> >>> >>> >>> On Tue, Apr 11, 2017 at 1:00 PM, Urs Liska [via Lilypond] <[hidden email]> >>> wrote: >>>> >>>> >>>> Am 11.04.2017 um 20:46 schrieb Malte Meyn: >>>>> Am 11.04.2017 um 20:36 schrieb Urs Liska: >>>>>> So, is there any moment in the compilation process where the natural, >>>>>> unstretched length of a measure can be calculated? It doesn't have to >>>>>> be >>>>>> an easily-read property and can involve calculation, but actually the x >>>>>> position of the barlines would be an easy target - *if* there's this >>>>>> magic moment in the compilation pipeline ;-) >>>>> Maybe you could experiment with the ly:one-line-breaking? >>>> I don't think so (only, of course, to investigate how much can be done >>>> on the internal level). >>>> Basically what I'm after is a ly:cheap-line-breaking mode that doesn't >>>> care at all about overall appearance or good page turns but instead >>>> simply places as many measures in a line as fit naturally. If then a >>>> line break changes and I know the natural width of the measures I can >>>> determine before compilation how many measures will fit on the *next* >>>> system. >> But given clefs, key signatures, cautionaries, doesn't this mean that >> you need to know the width of any measure as the first measure of the >> line, as the last measure on a line, at a median position? > > Ah yes, this is true. But I guess we could do with some estimates here > (see below). > >> >> I'm not clear on the need to know how many measures will fit on >> subsequent lines before compilation. Is it so that you can compile by >> system? >> >> (Just trying to get a handle on your goals so I can help better.) > > Yes, you're right. I'm not going to tackle this right now, but I have to > think about it for writing some plans. > I'm thinking about a "music entry mode" where I don't care at all about > "good" line and page breaking, so music can just be engraved like Word > "justifies" paragraphs - just fill the line and then go to the next.
Doesn't ly:minimal-breaking already do this? It might try out different line configurations -- I'm not entirely sure -- but looks pretty stripped down. > > Given that the music is available in a measure-by-measure state and > given that it is available in a parsed state from a LilyPond server > (both of which I hope to achieve one day) this would mean that I can > simply recompile the "current" system as long as the changed don't > require a change in line breaking. Only then I'd have to recompile the > next system as well, and then the next if the changed lines requires > this. I could do this sequentially, so the score would also update > incrementally without having to wait for the full compilation. But if I > knew the natural width of each existing measure I could perform the > calculations up front and decide which system should contain which > measures. In that case one could even have the systems be engraved in > parallel. > If any of these subsequent system fails because the measures don't fit > on it (BTW some help could be available by LilyPond's ability to squeeze > the system a bit) the parallel engraving could be stopped and restarted > in the incremental fashion. OK, I understand. This would be a great selling point.. Possibly related: have you considered the page/scroll view option from *ahem* Finale? (In scroll view, of course, all music is on a single line, whereas page view presents pages roughly as they will be engraved.) About "natural measure widths": I'm still poking around, hoping that you wouldn't need to run a copy of various structures through the page/line breaking algorithms. > > Urs > > PS: Still, I haven't found the opportunity to install the latest version > to test your suggestions. > Oh, I just added the latest bell-and-whistle assuming that you're always at the forefront! You can get the extents in other ways: Replace (lambda (c) (ly:paper-column::break-align-width c '(break-alignment))) with (lambda (c) (ly:generic-bound-extent c sys)) or (lambda (c) (ly:grob-extent c sys X)) HTH, David _______________________________________________ lilypond-user mailing list lilypond-user@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-user