On Fri, Jan 28, 2011 at 04:18:16PM -0200, Han-Wen Nienhuys wrote: > On Fri, Jan 28, 2011 at 11:43 AM, Graham Percival > <[email protected]> wrote: > > lilypond -p 0 my_file.ly % for quick work > > lilypond -p 2 my_file.ly % for a draft to print out > > lilypond -p 9 my_file.ly % for the final score > > I think most of these will go unused, as very few people will know how > and when to tune them. Having configurable settings is neat, but it's > far more important to do the right thing by default in 95% of the > cases.
That's actually precisely why I'm suggesting a -p X option. People (generally) aren't going to look into the depths of the page breaking / beam calculation / text column collision handling code. So let's just give them a "bad quality / good quality" command! (admittedly, in the above example I implicitly divided the "quality" into 9 levels, not 1) SPEED Composer (or typesetter) working by himself, just entering pitches and rhythms: use 0 quality. Who cares what it looks like, as long as he can see that the notes are in the right octave, it fits into bars, etc. Let slurs go through noteheads, draw accidentals on every note, use a monospace/courier "f" instead of a dynamic font... ok, maybe that's an exaggeration, but the point remains: at some point in people's work on a composition, they would *gladly* accept absolute crap typography in exchange for dividing the processing time by 2. I honestly think that if somebody seriously looked into this, we could divide the processing time (for crap output) by 10 for most scores. QUALITY Composer producing final (or near-final) version: use highest quality. Resolve beam collisions, try to have page turns at rests, keep text, etc etc. These two usage cases are very different; there is just no way to do "the right thing". Cheers, - Graham _______________________________________________ lilypond-devel mailing list [email protected] http://lists.gnu.org/mailman/listinfo/lilypond-devel
