Am 13.04.2017 um 16:48 schrieb David Nalesnik: > On Tue, Apr 11, 2017 at 5:54 PM, Urs Liska <[email protected]> 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. 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. Urs PS: Still, I haven't found the opportunity to install the latest version to test your suggestions. > > David -- [email protected] https://openlilylib.org http://lilypondblog.org _______________________________________________ lilypond-user mailing list [email protected] https://lists.gnu.org/mailman/listinfo/lilypond-user
