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

[Thomas Morley]

2016-07-03 22:59 GMT+02:00 David Kastrup <address@hidden>:
> Thomas Morley <address@hidden> writes:
>
>> Nevertheless, I tried a workaround for single bookparts with a build
>> including issue 4908.
>>
>> (1) This works as expected:
>>
>> hdr = \header { title = "my-title" }
>>
>> %#(format #t "~y" (ly:module->alist hdr))
>>
>> \header { \hdr }
>> { r1 }
>>
>> $ exiftool file.pdf
>> returns
>> [...]
>> Title                           : my-title
>> Creator                         : LilyPond 2.19.45
>>
>>
>> (2) This one not:
>>
>> hdr = \header { title = "my-title" }
>>
>> bkprt =
>> \bookpart {
>>   \header { \hdr }
>>   { r1 }
>> }
>>
>> %#(format #t "~y" (ly:module->alist (ly:book-header bkprt)))
>>
>> \header { #(ly:book-header bkprt) }
>> \bkprt
>
>> What's the essential difference?
>
> Essentially \hdr vs #hdr .  At top level and in blocks with modules
> (namely anywhere where assignments make sense) the results of #xxx get
> ignored since commands like #(set! (hashq-ref ...)) can actually return
> values and where LilyPond accepts assignments, assignments using
> #(set!...) must equally be expected, and there are function calls like
> #(set-whatever-point-size) that also tend to be written in a manner not
> painstakingly avoiding returning anything.
>
> So \header { #(ly:book-header bkprt) } does nothing and needs to be
> written as \header { $(ly:book-header bkprt) } instead.  While #...  is
> ignored in locations accepting environments

Ah, wasn't aware of that.

> (so not within music
> expressions), $..., \... (including anything defined with
> define-scheme-function which is why there also is define-void-function)
> is not.
>
> In Scheme, it depends on the context whether a return value is ignored.
> LilyPond's visible context is often a lot less obvious.
>
> Yes, I was confused at first as well and printed #{ \header { } #} with
> your print statement to see what was up here.
>
> By the way: #(format #t ...) also does not return a well-defined value
> (according to the Scheme standard; Guile might or might not be different
> here) so it's nice for debugging to have the return value ignored in
> such contexts.
>
> --
> David Kastrup


Many thanks again for the detailed explanation.


Federico,

as off issue 4908 you then could do:

Store this, (I named it atest-38.ly):
%%%%%%%%

\bookpart {
  \header { title = "my-title" }
  { r1 }
}

\version "2.19.45"

%%%%%%%%

Then in a new file (I named it atest-37.ly):

%%%%%%%%

\version "2.19.45"

bkprt = \include "atest-38.ly"

\header { $(ly:book-header bkprt) }
\bkprt

%%%%%%%%

After compiling atest-37.ly:

$ exiftool atest-37.pdf
[...]
Title                           : my-title
Creator                         : LilyPond 2.19.45

As wished for your use-case.
Well, it's one file more, but you can still
use/include/do-whatever-you-want with atest-38.ly

Cheers,
  Harm