bug-lilypond
[Top][All Lists]
Advanced

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

Re: PDF metadata missing if \header is within a \bookpart block


From: David Kastrup
Subject: Re: PDF metadata missing if \header is within a \bookpart block
Date: Fri, 15 Jul 2016 12:40:01 +0200
User-agent: Gnus/5.13 (Gnus v5.13) Emacs/25.1.50 (gnu/linux)

Federico Bruni <address@hidden> writes:

> Il giorno ven 15 lug 2016 alle 10:47, David Kastrup <address@hidden> ha
> scritto:
>> Federico Bruni <address@hidden> writes:
>>
>>>  Il giorno dom 3 lug 2016 alle 14:57, Simon Albrecht
>>>  <address@hidden> ha scritto:
>>>>>  Let me explain better.
>>>>>  In a directory I have single files for each song. I want to
>>>>> compile
>>>>>  each of them as a standalone PDF. But I also want to include them
>>>>>  in a master file which acts as an anthology book.
>>>>>  So the master file already works fine, because the \header is in
>>>>>  the top level.
>>>>>  The problem is with each single song, because the songs use
>>>>>  \bookpart.
>>>>
>>>>  Well, I suppose you need to find a clever way of setting pdftitle
>>>> in
>>>>  the wrapper files for the single songs. This kind of things can be
>>>>  really annoying and convoluted…
>>>
>>>  This is going to cause me headaches. I've always fought with this
>>> sort
>>>  of things in LilyPond.
>>>  The problem is that I cannot include music variables within a
>>>  \bookpart block.
>>
>> Come again?  Why wouldn't you be able to do that?
>
> If you try to compile the file John-Doe-Anthology.ly in the _first_
> set of files I sent yesterday you get the error:
>
> composition-1.ily:2:1: errore: syntax error, unexpected STRING
>
> myMusic = \relative {

Ok, for one thing I really did not remember that (and I don't think I
actually compiled those files).  And for another it is not "include
music variables" but "define music variables".

The basic problem is that bookparts (like books) don't have scope of
their own, so any variable definition inside there would be global.
Which would seem like it could interfere with other bookparts.

Extra local (anonymous?) scopes for books/book parts might work, but
then bookparts can be defined independent of books and wouldn't there be
the expectation that a bookpart can reference the scopes of the books
they end up in?

In short, I don't see an "obviously right" design here.

-- 
David Kastrup



reply via email to

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