4 @c A menu is needed before every deeper *section nesting of @nodes
5 @c Run M-x texinfo-all-menus-update
6 @c to automagically fill in these menus
7 @c before saving changes
11 @chapter Advanced Topics
14 When translating the input to notation, there are number of distinct
15 phases. We list them here:
17 @c todo: moved from refman.
19 The purpose of LilyPond is explained informally by the term `music
20 typesetter'. This is not a fully correct name: not only does the
21 program print musical symbols, it also makes aesthetic decisions.
22 Symbols and their placements are @emph{generated} from a high-level
23 musical description. In other words, LilyPond would be best described
24 by `music compiler' or `music to notation compiler'.
26 LilyPond is linked to GUILE, GNU's Scheme library for extension
27 programming. The Scheme library provides the glue that holds together
28 the low-level routines and separate modules which are written in C++.
30 When lilypond is run to typeset sheet music, the following happens:
32 @item GUILE Initialization: various scheme files are read
33 @item parsing: first standard @code{ly} initialization files are read, and
34 then the user @file{ly} file is read.
35 @item interpretation: the music in the file is processed ``in playing
36 order'', i.e. the order that you use to read sheet music, or the
37 order in which notes are played. The result of this step is a typesetting
41 The typesetting specification is solved: positions and formatting is
44 @item the visible results ("virtual ink") are written to the output file.
47 During these stages different types of data play the the main role:
48 during parsing, @strong{Music} objects are created. During the
49 interpretation, @strong{contexts} are constructed, and with these
50 contexts a network of @strong{graphical objects} (``grobs'') is
51 created. These grobs contain unknown variables, and the network forms a
52 set of equations. After solving the equations and filling in these
53 variables, the printed output is written to an output file.
55 These threemanship of tasks (parsing, translating, typesetting) and
56 data-structures (music, context, graphical objects) permeates the entire
57 design of the program.
65 The LY file is read, and converted to a list of @code{Scores}, which
66 each contain @code{Music} and paper/midi-definitions. Here @code{Music},
67 @code{Pitch} and @code{Duration} objects are created.
69 @item Interpreting music
70 @cindex interpreting music
72 All music events are "read" in the same order as they would be played
73 (or read from paper). At every step of the interpretation, musical
74 events are delivered to
75 interpretation contexts,
77 which use them to build @code{Grob}s (or MIDI objects, for MIDI output).
79 In this stage @code{Music_iterators} do a traversal of the @code{Music}
80 structure. The music events thus encountered are reported to
81 @code{Translator}s, a set of objects that collectively form interpretation
89 At places where line breaks may occur, clefs and bars are prepared for
90 a possible line break.
96 In this stage, all information that is needed to determine line breaking
99 @item Break calculation:
101 The lines and horizontal positions of the columns are determined.
105 Relations between all grobs are modified to reflect line breaks: When a
106 spanner, e.g. a slur, crosses a line-break, then the spanner is "broken
107 into pieces", for every line that the spanner is in, a copy of the grob
108 is made. A substitution process redirects all grob-reference so that
109 each spanner grob will only reference other grobs in the same line.
113 All vertical dimensions and spanning objects are computed, and all grobs
114 are output, line by line. The output is encoded in the form of
119 The data types that are mentioned here are all discussed in this
124 @c FIXME: Note entry vs Music entry at top level menu is confusing.
127 * Interpretation context::
128 * Syntactic details::
132 @c . {Output formats}
134 @section Output formats
136 LilyPond can output processed music in different output formats.
140 * PostScript output::
142 * ASCIIScript output::
147 @subsection @TeX{} output
148 @cindex @TeX{} output
150 LilyPond will use @TeX{} by default. Even if you want to produce
151 PostScript output for viewing or printing, you should normally have
152 LilyPond produce @TeX{} first. The .tex output must be processed by
153 @TeX{} (@strong{not} La@TeX{}) to generate a .dvi. Then, @file{Dvips}
154 is used to generate PostScript. Alternatively, @file{ly2dvi} can be
155 used to generate the .dvi for you.
159 Titling is not generated unless you use @file{ly2dvi}.
162 @node PostScript output
163 @subsection PostScript output
164 @cindex PostScript output
165 @cindex direct PostScript output
167 LilyPond can produce PostScript directly, without going through @TeX{}.
168 Currently, this is mainly useful if you cannot use TeX, because direct
169 PostScript output has some problems; see Bugs below.
172 $ lilypond -fps foo.ly
174 Now processing: `foo.ly'
176 Interpreting music...[3]
177 Preprocessing elements...
178 Calculating column positions...
179 paper output to foo.ps...
181 $ cat /usr/share/lilypond/pfa/feta20.pfa foo.ps | lpr
187 Text font selection is broken.
189 The .ps file does not contain the .pfa font files. To print a .ps
190 created through direct postscript output, you should prepend the
191 necessary .pfa files to LilyPond's .ps output, or upload them to the
192 printer before printing.
194 The line height calculation is broken, you must set @var{lineheight} in
195 the paperblock if you have more than one staff in your score, e.g.
200 % Set line height to 40 staff spaces
206 @subsection Scheme output
207 @cindex Scheme output
209 In the typesetting stage, LilyPond builds a page description, which is
210 then written to disk in postscript, @TeX{} or ASCII art. Before it is
211 written, the page description is represented as Scheme expressions. You
212 can also dump these Scheme expressions to a file, which may be
213 convenient for debugging output routines. This is done with the Scheme
217 $ lilypond -fscm foo.ly
219 Now processing: `foo.ly'
221 Interpreting music...[3]
222 Preprocessing elements...
223 Calculating column positions...
224 paper output to foo.scm...
227 ;;; Usage: guile -s x.scm > x.tex
228 (primitive-load-path 'standalone.scm)
232 $ guile -s foo.scm > foo.tex
236 @node ASCIIScript output
237 @subsection ASCIIScript output
238 @cindex ASCIIScript output
242 LilyPond can output ASCII Art. This is a two step process, LilyPond
243 produces an ASCII description file, dubbed ASCIIScript (extension
244 @file{.as}). ASCIIScript has a small and simple command set that
245 includes font selection, character and string printing and line drawing
246 commands. The program @file{as2text} is used to translate an .as file
249 To produce ASCII Art, you must include an ASCII Art paper definition
250 file in your .ly, one of:
252 \include "paper-as5.ly"
253 \include "paper-as9.ly"
256 Here's an example use for ASCII Art output (the example file
257 @file{as-email.ly} is included in the LilyPond distribution), the staff
258 symbol has been made invisible:
261 $ lilypond -fas as-email.ly
263 Now processing: `as-email.ly'
265 Interpreting music...[3]
266 Preprocessing elements...
267 Calculating column positions... [2]
268 paper output to as-email.as...
270 $ as2text as-email.as 2>/dev/null
273 /| | | | | |\ |\ |\ |\ |\ |
274 / |_ 3 | | | | 5 | )| )| )| )| )|
275 | /| \ 8 * * * | 8 * * * * * |
285 The ASCII Art fonts are far from complete and not very well designed.
286 It's easy to change the glyphs, though; if you think you can do better,
287 have a look at @file{mf/*.af}.
289 Lots of resizable symbols such as slurs, ties and tuplets are missing.
291 The poor looks of most ASCII Art output and its limited general
292 usefulness gives ASCII Art output a low priority; it may be
293 dropped in future versions.
297 @subsection Sketch output
299 @uref{http://sketch.sourceforge.net,Sketch} is a Free vector drawing
300 program. LilyPond includes bare bones output for Sketch version 0.7.
303 @cindex vector drawing
304 @cindex drawing program
307 @node Interpretation context
308 @section Interpretation context
311 * Creating contexts::
313 * Context properties::
314 * Engravers and performers::
315 * Changing context definitions::
316 * Defining new contexts::
320 Interpretation contexts are objects that only exist during a run of
321 LilyPond. During the interpretation phase of LilyPond (when it prints
322 "interpreting music"), the music expression in a @code{\score} block is
323 interpreted in time order. This is the same order that humans hear and
326 During this interpretation, the interpretation context holds the
327 state for the current point within the music. It contains information
331 @item What notes are playing at this point?
332 @item What symbols will be printed at this point?
333 @item What is the current key signature, time signature, point within
337 Contexts are grouped hierarchically: A @internalsref{Voice} context is
338 contained in a @internalsref{Staff} context (because a staff can contain
339 multiple voices at any point), a @internalsref{Staff} context is contained in
340 @internalsref{Score}, @internalsref{StaffGroup}, or @internalsref{ChoirStaff} context.
342 Contexts associated with sheet music output are called @emph{notation
343 contexts}, those for sound output are called @emph{performance
344 contexts}. The default definitions of the standard notation and
345 performance contexts can be found in @file{ly/engraver-init.ly} and
346 @file{ly/performer-init.ly}, respectively.
348 @node Creating contexts
349 @subsection Creating contexts
351 @cindex @code{\context}
352 @cindex context selection
354 Contexts for a music expression can be selected manually, using the
355 following music expression.
358 \context @var{contexttype} [= @var{contextname}] @var{musicexpr}
361 This instructs lilypond to interpret @var{musicexpr} within the context
362 of type @var{contexttype} and with name @var{contextname}. If this
363 context does not exist, it will be created.
365 @lilypond[verbatim,singleline]
367 \notes \relative c'' {
368 c4 <d4 \context Staff = "another" e4> f
374 In this example, the @code{c} and @code{d} are printed on the
375 default staff. For the @code{e}, a context Staff called
376 @code{another} is specified; since that does not exist, a new
377 context is created. Within @code{another}, a (default) Voice context
378 is created for the @code{e4}. When all music referring to a
379 context is finished, the context is ended as well. So after the
380 third quarter, @code{another} is removed.
384 @node Default contexts
385 @subsection Default contexts
387 Most music expressions don't need an explicit @code{\context}
388 declaration: they inherit the
389 notation context from their parent. Each note is a music expression, and
390 as you can see in the following example, only the sequential music
391 enclosing the three notes has an explicit context.
393 @lilypond[verbatim,singleline]
394 \score { \notes \context Voice = goUp { c'4 d' e' } }
397 There are some quirks that you must keep in mind when dealing with
400 First, every top level music is interpreted by the Score context, in other
401 words, you may think of @code{\score} working like
404 \context Score @var{music}
408 Second, contexts are created automatically to be able to interpret the
409 music expressions. Consider the following example.
411 @lilypond[verbatim, singleline]
412 \score { \context Score \notes { c'4 ( d' )e' } }
415 The sequential music is interpreted by the Score context initially
416 (notice that the @code{\context} specification is redundant), but when a
417 note is encountered, contexts are setup to accept that note. In this
418 case, a Thread, Voice and Staff are created. The rest of the sequential
419 music is also interpreted with the same Thread, Voice and Staff context,
420 putting the notes on the same staff, in the same voice.
422 This is a convenient mechanism, but do not expect opening chords to work
423 without @code{\context}. For every note, a separate staff is
426 @cindex explicit context
427 @cindex starting with chords
428 @cindex chords, starting with
430 @lilypond[verbatim, singleline]
431 \score { \notes <c'4 es'> }
434 Of course, if the chord is preceded by a normal note in sequential
435 music, the chord will be interpreted by the Thread of the preceding
437 @lilypond[verbatim,singleline]
438 \score { \notes { c'4 <c'4 es'> } }
443 @node Context properties
444 @subsection Context properties
446 Notation contexts have properties. These properties are from
447 the @file{.ly} file using the following expression:
448 @cindex @code{\property}
450 \property @var{contextname}.@var{propname} = @var{value}
453 Sets the @var{propname} property of the context @var{contextname} to the
454 specified Scheme expression @var{value}. All @var{propname} and
455 @var{contextname} are strings, which are typically unquoted.
457 Properties that are set in one context are inherited by all of the
458 contained contexts. This means that a property valid for the
459 @internalsref{Voice} context can be set in the @internalsref{Score} context (for
460 example) and thus take effect in all @internalsref{Voice} contexts.
462 Properties can be unset using the following expression:
464 \property @var{contextname}.@var{propname} \unset
467 @cindex properties, unsetting
468 @cindex @code{\unset}
470 This removes the definition of @var{propname} in @var{contextname}. If
471 @var{propname} was not defined in @var{contextname} (but was inherited
472 from a higher context), then this has no effect.
477 The syntax of @code{\unset} is asymmetric: @code{\property \unset} is not
478 the inverse of @code{\property \set}.
480 @node Engravers and performers
481 @subsection Engravers and performers
485 Basic building blocks of translation are called engravers; they are
490 @node Changing context definitions
491 @subsection Changing context definitions
493 @cindex context definition
494 @cindex translator definition
496 The most common way to define a context is by extending an existing
497 context. You can change an existing context from the paper block, by
498 first initializing a translator with an existing context identifier:
502 @var{context-identifier}
505 Then you can add and remove engravers using the following syntax:
507 \remove @var{engravername}
508 \consists @var{engravername}
512 Here @var{engravername} is a string, the name of an engraver in the
516 @lilypond[verbatim,singleline]
520 \translator { \StaffContext
521 \remove Clef_engraver
527 You can also set properties in a translator definition. The syntax is as
530 @var{propname} = @var{value}
531 @var{propname} \set @var{grob-propname} = @var{pvalue}
532 @var{propname} \override @var{grob-propname} = @var{pvalue}
533 @var{propname} \revert @var{grob-propname}
535 @var{propname} is a string, @var{grob-propname} a symbol, @var{value}
536 and @code{pvalue} are Scheme expressions. These type of property
537 assignments happen before interpretation starts, so a @code{\property}
538 command will override any predefined settings.
541 To simplify editing translators, all standard contexts have standard
542 identifiers called @var{name}@code{Context}, e.g. @code{StaffContext},
543 @code{VoiceContext}, see @file{ly/engraver-init.ly}.
545 @node Defining new contexts
546 @subsection Defining new contexts
548 If you want to build a context from scratch, you must also supply the
549 following extra information:
551 @item A name, specified by @code{\name @var{contextname}}.
553 @item A cooperation module. This is specified by @code{\type
560 \type "Engraver_group_engraver"
563 \consists "Staff_symbol_engraver"
564 \consists "Note_head_engraver"
565 \consistsend "Axis_group_engraver"
569 The argument of @code{\type} is the name for a special engraver that
570 handles cooperation between simple engravers such as
571 @code{Note_head_engraver} and @code{Staff_symbol_engraver}. Alternatives
572 for this engraver are the following:
574 @cindex @code{Engraver_group_engraver}
575 @item @code{Engraver_group_engraver}
576 The standard cooperation engraver.
578 @cindex @code{Score_engraver}
580 @item @code{Score_engraver}
581 This is cooperation module that should be in the top level context,
582 and only the top level context.
589 @item @code{\alias} @var{alternate-name}
590 This specifies a different name. In the above example,
591 @code{\property Staff.X = Y} will also work on @code{SimpleStaff}s
593 @item @code{\consistsend} @var{engravername}
594 Analogous to @code{\consists}, but makes sure that
595 @var{engravername} is always added to the end of the list of
598 Some engraver types need to be at the end of the list; this
599 insures they stay there even if a user adds or removes engravers.
600 End-users generally don't need this command.
602 @item @code{\accepts} @var{contextname}
603 Add @var{contextname} to the list of contexts this context can
604 contain in the context hierarchy. The first listed context is the
605 context to create by default.
607 @item @code{\denies}. The opposite of @code{\accepts}. Added for
608 completeness, but is never used in practice.
611 @item @code{\name} @var{contextname}
612 This sets the type name of the context, e.g. @internalsref{Staff},
613 @internalsref{Voice}. If the name is not specified, the translator won't do
617 In the @code{\paper} block, it is also possible to define translator
618 identifiers. Like other block identifiers, the identifier can only
619 be used as the very first item of a translator. In order to define
620 such an identifier outside of @code{\score}, you must do
625 foo = \translator @{ @dots{} @}
632 \translator @{ \foo @dots{} @}
640 @cindex paper types, engravers, and pre-defined translators
643 @node Syntactic details
644 @section Syntactic details
645 @cindex Syntactic details
647 This section describes details that were too boring to be put elsewhere.
651 * Music expressions::
652 * Manipulating music expressions::
661 @subsection Identifiers
665 What has this section got to do with identifiers?
666 It seems more appropriate in the introduction to Chapter 4,
672 All of the information in a LilyPond input file, is internally
673 represented as a Scheme value. In addition to normal Scheme data types
674 (such as pair, number, boolean, etc.), LilyPond has a number of
675 specialized data types,
686 @item Music_output_def
687 @item Moment (rational number)
690 LilyPond also includes some transient object types. Objects of these
691 types are built during a LilyPond run, and do not `exist' per se within
692 your input file. These objects are created as a result of your input
693 file, so you can include commands in the input to manipulate them,
694 during a lilypond run.
697 @item Grob: short for Graphical object.
698 @item Molecule: device-independent page output object,
699 including dimensions. Produced by some Grob functions
700 @item Translator: object that produces audio objects or Grobs. This is
701 not yet user accessible.
702 @item Font_metric: object representing a font.
706 @node Music expressions
707 @subsection Music expressions
709 @cindex music expressions
711 Music in LilyPond is entered as a music expression. Notes, rests, lyric
712 syllables are music expressions, and you can combine music expressions
713 to form new ones, for example by enclosing a list of expressions in
714 @code{\sequential @{ @}} or @code{< >}. In the following example, a
715 compound expression is formed out of the quarter note @code{c} and a
716 quarter note @code{d}:
719 \sequential @{ c4 d4 @}
722 @cindex Sequential music
723 @cindex @code{\sequential}
724 @cindex sequential music
727 @cindex Simultaneous music
728 @cindex @code{\simultaneous}
730 The two basic compound music expressions are simultaneous and
734 \sequential @code{@{} @var{musicexprlist} @code{@}}
735 \simultaneous @code{@{} @var{musicexprlist} @code{@}}
737 For both, there is a shorthand:
739 @code{@{} @var{musicexprlist} @code{@}}
743 @code{<} @var{musicexprlist} @code{>}
745 for simultaneous music.
746 In principle, the way in which you nest sequential and simultaneous to
747 produce music is not relevant. In the following example, three chords
748 are expressed in two different ways:
750 @lilypond[fragment,verbatim,center]
751 \notes \context Voice {
752 <a c'> <b d' > <c' e'>
753 < { a b c' } { c' d' e' } >
758 Other compound music expressions include
761 \transpose @var{pitch} @var{expr}
762 \apply @var{func} @var{expr}
763 \context @var{type} = @var{id} @var{expr}
764 \times @var{fraction} @var{expr}
768 @c . {Manipulating music expressions}
769 @node Manipulating music expressions
770 @subsection Manipulating music expressions
772 The @code{\apply} mechanism gives you access to the internal
773 representation of music. You can write Scheme-functions that operate
774 directly on it. The syntax is
776 \apply #@var{func} @var{music}
778 This means that @var{func} is applied to @var{music}. The function
779 @var{func} should return a music expression.
781 This example replaces the text string of a script. It also shows a dump
782 of the music it processes, which is useful if you want to know more
783 about how music is stored.
785 @lilypond[verbatim,singleline]
786 #(define (testfunc x)
787 (if (equal? (ly-get-mus-property x 'text) "foo")
788 (ly-set-mus-property! x 'text "bar"))
790 (ly-set-mus-property! x 'elements
791 (map testfunc (ly-get-mus-property x 'elements)))
796 \apply #testfunc { c'4_"foo" }
800 For more information on what is possible, see the automatically
801 generated documentation.
804 Directly accessing internal representations is dangerous: the
805 implementation is subject to changes, so you should avoid this feature
808 A final example is a function that reverses a piece of music in time:
810 @lilypond[verbatim,singleline]
811 #(define (reverse-music music)
812 (let* ((elements (ly-get-mus-property music 'elements))
813 (reversed (reverse elements))
814 (span-dir (ly-get-mus-property music 'span-direction)))
815 (ly-set-mus-property! music 'elements reversed)
817 (ly-set-mus-property! music 'span-direction (- span-dir)))
818 (map reverse-music reversed)
821 music = \notes { c'4 d'4( e'4 f'4 }
823 \score { \context Voice {
825 \apply #reverse-music \music
830 More examples are given in the distributed example files in
839 @subsection Span requests
840 @cindex Span requests
842 Notational constructs that start and end on different notes can be
843 entered using span requests. The syntax is as follows:
847 \spanrequest @var{startstop} @var{type}
851 @cindex @code{\start}
854 This defines a spanning request. The @var{startstop} parameter is either
855 -1 (@code{\start}) or 1 (@code{\stop}) and @var{type} is a string that
856 describes what should be started. Much of the syntactic sugar is a
857 shorthand for @code{\spanrequest}, for example,
859 @lilypond[fragment,verbatim,center]
860 c'4-\spanrequest \start "slur"
861 c'4-\spanrequest \stop "slur"
864 Among the supported types are @code{crescendo}, @code{decrescendo},
865 @code{beam}, @code{slur}. This is an internal command. Users are
866 encouraged to use the shorthands which are defined in the initialization
867 file @file{spanners.ly}.
872 @subsection Assignments
875 Identifiers allow objects to be assigned to names during the parse
876 stage. To assign an identifier, you use @var{name}@code{=}@var{value}
877 and to refer to an identifier, you precede its name with a backslash:
878 `@code{\}@var{name}'. @var{value} is any valid Scheme value or any of
879 the input-types listed above. Identifier assignments can appear at top
880 level in the LilyPond file, but also in @code{\paper} blocks.
882 An identifier can be created with any string for its name, but you will
883 only be able to refer to identifiers whose names begin with a letter,
884 being entirely alphabetical. It is impossible to refer to an identifier
885 whose name is the same as the name of a keyword.
887 The right hand side of an identifier assignment is parsed completely
888 before the assignment is done, so it is allowed to redefine an
889 identifier in terms of its old value, e.g.
895 When an identifier is referenced, the information it points to is
896 copied. For this reason, an identifier reference must always be the
897 first item in a block.
901 \paperIdent % wrong and invalid
905 \paperIdent % correct
912 @subsection Lexical modes
913 @cindex Lexical modes
916 @cindex @code{\notes}
917 @cindex @code{\chords}
918 @cindex @code{\lyrics}
920 To simplify entering notes, lyrics, and chords, LilyPond has three
921 special input modes in addition to the default mode: note, lyrics and
922 chords mode. These input modes change the way that normal, unquoted
923 words are interpreted: for example, the word @code{cis} may be
924 interpreted as a C-sharp, as a lyric syllable `cis' or as a C-sharp
925 major triad respectively.
927 A mode switch is entered as a compound music expression
929 @code{\notes} @var{musicexpr}
930 @code{\chords} @var{musicexpr}
931 @code{\lyrics} @var{musicexpr}.
934 In each of these cases, these expressions do not add anything to the
935 meaning of their arguments. They just instruct the parser in what mode
936 to parse their arguments.
938 Different input modes may be nested.
942 @subsection Ambiguities
947 The grammar contains a number of ambiguities. We hope to resolve them at
956 is interpreted as the string identifier assignment. However,
957 it can also be interpreted as making a string identifier @code{\foo}
958 containing @code{"bar"}, or a music identifier @code{\foo} containing
959 the syllable `bar'. The former interpretation is chosen.
961 @item If you do a nested repeat like
973 then it is ambiguous to which @code{\repeat} the
974 @code{\alternative} belongs. This is the classic if-then-else
975 dilemma. It may be solved by using braces.
979 @c . {Lexical details}
980 @node Lexical details
981 @section Lexical details
983 Even more boring details, now on lexical side of the input parser.
993 @subsection Direct Scheme
997 @cindex Scheme, in-line code
1003 @cindex accessing Scheme
1004 @cindex evaluating Scheme
1007 LilyPond internally uses GUILE, a Scheme-interpreter. Scheme is a
1008 language from the LISP family. You can learn more about Scheme at
1009 @uref{http://www.scheme.org}. It is used to represent data throughout
1010 the whole program. The hash-sign (@code{#}) accesses GUILE directly: the
1011 code following the hash-sign is evaluated as Scheme. The boolean value
1012 @var{true} is @code{#t} in Scheme, so for LilyPond @var{true} looks like
1015 LilyPond contains a Scheme interpreter (the GUILE library) for
1016 internal use. In some places, Scheme expressions also form valid syntax:
1017 wherever it is allowed,
1021 evaluates the specified Scheme code. Example:
1023 \property Staff.TestObject \override #'foobar = #(+ 1 2)
1025 @code{\override} expects two Scheme expressions, so there are two Scheme
1026 expressions. The first one is a symbol (@code{foobar}), the second one
1027 an integer (namely, 3).
1029 In-line scheme may be used at the top level. In this case the result is
1032 Scheme is a full-blown programming language, and a full discussion is
1033 outside the scope of this document. Interested readers are referred to
1034 the website @uref{http://www.schemers.org/} for more information on
1040 @cindex real numbers
1042 Formed from an optional minus sign and a sequence of digits followed
1043 by a @emph{required} decimal point and an optional exponent such as
1044 @code{-1.2e3}. Reals can be built up using the usual operations:
1045 `@code{+}', `@code{-}', `@code{*}', and
1046 `@code{/}', with parentheses for grouping.
1054 A real constant can be followed by one of the dimension keywords:
1055 @code{\mm} @code{\pt}, @code{\in}, or @code{\cm}, for millimeters,
1056 points, inches and centimeters, respectively. This converts the number
1057 a number that is the internal representation of that dimension.
1065 Begins and ends with the @code{"} character. To include a @code{"}
1066 character in a string write @code{\"}. Various other backslash
1067 sequences have special interpretations as in the C language. A string
1068 that contains no spaces can be written without the quotes. Strings can
1069 be concatenated with the @code{+} operator.