summaryrefslogtreecommitdiff
path: root/Documentation/automated-engraving/implementing-typography.itexi
diff options
context:
space:
mode:
Diffstat (limited to 'Documentation/automated-engraving/implementing-typography.itexi')
-rw-r--r--Documentation/automated-engraving/implementing-typography.itexi71
1 files changed, 71 insertions, 0 deletions
diff --git a/Documentation/automated-engraving/implementing-typography.itexi b/Documentation/automated-engraving/implementing-typography.itexi
new file mode 100644
index 0000000000..074695f620
--- /dev/null
+++ b/Documentation/automated-engraving/implementing-typography.itexi
@@ -0,0 +1,71 @@
+\input texinfo @c -*- coding: utf-8; mode: texinfo; -*-
+@ignore
+ Translation of GIT committish: FILL-IN-HEAD-COMMITTISH
+
+ When revising a translation, copy the HEAD committish of the
+ version that you are working on. See TRANSLATION for details.
+@end ignore
+
+
+
+
+@node implementing-typography
+
+
+@unnumberedsec 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:
+
+@itemize
+@item
+ 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.
+
+
+@item
+ 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.
+
+
+@item
+ 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.
+
+
+@end itemize
+
+Clearly, there is a need for a flexible architecture. The architecture
+should encompass formatting rules, typographical style and individual
+formatting decisions.
+
+@divClass{float-right}
+@divEnd
+Next: @ref{formatting-architecture.html,Program architecture,
+your flexible friend}: tuning, tweaking and developing typography
+rules.
+
+@bye
+