+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. 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. Master engravers must learn all these details from
+experience or from other engravers, which is why it takes so long to
+become a master. 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 typographical knowledge into a computer program.
+It is not possible to come up with a definitive 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 90 or 95 % of the cases are
+handled.
+
+This has an important implication for the design of the program: at
+any time, almost every piece of formatting code must be considered as
+temporary. When the need arises, it is to be replaced a solution that
+will cover even more cases. A ``plug-in'' architecture is a clean
+way to accomplish this. This is 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. For
+testing, it is plugged in, but for production use, the old solution is
+used. The new module can be perfected separately until it is better
+than the existing solution, at which point it replaces the old one.
+
+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. To accomplish this we store decisions in generic
+variables, and let the user manipulate thosed. For example, consider
+the following fragment of notation:
+
+@lilypond
+\score { \notes \relative c'' {
+\stemUp
+ a4_\f f,8
+ }
+\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 \relative c'' {
+\stemUp
+ \once\property Voice. DynamicLineSpanner \override #'padding = #4.0
+ a4_\f f,8
+ }
+\paper { raggedright = ##t }
+ }
+@end lilypond
+
+This was achieved with the following input statement:
+@example
+ \once \property Voice. DynamicLineSpanner \override #'padding = #4.0
+@end example
+It 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). The keyword @code{\once} indicates that
+this is a tweak: it is only done one time.
+
+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 the
+following command, the entire piece is now formatted with thicker stems:
+@example
+ \property Score.Stem \override #'thickness = #3.0
+@end example
+
+@lilypond
+\score { \notes \relative c'' {
+ \property Score.Stem \override #'thickness = #3.0
+ \once\property Voice. DynamicLineSpanner \override #'padding = #4.0
+\stemUp
+ a4_\f f,8
+ }
+\paper { raggedright = ##t }
+ }
+@end lilypond