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. They
137 can be used by invoking lilypond directly, i.e. not through ly2dvi,
138 and supplying the @code{-f} command line option. See also
139 @ref{Invoking LilyPond}.
143 * PostScript output::
145 * ASCIIScript output::
150 @subsection @TeX{} output
151 @cindex @TeX{} output
153 LilyPond will use @TeX{} by default. Even if you want to produce
154 PostScript output for viewing or printing, you should normally have
155 LilyPond produce @TeX{} first. The .tex output must be processed by
156 @TeX{} (@strong{not} La@TeX{}) to generate a .dvi. Then, @file{Dvips}
157 is used to generate PostScript. Alternatively, @file{ly2dvi} can be
158 used to generate the .dvi for you.
162 Titling is not generated unless you use @file{ly2dvi}.
165 @node PostScript output
166 @subsection PostScript output
167 @cindex PostScript output
168 @cindex direct PostScript output
170 LilyPond can produce PostScript directly, without going through @TeX{}.
171 Currently, this is mainly useful if you cannot use TeX, because direct
172 PostScript output has some problems; see Bugs below.
175 $ lilypond -fps foo.ly
177 Now processing: `foo.ly'
179 Interpreting music...[3]
180 Preprocessing elements...
181 Calculating column positions...
182 paper output to foo.ps...
184 $ cat /usr/share/lilypond/pfa/feta20.pfa foo.ps | lpr
190 Text font selection is broken.
192 The .ps file does not contain the .pfa font files. To print a .ps
193 created through direct postscript output, you should prepend the
194 necessary .pfa files to LilyPond's .ps output, or upload them to the
195 printer before printing.
197 The line height calculation is broken, you must set @var{lineheight} in
198 the paperblock if you have more than one staff in your score, e.g.
203 % Set line height to 40 staff spaces
209 @subsection Scheme output
210 @cindex Scheme output
212 In the typesetting stage, LilyPond builds a page description, which is
213 then written to disk in postscript, @TeX{} or ASCII art. Before it is
214 written, the page description is represented as Scheme expressions. You
215 can also dump these Scheme expressions to a file, which may be
216 convenient for debugging output routines. This is done with the Scheme
220 $ lilypond -fscm foo.ly
222 Now processing: `foo.ly'
224 Interpreting music...[3]
225 Preprocessing elements...
226 Calculating column positions...
227 paper output to foo.scm...
230 ;;; Usage: guile -s x.scm > x.tex
231 (primitive-load-path 'standalone.scm)
235 $ guile -s foo.scm > foo.tex
239 @node ASCIIScript output
240 @subsection ASCIIScript output
241 @cindex ASCIIScript output
245 LilyPond can output ASCII Art. This is a two step process, LilyPond
246 produces an ASCII description file, dubbed ASCIIScript (extension
247 @file{.as}). ASCIIScript has a small and simple command set that
248 includes font selection, character and string printing and line drawing
249 commands. The program @file{as2text} is used to translate an .as file
252 To produce ASCII Art, you must include an ASCII Art paper definition
253 file in your .ly, one of:
255 \include "paper-as5.ly"
256 \include "paper-as9.ly"
259 Here's an example use for ASCII Art output (the example file
260 @file{as-email.ly} is included in the LilyPond distribution), the staff
261 symbol has been made invisible:
264 $ lilypond -fas as-email.ly
266 Now processing: `as-email.ly'
268 Interpreting music...[3]
269 Preprocessing elements...
270 Calculating column positions... [2]
271 paper output to as-email.as...
273 $ as2text as-email.as 2>/dev/null
276 /| | | | | |\ |\ |\ |\ |\ |
277 / |_ 3 | | | | 5 | )| )| )| )| )|
278 | /| \ 8 * * * | 8 * * * * * |
288 The ASCII Art fonts are far from complete and not very well designed.
289 It's easy to change the glyphs, though; if you think you can do better,
290 have a look at @file{mf/*.af}.
292 Lots of resizable symbols such as slurs, ties and tuplets are missing.
294 The poor looks of most ASCII Art output and its limited general
295 usefulness gives ASCII Art output a low priority; it may be
296 dropped in future versions.
300 @subsection Sketch output
302 @uref{http://sketch.sourceforge.net,Sketch} is a Free vector drawing
303 program. LilyPond includes bare bones output for Sketch version
307 @cindex vector drawing
308 @cindex drawing program
311 @node Interpretation context
312 @section Interpretation context
315 * Creating contexts::
317 * Context properties::
318 * Engravers and performers::
319 * Changing context definitions::
320 * Defining new contexts::
324 Interpretation contexts are objects that only exist during a run of
325 LilyPond. During the interpretation phase of LilyPond (when it prints
326 "interpreting music"), the music expression in a @code{\score} block is
327 interpreted in time order. This is the same order that humans hear and
330 During this interpretation, the interpretation context holds the
331 state for the current point within the music. It contains information
335 @item What notes are playing at this point?
336 @item What symbols will be printed at this point?
337 @item What is the current key signature, time signature, point within
341 Contexts are grouped hierarchically: A @internalsref{Voice} context is
342 contained in a @internalsref{Staff} context (because a staff can contain
343 multiple voices at any point), a @internalsref{Staff} context is contained in
344 @internalsref{Score}, @internalsref{StaffGroup}, or @internalsref{ChoirStaff} context.
346 Contexts associated with sheet music output are called @emph{notation
347 contexts}, those for sound output are called @emph{performance
348 contexts}. The default definitions of the standard notation and
349 performance contexts can be found in @file{ly/engraver-init.ly} and
350 @file{ly/performer-init.ly}, respectively.
352 @node Creating contexts
353 @subsection Creating contexts
355 @cindex @code{\context}
356 @cindex context selection
358 Contexts for a music expression can be selected manually, using the
359 following music expression.
362 \context @var{contexttype} [= @var{contextname}] @var{musicexpr}
365 This instructs lilypond to interpret @var{musicexpr} within the context
366 of type @var{contexttype} and with name @var{contextname}. If this
367 context does not exist, it will be created.
369 @lilypond[verbatim,singleline]
371 \notes \relative c'' {
372 c4 <d4 \context Staff = "another" e4> f
378 In this example, the @code{c} and @code{d} are printed on the
379 default staff. For the @code{e}, a context Staff called
380 @code{another} is specified; since that does not exist, a new
381 context is created. Within @code{another}, a (default) Voice context
382 is created for the @code{e4}. When all music referring to a
383 context is finished, the context is ended as well. So after the
384 third quarter, @code{another} is removed.
388 @node Default contexts
389 @subsection Default contexts
391 Most music expressions don't need an explicit @code{\context}
392 declaration: they inherit the
393 notation context from their parent. Each note is a music expression, and
394 as you can see in the following example, only the sequential music
395 enclosing the three notes has an explicit context.
397 @lilypond[verbatim,singleline]
398 \score { \notes \context Voice = goUp { c'4 d' e' } }
401 There are some quirks that you must keep in mind when dealing with
404 First, every top level music is interpreted by the Score context, in other
405 words, you may think of @code{\score} working like
408 \context Score @var{music}
412 Second, contexts are created automatically to be able to interpret the
413 music expressions. Consider the following example.
415 @lilypond[verbatim, singleline]
416 \score { \context Score \notes { c'4 ( d' )e' } }
419 The sequential music is interpreted by the Score context initially
420 (notice that the @code{\context} specification is redundant), but when a
421 note is encountered, contexts are setup to accept that note. In this
422 case, a Thread, Voice and Staff are created. The rest of the sequential
423 music is also interpreted with the same Thread, Voice and Staff context,
424 putting the notes on the same staff, in the same voice.
426 This is a convenient mechanism, but do not expect opening chords to work
427 without @code{\context}. For every note, a separate staff is
430 @cindex explicit context
431 @cindex starting with chords
432 @cindex chords, starting with
434 @lilypond[verbatim, singleline]
435 \score { \notes <c'4 es'> }
438 Of course, if the chord is preceded by a normal note in sequential
439 music, the chord will be interpreted by the Thread of the preceding
441 @lilypond[verbatim,singleline]
442 \score { \notes { c'4 <c'4 es'> } }
447 @node Context properties
448 @subsection Context properties
450 Notation contexts have properties. These properties are from
451 the @file{.ly} file using the following expression:
452 @cindex @code{\property}
454 \property @var{contextname}.@var{propname} = @var{value}
457 Sets the @var{propname} property of the context @var{contextname} to the
458 specified Scheme expression @var{value}. All @var{propname} and
459 @var{contextname} are strings, which are typically unquoted.
461 Properties that are set in one context are inherited by all of the
462 contained contexts. This means that a property valid for the
463 @internalsref{Voice} context can be set in the @internalsref{Score} context (for
464 example) and thus take effect in all @internalsref{Voice} contexts.
466 Properties can be unset using the following expression:
468 \property @var{contextname}.@var{propname} \unset
471 @cindex properties, unsetting
472 @cindex @code{\unset}
474 This removes the definition of @var{propname} in @var{contextname}. If
475 @var{propname} was not defined in @var{contextname} (but was inherited
476 from a higher context), then this has no effect.
481 The syntax of @code{\unset} is asymmetric: @code{\property \unset} is not
482 the inverse of @code{\property \set}.
484 @node Engravers and performers
485 @subsection Engravers and performers
489 Basic building blocks of translation are called engravers; they are
494 @node Changing context definitions
495 @subsection Changing context definitions
497 @cindex context definition
498 @cindex translator definition
500 The most common way to define a context is by extending an existing
501 context. You can change an existing context from the paper block, by
502 first initializing a translator with an existing context identifier:
506 @var{context-identifier}
509 Then you can add and remove engravers using the following syntax:
511 \remove @var{engravername}
512 \consists @var{engravername}
516 Here @var{engravername} is a string, the name of an engraver in the
520 @lilypond[verbatim,singleline]
524 \translator { \StaffContext
525 \remove Clef_engraver
531 You can also set properties in a translator definition. The syntax is as
534 @var{propname} = @var{value}
535 @var{propname} \set @var{grob-propname} = @var{pvalue}
536 @var{propname} \override @var{grob-propname} = @var{pvalue}
537 @var{propname} \revert @var{grob-propname}
539 @var{propname} is a string, @var{grob-propname} a symbol, @var{value}
540 and @code{pvalue} are Scheme expressions. These type of property
541 assignments happen before interpretation starts, so a @code{\property}
542 command will override any predefined settings.
545 To simplify editing translators, all standard contexts have standard
546 identifiers called @var{name}@code{Context}, e.g. @code{StaffContext},
547 @code{VoiceContext}, see @file{ly/engraver-init.ly}.
549 @node Defining new contexts
550 @subsection Defining new contexts
552 If you want to build a context from scratch, you must also supply the
553 following extra information:
555 @item A name, specified by @code{\name @var{contextname}}.
557 @item A cooperation module. This is specified by @code{\type
564 \type "Engraver_group_engraver"
567 \consists "Staff_symbol_engraver"
568 \consists "Note_head_engraver"
569 \consistsend "Axis_group_engraver"
573 The argument of @code{\type} is the name for a special engraver that
574 handles cooperation between simple engravers such as
575 @code{Note_head_engraver} and @code{Staff_symbol_engraver}. Alternatives
576 for this engraver are the following:
578 @cindex @code{Engraver_group_engraver}
579 @item @code{Engraver_group_engraver}
580 The standard cooperation engraver.
582 @cindex @code{Score_engraver}
584 @item @code{Score_engraver}
585 This is cooperation module that should be in the top level context,
586 and only the top level context.
593 @item @code{\alias} @var{alternate-name}
594 This specifies a different name. In the above example,
595 @code{\property Staff.X = Y} will also work on @code{SimpleStaff}s
597 @item @code{\consistsend} @var{engravername}
598 Analogous to @code{\consists}, but makes sure that
599 @var{engravername} is always added to the end of the list of
602 Some engraver types need to be at the end of the list; this
603 insures they stay there even if a user adds or removes engravers.
604 End-users generally don't need this command.
606 @item @code{\accepts} @var{contextname}
607 Add @var{contextname} to the list of contexts this context can
608 contain in the context hierarchy. The first listed context is the
609 context to create by default.
611 @item @code{\denies}. The opposite of @code{\accepts}. Added for
612 completeness, but is never used in practice.
615 @item @code{\name} @var{contextname}
616 This sets the type name of the context, e.g. @internalsref{Staff},
617 @internalsref{Voice}. If the name is not specified, the translator won't do
621 In the @code{\paper} block, it is also possible to define translator
622 identifiers. Like other block identifiers, the identifier can only
623 be used as the very first item of a translator. In order to define
624 such an identifier outside of @code{\score}, you must do
629 foo = \translator @{ @dots{} @}
636 \translator @{ \foo @dots{} @}
644 @cindex paper types, engravers, and pre-defined translators
647 @node Syntactic details
648 @section Syntactic details
649 @cindex Syntactic details
651 This section describes details that were too boring to be put elsewhere.
655 * Music expressions::
656 * Manipulating music expressions::
665 @subsection Identifiers
669 What has this section got to do with identifiers?
670 It seems more appropriate in the introduction to Chapter 4,
676 All of the information in a LilyPond input file, is internally
677 represented as a Scheme value. In addition to normal Scheme data types
678 (such as pair, number, boolean, etc.), LilyPond has a number of
679 specialized data types,
690 @item Music_output_def
691 @item Moment (rational number)
694 LilyPond also includes some transient object types. Objects of these
695 types are built during a LilyPond run, and do not `exist' per se within
696 your input file. These objects are created as a result of your input
697 file, so you can include commands in the input to manipulate them,
698 during a lilypond run.
701 @item Grob: short for Graphical object.
702 @item Molecule: device-independent page output object,
703 including dimensions. Produced by some Grob functions
704 @item Translator: object that produces audio objects or Grobs. This is
705 not yet user accessible.
706 @item Font_metric: object representing a font.
710 @node Music expressions
711 @subsection Music expressions
713 @cindex music expressions
715 Music in LilyPond is entered as a music expression. Notes, rests, lyric
716 syllables are music expressions, and you can combine music expressions
717 to form new ones, for example by enclosing a list of expressions in
718 @code{\sequential @{ @}} or @code{< >}. In the following example, a
719 compound expression is formed out of the quarter note @code{c} and a
720 quarter note @code{d}:
723 \sequential @{ c4 d4 @}
726 @cindex Sequential music
727 @cindex @code{\sequential}
728 @cindex sequential music
731 @cindex Simultaneous music
732 @cindex @code{\simultaneous}
734 The two basic compound music expressions are simultaneous and
738 \sequential @code{@{} @var{musicexprlist} @code{@}}
739 \simultaneous @code{@{} @var{musicexprlist} @code{@}}
741 For both, there is a shorthand:
743 @code{@{} @var{musicexprlist} @code{@}}
747 @code{<} @var{musicexprlist} @code{>}
749 for simultaneous music.
750 In principle, the way in which you nest sequential and simultaneous to
751 produce music is not relevant. In the following example, three chords
752 are expressed in two different ways:
754 @lilypond[fragment,verbatim,center]
755 \notes \context Voice {
756 <a c'> <b d' > <c' e'>
757 < { a b c' } { c' d' e' } >
762 Other compound music expressions include
765 \transpose @var{pitch} @var{expr}
766 \apply @var{func} @var{expr}
767 \context @var{type} = @var{id} @var{expr}
768 \times @var{fraction} @var{expr}
772 @c . {Manipulating music expressions}
773 @node Manipulating music expressions
774 @subsection Manipulating music expressions
776 The @code{\apply} mechanism gives you access to the internal
777 representation of music. You can write Scheme-functions that operate
778 directly on it. The syntax is
780 \apply #@var{func} @var{music}
782 This means that @var{func} is applied to @var{music}. The function
783 @var{func} should return a music expression.
785 This example replaces the text string of a script. It also shows a dump
786 of the music it processes, which is useful if you want to know more
787 about how music is stored.
789 @lilypond[verbatim,singleline]
790 #(define (testfunc x)
791 (if (equal? (ly-get-mus-property x 'text) "foo")
792 (ly-set-mus-property! x 'text "bar"))
794 (ly-set-mus-property! x 'elements
795 (map testfunc (ly-get-mus-property x 'elements)))
800 \apply #testfunc { c'4_"foo" }
804 For more information on what is possible, see the automatically
805 generated documentation.
808 Directly accessing internal representations is dangerous: the
809 implementation is subject to changes, so you should avoid this feature
812 A final example is a function that reverses a piece of music in time:
814 @lilypond[verbatim,singleline]
815 #(define (reverse-music music)
816 (let* ((elements (ly-get-mus-property music 'elements))
817 (reversed (reverse elements))
818 (span-dir (ly-get-mus-property music 'span-direction)))
819 (ly-set-mus-property! music 'elements reversed)
821 (ly-set-mus-property! music 'span-direction (- span-dir)))
822 (map reverse-music reversed)
825 music = \notes { c'4 d'4( e'4 f'4 }
827 \score { \context Voice {
829 \apply #reverse-music \music
834 More examples are given in the distributed example files in
843 @subsection Span requests
844 @cindex Span requests
846 Notational constructs that start and end on different notes can be
847 entered using span requests. The syntax is as follows:
851 \spanrequest @var{startstop} @var{type}
855 @cindex @code{\start}
858 This defines a spanning request. The @var{startstop} parameter is either
859 -1 (@code{\start}) or 1 (@code{\stop}) and @var{type} is a string that
860 describes what should be started. Much of the syntactic sugar is a
861 shorthand for @code{\spanrequest}, for example,
863 @lilypond[fragment,verbatim,center]
864 c'4-\spanrequest \start "slur"
865 c'4-\spanrequest \stop "slur"
868 Among the supported types are @code{crescendo}, @code{decrescendo},
869 @code{beam}, @code{slur}. This is an internal command. Users are
870 encouraged to use the shorthands which are defined in the initialization
871 file @file{spanners.ly}.
876 @subsection Assignments
879 Identifiers allow objects to be assigned to names during the parse
880 stage. To assign an identifier, you use @var{name}@code{=}@var{value}
881 and to refer to an identifier, you precede its name with a backslash:
882 `@code{\}@var{name}'. @var{value} is any valid Scheme value or any of
883 the input-types listed above. Identifier assignments can appear at top
884 level in the LilyPond file, but also in @code{\paper} blocks.
886 An identifier can be created with any string for its name, but you will
887 only be able to refer to identifiers whose names begin with a letter,
888 being entirely alphabetical. It is impossible to refer to an identifier
889 whose name is the same as the name of a keyword.
891 The right hand side of an identifier assignment is parsed completely
892 before the assignment is done, so it is allowed to redefine an
893 identifier in terms of its old value, e.g.
899 When an identifier is referenced, the information it points to is
900 copied. For this reason, an identifier reference must always be the
901 first item in a block.
905 \paperIdent % wrong and invalid
909 \paperIdent % correct
916 @subsection Lexical modes
917 @cindex Lexical modes
920 @cindex @code{\notes}
921 @cindex @code{\chords}
922 @cindex @code{\lyrics}
924 To simplify entering notes, lyrics, and chords, LilyPond has three
925 special input modes in addition to the default mode: note, lyrics and
926 chords mode. These input modes change the way that normal, unquoted
927 words are interpreted: for example, the word @code{cis} may be
928 interpreted as a C-sharp, as a lyric syllable `cis' or as a C-sharp
929 major triad respectively.
931 A mode switch is entered as a compound music expression
933 @code{\notes} @var{musicexpr}
934 @code{\chords} @var{musicexpr}
935 @code{\lyrics} @var{musicexpr}.
938 In each of these cases, these expressions do not add anything to the
939 meaning of their arguments. They just instruct the parser in what mode
940 to parse their arguments.
942 Different input modes may be nested.
946 @subsection Ambiguities
951 The grammar contains a number of ambiguities. We hope to resolve them at
960 is interpreted as the string identifier assignment. However,
961 it can also be interpreted as making a string identifier @code{\foo}
962 containing @code{"bar"}, or a music identifier @code{\foo} containing
963 the syllable `bar'. The former interpretation is chosen.
965 @item If you do a nested repeat like
977 then it is ambiguous to which @code{\repeat} the
978 @code{\alternative} belongs. This is the classic if-then-else
979 dilemma. It may be solved by using braces.
983 @c . {Lexical details}
984 @node Lexical details
985 @section Lexical details
987 Even more boring details, now on lexical side of the input parser.
997 @subsection Direct Scheme
1001 @cindex Scheme, in-line code
1007 @cindex accessing Scheme
1008 @cindex evaluating Scheme
1011 LilyPond internally uses GUILE, a Scheme-interpreter. Scheme is a
1012 language from the LISP family. You can learn more about Scheme at
1013 @uref{http://www.scheme.org}. It is used to represent data throughout
1014 the whole program. The hash-sign (@code{#}) accesses GUILE directly: the
1015 code following the hash-sign is evaluated as Scheme. The boolean value
1016 @var{true} is @code{#t} in Scheme, so for LilyPond @var{true} looks like
1019 LilyPond contains a Scheme interpreter (the GUILE library) for
1020 internal use. In some places, Scheme expressions also form valid syntax:
1021 wherever it is allowed,
1025 evaluates the specified Scheme code. Example:
1027 \property Staff.TestObject \override #'foobar = #(+ 1 2)
1029 @code{\override} expects two Scheme expressions, so there are two Scheme
1030 expressions. The first one is a symbol (@code{foobar}), the second one
1031 an integer (namely, 3).
1033 In-line scheme may be used at the top level. In this case the result is
1036 Scheme is a full-blown programming language, and a full discussion is
1037 outside the scope of this document. Interested readers are referred to
1038 the website @uref{http://www.schemers.org/} for more information on
1044 @cindex real numbers
1046 Formed from an optional minus sign and a sequence of digits followed
1047 by a @emph{required} decimal point and an optional exponent such as
1048 @code{-1.2e3}. Reals can be built up using the usual operations:
1049 `@code{+}', `@code{-}', `@code{*}', and
1050 `@code{/}', with parentheses for grouping.
1058 A real constant can be followed by one of the dimension keywords:
1059 @code{\mm} @code{\pt}, @code{\in}, or @code{\cm}, for millimeters,
1060 points, inches and centimeters, respectively. This converts the number
1061 a number that is the internal representation of that dimension.
1069 Begins and ends with the @code{"} character. To include a @code{"}
1070 character in a string write @code{\"}. Various other backslash
1071 sequences have special interpretations as in the C language. A string
1072 that contains no spaces can be written without the quotes. Strings can
1073 be concatenated with the @code{+} operator.