version that you are working on. See TRANSLATION for details.
@end ignore
-@c \version "2.11.55"
+@c \version "2.11.61"
@node Changing defaults
@chapter Changing defaults
-@strong{N.B. This Chapter is still being developed at present.}
-
The purpose of LilyPond's design is to provide the finest quality
output by default. Nevertheless, it may happen that you need to
change this default layout. The layout is controlled through a large
@uref{http://@/lilypond@/.org/@/doc/@/stable/@/Documentation/@/user/@/lilypond@/-internals/,on@/-line},
and is also included with the LilyPond documentation package.
-@c TODO The following is at variance to what actually follows. Fix -td
-
-@ignore
-There are four areas where the default settings may be changed:
-
-@itemize
-@item
-Automatic notation: changing the automatic creation of notation
-elements. For example, changing the beaming rules.
-
-@item
-Output: changing the appearance of individual
-objects. For example, changing stem directions or the location of
-subscripts.
-
-@item
-Context: changing aspects of the translation from music events to
-notation. For example, giving each staff a separate time signature.
-
-@item
-Page layout: changing the appearance of the spacing, line
-breaks, and page dimensions. These modifications are discussed
-@c in @ref{notation}, and @ref{Spacing issues}.
-@end itemize
-
Internally, LilyPond uses Scheme (a LISP dialect) to provide
infrastructure. Overriding layout decisions in effect accesses the
program internals, which requires Scheme input. Scheme elements are
@code{#}.@footnote{@rlearning{Scheme tutorial}, contains a short tutorial
on entering numbers, lists, strings, and symbols in Scheme.}
-@end ignore
-
@menu
* Interpretation contexts::
* Modifying properties::
* Useful concepts and properties::
* Advanced tweaks::
-* Discussion of specific tweaks::
@end menu
This section describes what contexts are, and how to modify them.
@menu
-* Contexts explained::
-* Creating contexts::
-* Modifying context plug-ins::
-* Changing context default settings::
-* Defining new contexts::
-* Aligning contexts::
+* Contexts explained::
+* Creating contexts::
+* Modifying context plug-ins::
+* Changing context default settings::
+* Defining new contexts::
+* Aligning contexts::
@end menu
+@seealso
+
+Learning Manual:
+@rlearning{Contexts and engravers}.
+
+Installed files:
+@file{ly/@/engraver@/-init@/.ly},
+@file{ly/@/performer@/-init@/.ly}.
+
+Snippets:
+@rlsr{Contexts and engravers}.
+
+Internals Reference:
+@rinternals{Contexts},
+@rinternals{Engravers and Performers}.
+
@node Contexts explained
@subsection Contexts explained
@strong{@emph{PianoStaff}}
-TODO No longer correct? Check. -td
-
+@c TODO No longer correct? Check. -td
Just like GrandStaff but with a forced distance between the
staves, so cross staff beaming and slurring can be used.
+@ignore
@strong{@emph{InnerStaffGroup}}
TODO -td
TODO -td
+@end ignore
+
@node Intermediate-level contexts - staves
@unnumberedsubsubsec Intermediate-level contexts - staves
Typesets chord names.
-------------------------------
-
+@ignore
TODO
Then the following, which I don't know what to do with:
Silently discards all musical information given to this
context.
+@end ignore
@node Creating contexts
@subsection Creating contexts
>>
@end lilypond
+@knownissues
+
+Usually the order in which the engravers are specified
+does not matter, but in a few special cases the order
+is important, for example where one engraver writes
+a property and another reads it, or where one engraver
+creates a grob and another must process it. The order in
+which the engravers are specified is the order in which
+they are called to carry out their processing.
+
+The following orderings are important: the
+@code{Bar_engraver} must normally be first, and
+the @code{New_fingering_engraver} must come before
+the @code{Script_column_engraver}. There may be others
+with ordering dependencies.
@node Changing context default settings
@subsection Changing context default settings
@}
@end example
-TODO: add \with in here.
+@c TODO: add \with in here.
@c TODO Better example needed. Ref LM, and expand on it.
@cindex ossia
-@findex alignAboveContext
-@findex alignBelowContext
+@funindex alignAboveContext
+@funindex alignBelowContext
@lilypond[quote,ragged-right]
ossia = { f4 f f f }
}
@end lilypond
+@cindex nested contexts
+@cindex contexts, nested
+
+@funindex \accepts
+@funindex \denies
+
+Contexts like @code{PianoStaff} can contain other contexts
+nested within them. Contexts which are acceptable for nesting
+are defined by the @qq{accepts} list of a context. Contexts
+which are not in this list are placed below the outer context
+in the printed score.
+For example, the @code{PianoStaff} context is defined by default
+to accept @code{Staff} and @code{FiguredBass} contexts within
+it, but not (for example) a @code{Lyrics} context. So in the
+following structure the lyrics are placed below the piano staff
+rather than between the two staves:
+
+@lilypond[verbatim,quote,relative=1]
+\new PianoStaff
+<<
+ \new Staff { e4 d c2 }
+ \addlyrics { Three blind mice }
+ \new Staff {
+ \clef "bass"
+ { c,1 }
+ }
+>>
+@end lilypond
+
+The @qq{accepts} list of a context can be modified to include
+additional nested contexts, so if we wanted the lyrics to appear
+between the two staves we could use:
+
+@lilypond[verbatim,quote,relative=1]
+\new PianoStaff \with { \accepts Lyrics }
+<<
+ \new Staff { e4 d c2 }
+ \addlyrics { Three blind mice }
+ \new Staff {
+ \clef "bass"
+ { c,1 }
+ }
+>>
+@end lilypond
+
+The opposite of @code{\accepts} is @code{\denies}; this removes a
+context from the @qq{accepts} list.
@node Explaining the Internals Reference
@section Explaining the Internals Reference
@menu
-* Navigating the program reference::
-* Layout interfaces::
-* Determining the grob property::
-* Naming conventions::
+* Navigating the program reference::
+* Layout interfaces::
+* Determining the grob property::
+* Naming conventions::
@end menu
@node Navigating the program reference
* Input modes::
* Direction and placement::
* Distances and measurements::
+* Staff symbol properties::
* Spanners::
* Visibility of objects::
* Line styles::
@c TODO Add table showing these
-@strong{Context layout}
-
-Contexts are positioned in a system from top to bottom in the
-order in which they are encountered. Note, however, that a
-context will be created implicitly if a command is encountered
-when there is no suitable context available to contain it.
+@strong{Context layout order}
-@c TODO Add example ?
+Contexts are normally positioned in a system from top to bottom
+in the order in which they are encountered. Note, however, that
+a context will be created implicitly if a command is encountered
+when there is no suitable context available to contain it. When
+contexts are nested, the outer context will exclude inner contexts
+which are not included in its @qq{accepts} list; excluded contexts
+will be repositioned below the outer context.
-The default order in which contexts are laid out can be changed,
-see @ref{Aligning contexts}
+The default order in which contexts are laid out and the
+@qq{accepts} list can be changed, see @ref{Aligning contexts}.
@strong{Articulation direction indicators}
@node Distances and measurements
@subsection Distances and measurements
-To be written
+@cindex distances, absolute
+@cindex distances, scaled
+
+@funindex \mm
+@funindex \cm
+@funindex \in
+@funindex \pt
+
+Distances in LilyPond are of two types: absolute and scaled.
+
+Absolute distances are used for specifying margins, indents, and
+other page layout details, and are by default specified in
+millimeters. Distances may be specified in other units by
+following the quantity by @code{\mm}, @code{\cm},
+@code{\in}@tie{}(inches), or @code{\pt}@tie{}(points, 1/72.27
+of an inch). Page layout distances can also be specified in
+scalable units (see the following paragraph) by appending
+@code{\staff-space} to the quantity.
+Page layout is described in detail in @ref{Page formatting}.
+
+Scaled distances are always specified in units of the staff-space
+or, rarely, the half staff-space. The staff-space is the distance
+between two adjacent staff lines. The default value can be changed
+globally by setting the global staff size, or it can be overridden
+locally by changing the @code{staff-space} property of
+@code{StaffSymbol}. Scaled distances automatically scale with any
+change to the either the global staff size or the
+@code{staff-space} property of @code{StaffSymbol}, but fonts scale
+automatically only with changes to the global staff size.
+The global staff size thus enables the overall size of a rendered
+score to be easily varied. For the methods of setting the global
+staff size see @ref{Setting the staff size}.
+
+@funindex magstep
+
+If just a section of a score needs to be rendered to a different
+scale, for example an ossia section or a footnote, the global staff
+size cannot simply be changed as this would affect the entire score.
+In such cases the change in size is made by overriding both the
+@code{staff-space} property of @code{StaffSymbol} and the size of
+the fonts. A Scheme function, @code{magstep}, is available to
+convert from a font size change to the equivalent change in
+@code{staff-space}. For an explanation and an example of its use,
+see @rlearning{Length and thickness of objects}.
+
+@seealso
+
+Learning Manual:
+@rlearning{Length and thickness of objects}.
+
+Notation Reference:
+@ref{Page formatting},
+@ref{Setting the staff size}.
-@c FIXME DISCUSS after working on other sections.
-@c TODO: staff spaces. Maybe move into tweaks?
+@node Staff symbol properties
+@subsection Staff symbol properties
+
+@cindex adjusting staff symbol
+@cindex drawing staff symbol
+@cindex staff symbol, setting of
+
+@c TODO Extend or remove this section. See also NR 1.6.2 Staff symbol
+@c Need to think of uses for these properties. Eg 'line-positions
+@c is used in a snippet to thicken centre line.
+@c If retained, add @ref to here in 1.6.2 -td
+
+The vertical position of staff lines and the number of staff lines
+can be defined at the same time. As the following example shows,
+note positions are not influenced by the staff line positions.
+
+@warning{The @code{'line-positions} property overrides the
+@code{'line-count} property. The number of staff lines is
+implicitly defined by the number of elements in the list of values
+for @code{'line-positions}.}
+
+@lilypond[verbatim,quote,relative=1]
+\new Staff \with {
+ \override StaffSymbol #'line-positions = #'(7 3 0 -4 -6 -7)
+}
+{ a4 e' f b | d1 }
+@end lilypond
+
+The width of a staff can be modified. The units are staff
+spaces. The spacing of objects inside the staff is not affected by
+this setting.
+
+@lilypond[verbatim,quote,relative=1]
+\new Staff \with {
+ \override StaffSymbol #'width = #23
+}
+{ a4 e' f b | d1 }
+@end lilypond
@node Spanners
@node Advanced tweaks
@section Advanced tweaks
+This section discusses various approaches to fine tuning the
+appearance of the printed score.
+
@menu
* Aligning objects::
* Vertical grouping of grobs::
* Modifying shapes::
@end menu
+@seealso
+
+Learning Manual:
+@rlearning{Tweaking output},
+@rlearning{Other sources of information}.
+
+Notation Reference:
+@ref{Explaining the Internals Reference},
+@ref{Modifying properties},
+@ref{Interfaces for programmers}.
+
+Installed Files:
+@file{scm/@/define@/-grobs@/.scm}.
+
+Snippets:
+@rlsr{Tweaks and overrides}.
+
+Internals Reference:
+@rinternals{All layout objects}.
+
@node Aligning objects
@subsection Aligning objects
-@node Discussion of specific tweaks
-@section Discussion of specific tweaks
-
-@c TODO What should go in here?
-
projects / lilypond.git / blobdiff