Re: Issue 37 - new work

[Graham Percival]

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
> <address@hidden> 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