Implementing typography
How do we go about implementing typography? Answering the "music notation" problem left us with a bunch of graphic objects representing note heads, the staff, stems, etc.
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! Since typography relies on human judgement of appearance, people cannot be replaced. However, much of their dull work can be automated: if LilyPond solves most of the common situations correctly, then 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 necessary less and less.
How do we go about building such a system? When we started, we wrote the program in C++. Essentially, this means that the program functionality is set in stone by us developers. That proved to be unsatisfactory:
- If things must be tuned by hand, then the user must access to the formatting engine. Hence, rules and settings cannot be fixed at compile time, but they must be accessible at run-time.
- Engraving is a matter of visual judgement, and hence it is a matter of taste. As knowledgeable as we are, users can disagree with our personal decision. 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 does not match how music notation works.
Next: Program architecture,
your flexible friend: tuning, tweaking and developing typography
rules.