+The fragment only uses quarter notes: notes that are played in a
+constant rhythm. The spacing should reflect that. Unfortunately, the
+eye deceives us a little: not only does it notice the distance between
+note heads, it also takes into account the distance between
+consecutive stems. As a result, the notes of an 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 Typography and program architecture
+@section Typography and program architecture
+
+Producing good engraving requires skill and knowledge. It was our
+challenge to see if we could put such 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 examples show, there is a lot of subtlety
+involved in music engraving, and unfortunately, only a small fraction
+of these 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 }
+ }
+@end lilypond
+
+@noindent
+The position of the forte symbol is slightly awkward, because it is
+next to the low note, whereas dynamics should be below notes in
+general. This may be remedied by inserting extra space between the
+high note and the `f', as shown in this example
+
+@lilypond
+\score { \notes {
+ \once\property Voice. DynamicLineSpanner \override #'padding = #4.0
+ g'4-\f g4
+ }
+\paper { raggedright = ##t }
+ }
+@end lilypond
+
+This was achieved with the input statement
+@example
+ \property Voice. DynamicLineSpanner \override #'padding = #4.0
+@end example
+which increases the amount of space (@code{padding}) between the note
+and the dynamic symbol to 4.0 (which is measured in staff space, so
+4.0 equals the height of a staff).
+
+Both design aspects, a plug-in architecture, and formatting variables,
+are built on top of GUILE, an interpreter for the programming language
+Scheme, which is a member of the LISP family. Variables are stored as
+Scheme objects, and attached to graphical objects such as note heads
+and stems. The variables are a means to adjust formatting details in
+individual cases, but they are used in a more general manner.
+
+Consider the case of a publisher that is not satisfied with the in the
+default layout, and wants heavier stems. Normally, they are @code{1.3}
+times the thickness of staff lines, but suppose that their editions
+require them to be twice the thickness of the staff lines. The same
+mechanism can be used to adjust a setting globally. By issuing
+@example
+ \property Score.Stem \override #'thickness = #2.0
+@end example
+the entire piece is formatted with thick stems:
+@lilypond
+\score { \notes {
+ \property Score.Stem \override #'thickness = #2.0
+ \once\property Voice. DynamicLineSpanner \override #'padding = #4.0
+ g'4-\f g4
+ }
+\paper { raggedright = ##t }
+ }
+@end lilypond