Sanford Sutton.
* mf/GNUmakefile: unset sauter-fonts.
+2004-02-27 Han-Wen Nienhuys <hanwen@xs4all.nl>
+
+ * Documentation/user/refman.itely: documentation patch by Edward
+ Sanford Sutton.
+
+ * mf/GNUmakefile: unset sauter-fonts.
+
2004-02-27 Jan Nieuwenhuizen <janneke@gnu.org>
* input/test/chord-names-jazz.ly:
@menu
* Inline Scheme::
* Input variables and Scheme::
-* Scheme datatypes::
+* Scheme data types::
* Assignments::
@end menu
-@node Scheme datatypes
-@subsection Scheme datatypes
+@node Scheme data types
+@subsection Scheme data types
Scheme is used to glue together different program modules. To aid this
glue function, many LilyPond specific object types can be passed as
In effect, the input format is a language, and the rules of that
language can be specified succinctly with a so-called context-free
-grammar. The grammar formally specificies what types of input form
+grammar. The grammar formally specifies what types of input form
valid `sentences'. Reading such languages, and splitting them into
grammatical structures is a problem with standard solutions.
Moreover, rigid definitions make the format easier to understand: a
(available @uref{../lilypond-internals/lilypond-internals.html,here})
@end ifhtml
-The program reference is a set of heavily crosslinked HTML pages,
+The program reference is a set of heavily cross linked HTML pages,
which documents the nit-gritty details of each and every LilyPond
class, object and function. It is produced directly from the
formatting definitions used.
After you have gone through the tutorial, you should be able to write
input files. In practice, writing files from scratch turns out to be
-intimidating. To give you a headstart, we have collected a number of
+intimidating. To give you a head start, we have collected a number of
often-used formats in example files. These files can be used as a
start: simply copy the template, and add notes in the appropriate
places.
This collection of files tests each notation and engraving feature of
LilyPond in one file. The collection is primarily there to help us
-debug problems, but it can be instructive to see how we excercise the
+debug problems, but it can be instructive to see how we exercise the
program. The format is like the tips and tricks document.
@end itemize
@cindex internal documentation
@cindex Scheme
@cindex extending lilypond
-@cindex bugreport
+@cindex bug report
@cindex index
Finally, this and all other manuals, are available online both as PDF
pleasant way.
Our users not only give us good vibes by using our program, many of
-them also help us by giving suggestions and sending bugreports. So
+them also help us by giving suggestions and sending bug reports. So
first and foremost, we would like to thank all users that sent us
-bugreports, gave suggestions or contributed in any other way to
+bug reports, gave suggestions or contributed in any other way to
LilyPond.
We would also like to thank the following people: Mats Bengtsson for
-the incountable number of questions he answered on the mailing list,
+the uncountable number of questions he answered on the mailing list,
and Rune Zedeler for his energy in finding and fixing bugs. Nicola
Bernardini for inviting us to his workshop on music publishing, which
was truly a masterclass, and Heinz Stolba and James Ingram for
Long notes can be converted automatically to tied notes. This is done
by replacing the @internalsref{Note_heads_engraver} by the
@internalsref{Completion_heads_engraver}.
-In the following examples, notes crossing the barline are split and tied.
+In the following examples, notes crossing the bar line are split and tied.
@lilypond[noindent,verbatim,relative=1]
@refbugs
If a staff is ended halfway a piece, the staff symbol may not end
-exactly on the barline.
+exactly on the bar line.
@node Key signature
can be specified by setting this property directly.
Accidentals and key signatures often confuse new users, because
-unaltered notes get natural signs depending on the keysignature. The
+unaltered notes get natural signs depending on the key signature. The
tutorial explains why this is so in @ref{More about pitches}.
@refbugs
The @code{set-octavation} function also takes -1 (for 8va bassa) and 2
(for 15ma) as arguments. Internally the function sets the properties
-@code{ottavation} (eg. to @code{"8va"}) and
+@code{ottavation} (e.g. to @code{"8va"}) and
@code{centralCPosition}. For overriding the text of the bracket, set
@code{ottavation} after invoking @code{set-octavation}, i.e.,
Bar lines delimit measures, but are also used to indicate repeats.
Normally, they are inserted automatically. Line breaks may only
-happen on barlines.
+happen on bar lines.
@syntax
Special types
-of barlines can be forced with the @code{\bar} command:
+of bar lines can be forced with the @code{\bar} command:
@c
@lilypond[relative=1,fragment,verbatim]
c4 \bar "|:" c4
@end lilypond
The following bar types are available:
+
@lilypond[fragment,relative,raggedright,verbatim]
c4
\bar "|" c
\bar "|." c
\bar ":" c
@end lilypond
-For allowing linebreaks, there is a special command,
+
+For allowing line breaks, there is a special command,
@example
\bar "empty"
@end example
-This will insert an invisible barline, and allow linebreaks at this
+This will insert an invisible bar line, and allow linebreaks at this
point.
In scores with many staves, a @code{\bar} command in one staff is
@cindex bar lines at start of system
@cindex start of system
-The barlines at the start of each system are
+The bar lines at the start of each system are
@internalsref{SystemStartBar}, @internalsref{SystemStartBrace}, and
@internalsref{SystemStartBracket}. Only one of these types is created
in every context, and that type is determined by the property
beams and sixteenth beams, a beam that contains both eight and
sixteenth notes will use the rules for the sixteenth beam.
-In the example below, the autobeamer makes eight beams and sixteenth
+In the example below, the auto beamer makes eight beams and sixteenth
end at 3 eights; the third beam can only be corrected by specifying
manual beaming.
The following styles are supported:
@table @code
@item default
- This is the default typesetting behaviour. It should correspond
+ This is the default typesetting behavior. It should correspond
to 18th century common practice: Accidentals are
remembered to the end of the measure in which they occur and
only on their own octave.
@item voice
@c
- The normal behaviour is to remember the accidentals on
+ The normal behavior is to remember the accidentals on
Staff-level. This variable, however, typesets accidentals
individually for each voice. Apart from that, the rule is similar to
@code{code}.
This leads to some weird and often unwanted results
- because accidentals from one voice do not get cancelled in other
+ because accidentals from one voice do not get canceled in other
voices:
@lilypond[raggedright,relative,fragment,verbatim,quote]
\context Staff <<
This rule corresponds to the common practice in the 20th
century.
This rule prints the same accidentals as @code{default}, but temporary
- accidentals also are cancelled in other octaves. Furthermore,
- in the same octave, they also get cancelled in the following
+ accidentals also are canceled in other octaves. Furthermore,
+ in the same octave, they also get canceled in the following
measure:
@lilypond[raggedright,fragment,verbatim]
On Windows, the same procedure should work. The terminal is started by
clicking on the LilyPond or Cygwin icon. Any text editor (such as
-NotePad, Emacs or Vim) may be used to edit the LilyPond file.
+Notepad, Emacs or Vim) may be used to edit the LilyPond file.
To view the PDF file, try the following:
@itemize
When the music is converted from notes to print it is interpreted
in left-to-right order. This is similar to what happens when we read
music. During this step context-sensitive information such as the
-accidentals to print, and where barlines must be placed, are stored in
+accidentals to print, and where bar lines must be placed, are stored in
variables. These variables are called @emph{context properties}.
The properties can also be manipulated from input files. Consider this input:
@example
@end example
More information on the possible uses of identifiers is in the
-technical manual, in @ref{Scheme datatypes}.
+technical manual, in @ref{Scheme data types}.
@node An orchestral part
output_def_ = o;
definition_ = o->find_context_def (ly_symbol2scm ("Global"));
unsmob_context_def (definition_)->apply_default_property_operations (this);
-
}
Music_output_def*
%if %{info}
-if [ $1 = 0 ]; then
/sbin/install-info --delete %{_infodir}/lilypond.info.gz %{_infodir}/dir
/sbin/install-info --delete %{_infodir}/music-glossary.info.gz %{_infodir}/dir
-fi
%endif
# chkfontpath --remove=%{_datadir}/share/lilypond/@TOPLEVEL_VERSION@/fonts/type1/
ENCODING_FILE=$(findstring $(<:.mf=.enc), $(FETA_MF_FILES:.mf=.enc))
MFTRACE_FLAGS=$(if $(ENCODING_FILE),--encoding $(ENCODING_FILE),)
-SAUTER_FONTS = cmbx14 cmbx17 \
+
+# only for fonts which
+#
+# 1. are mentioned in font.scm
+#
+# 2. are not included with teTeX
+#
+SAUTER_FONTS = cmbxti8
+
+MORE_SAUTER_FONTS = cmbx14 cmbx17 \
cmbxti12 cmbxti14 \
cmbxti6 cmbxti7 cmbxti8 \
cmcsc12 cmcsc7 cmcsc8 \
projects / lilypond.git / commitdiff