bug-lilypond
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: \\bookOutputName not working if a \\paper block uses a previously de


From: David Kastrup
Subject: Re: \\bookOutputName not working if a \\paper block uses a previously defined variable
Date: Mon, 26 Mar 2012 02:44:24 +0200
User-agent: Gnus/5.13 (Gnus v5.13) Emacs/24.0.94 (gnu/linux)

Eluze <address@hidden> writes:

> Am 25.03.2012 23:50, schrieb David Kastrup:
>> Eluze<address@hidden>  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.

-- 
David Kastrup



reply via email to

[Prev in Thread] Current Thread [Next in Thread]