### 1.2 Automated engraving

How do we go about implementing typography? If craftsmen need over ten years to become true masters, how could we simple hackers ever write a program to take over their jobs?

The answer is: we cannot. Typography relies on human judgment of appearance, so people cannot be replaced ultimately. However, much of the dull work can be automated. If LilyPond solves most of the common situations correctly, this will be a huge improvement over existing software. The remaining cases can be tuned by hand. Over the course of years, the software can be refined to do more and more automatically, so manual overrides are less and less necessary.

When we started we wrote the LilyPond program entirely in the C++ programming language, the program's functionality was set in stone by the developers. That proved to be unsatisfactory for a number of reasons:

- When LilyPond makes mistakes, users need to override formatting decisions. Therefore, the user must access to the formatting engine. Hence, rules and settings cannot be fixed by us at compile time, but they must be accessible for users at run-time.
- Engraving is a matter of visual judgment, and therefore a matter of taste. As knowledgeable as we are, users can disagree with our personal decisions. Therefore, the definitions of typographical style must also be accessible to the user.
- Finally, we continually refine the formatting algorithms, so we need a flexible approach to rules. The C++ language forces a certain method of grouping rules that do not match well with how music notation works.

These problems have been addressed by integrating the GUILE interpreter for the Scheme programming language and rewriting parts of LilyPond in Scheme. The new, flexible formatting is built around the notion of graphical objects, described by Scheme variables and functions. This architecture encompasses formatting rules, typographical style and individual formatting decisions. The user has direct access to most of these controls.

Scheme variables control layout decisions. For example, many graphical objects have a direction variable that encodes the choice between up and down (or left and right). Here you see two chords, with accents and arpeggio. In the first chord, the graphical objects have all directions down (or left). The second chord has all directions up (right).

The process of formatting a score consists of reading and writing the variables of graphical objects.

Some variables have a preset value. For example, the thickness of many lines—a characteristic of typographical style—are preset variables. Changing them gives a different typographical impression

Formatting rules are also preset variables: each object has variables containing procedures. These procedure perform the actual formatting, and by substituting different ones, we can change behavior. In the following example, the rule that note head objects use to produce their symbol is changed during the music fragment

Read comments on this page, or add one. This page is for LilyPond-2.2.2 (stable-branch).