-The fragment that was printed uses only quarter notes: notes that are
-played in a constant rhythm. The spacing should reflect
-that. Unfortunately, the eye deceives us a little: the eye not only
-notices the distance between note heads, but also between consecutive
-stems. As a result, the notes of a up-stem/down-stem combination
-should be put farther apart, and the notes of a down-up combination
-should be put closer together, all depending on the combined vertical
-positions of the notes. The first two measures are printed with this
-correction, the last two measures without. The notes in the last two
-measures form down-stem/up-stems clumps of notes.
-
-@node Computerized typography
-@section Computerized typography
-
-The example in the previous section is one illustration of how subtle
-music engraving can be is a subtle. Producing good engraving requires
-skill and knowledge.
-
-
-It was our challenge to see if we could put typographical knowledge
-into a computer program. Capturing that knowledge has two aspects:
-first, it has to be acquired. Then, it has to be encoded in
-data-structures and algorithms. As the previous example shows, there
-is a lot of subtlety involved in music engraving, and unfortunately,
-only a small fraction of these tiny details are documented.
-
-One reason for the time that it takes to become a master engraver, is
-that all these details must be learned either from experience or from
-other engravers: as an engraver gets older and wiser, he will be able
-to produce better and more complex pieces. A similar situation is
-present when putting typography into computer programs. It is not
-possible to come up with a final solution for a problem at the first
-try. Instead, we start out with simple solution that might cover 75%
-of the cases, and gradually refine that solution over the course of
-months or years, so that 90 or 95 % of the cases are handled.
-
-This has an important implication for the design of the
-program. During development, almost every piece of formatting code
-must be considered as temporary. When the need arises, is to be
-replaced a solution that will cover even more cases. A clean way to
-accomplish this, is a ``plug-in'' architecture: an architecture where
-new pieces of code can be inserted in the program dynamically. In
-such a program, a new solution can be developed along-side the
-existing code. It can be perfected separately until it is better than
-the existing solution, at which point, the new solution is switched on
-by default, and the old one is removed.
-
-Until that time, users must have a way to deal with imperfections:
-these 25%, 10% or 5% of the cases that are not handled
-automatically. In these cases, a user must be able to override
-formatting decisions. A way to accomplish this, is to store decisions
-in generic variables, and let the user manipulate these variables.
-For example, consider the following fragment of notation.
-
-@lilypond
-\score { \notes {
- g'4-\f g4
- }
-\paper { raggedright = ##t }
- }