summaryrefslogtreecommitdiff
path: root/Documentation/automated-engraving/implementing-typography.itexi
blob: 2bf029e4a3e1e64c5f52a8aac2141c634e4f19de (about) (plain)
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70
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,Program architecture,
your flexible friend}: tuning, tweaking and developing  typography
rules.

@bye