sorry for the attachment...
Am 26.03.2012 16:14, schrieb Eluze:
Am 26.03.2012 02:44, schrieb David Kastrup:
Eluze<[email protected]> writes:
Am 25.03.2012 23:50, schrieb David Kastrup:
Eluze<[email protected]> writes:
Am 25.03.2012 19:35, schrieb David Kastrup:
Personally, I think it would make more sense if people just placed
assignments to output-filename and output-suffix inside of the book's
paper block. That's straightforward to understand and does not require
keeping magical ordering relations in mind. \bookOutputName is more
like a compatibility API. A courtesy to keep around, but not as
straightforward in its implications.
this works:
bigMargin = \paper { top-margin = 10 \cm }
\book {
\paper {
\bigMargin
#(define output-filename "output-filename")
}
\relative {c d e f}
}
Ugh. Why don't you write
\paper {
\bigMargin
output-filename = "output-filename"
}
I found this weird expression in the docs - other forms are not
mentioned.
Ugh. Sounds worth fixing.
I will gladly apply the simple form now!
this not (because of the order):
\book {
\paper {
#(define output-suffix "output-filename")
\bigMargin
}
\relative {c d e f}
}
Hardly surprising now, is it, if you write it as _assignment_ rather
than as some weird Scheme block?
putting the assignment before \bigMargin still produces an error and
the output returns to default.
Exactly. A predefined output definition has (if at all) to come first
in any new output definition. The same with context definitions.
It is a bit weird how they find their target if not given.
\layout { \context { \Voice ... } }
manages to change the variable Voice in \layout's module. The reason is
not that this syntax would specify which variable to change: indeed,
\Voice just _fetches_ a copy of the variable Voice. But this variable
is a context definition containing a name = "Voice" definition, and
that's enough for this purpose. If you write
\layout { silly = \Voice
\context { \silly ... } }
then the changes end up in the definition of Voice, not in the
definition of silly, exactly because of that name = "Voice" def. Or
with
\layout { \context { \Voice name="TabVoice" ... } }
you redefine TabVoice starting from a copy of Voice (at least I think
so).
For output definitions, if you use them "naked" like
xxx = \paper { ... }
\book { \xxx }
then book knows to treat this like a paper because xxx has, in its
module, a variable is-paper set to #t.
thanks - now I understand (at least a little better)!
I don't think this should be broadly explained in the manual
(certainly not under the topic /Output file names /or /Multiple output
files from one input file/) - there must be better places.
I attach my version of chapter NR 3.1.3 + 4 (in simple html). It is
shorter and I think the needed information is there.
I have included a /note /about the order but as I said above there
might be better places for that (where the \paper block is discussed,
maybe).
with no objection I will open a new Doc enhancement request (also
asking to remove these weird definitions).
Eluze
3.1.3+4 Output file names and multiple output files
LilyPond creates one output file for each \book block.
If there is no explicit \book block in the input file, LilyPond
implicitly treats the whole file as a single \book block, see Section
3.1.5 [File structure], page 426.
By default LilyPond names the output file using the input filename and
if necessary suffixes it with an increasing number - i.e. if an output
file with the same name has already been created during the run.
It is possible to override both the output filename and the suffix
appended to the basic filename in the \paper block of each \book:
\book {
\paper {
output-filename = "my special output"
output-suffix = "menuetto"
}
}
The result is an output file named "my special output-menuetto.pdf".
Note: Predefined \paper variables must be placed before the
output-filename and output-suffix assignements, e.g.
bigMargin = \paper { top-margin = 10 \cm }
\book {
\paper {
\bigMargin
output-filename = "filename after bigMargin"
}
\relative { c }
}
_______________________________________________
bug-lilypond mailing list
[email protected]
https://lists.gnu.org/mailman/listinfo/bug-lilypond
