Re: Setting paper for bookpart

[Thomas Morley]

Hi David,

to continue on this

2017-08-02 23:26 GMT+02:00 David Kastrup <address@hidden>:
> Thomas Morley <address@hidden> writes:
>
>> 2017-08-02 22:38 GMT+02:00 David Kastrup <address@hidden>:
>>
>>> I think that part of the problem is that looking at the functions in
>>>
>>> lily/book-scheme.cc
>>>
>>> it seems like bookparts were never intended to have paper blocks.  Now
>>> after actually checking it would appear that at least several bookparts
>>> cannot appear on the same page: so at least the paper dimensions likely
>>> don't clash.
>>>
>>> So what is supposed to be the actual difference between bookparts and
>>> books?
>>>
>>> I actually don't know how to tell, and it shows by the parser not
>>> knowing how to know that
>>>
>>> \xxx
>>>
>>> is not a book when xxx has been defined as \bookpart { \paper {...} ...}.
>>>
>>> I really don't have an idea what the distinction is supposed to be about.
>>
>> Thanks for your findings and thoughts.
>>
>> At least one distinction can be seen here:
>>
>> foo = \book { }
>> #(format #t "paper present? ~a" (ly:book-paper foo))
>>
>> bar = \bookpart { }
>> #(format #t "paper present? ~a" (ly:book-paper bar))
>
> Yes, books and bookparts can be told apart when specified _without_
> paper block.  Once a paper block intervenes, it's getting impossible.
>
>> The latter displays #f, which is inline with what you said above:
>> "bookparts were never intended to have paper blocks"
>> Otoh, paper in bookpart _is_ supported, at least nowadays ...
>
> The Scheme code for creating a Book has a constructor _including_ a
> paper block from the moment a book is created, and it would appear that
> after creation, there is no real accessor for changing it.
>
> The Scheme code for creating a Bookpart.  Actually, there is no such
> thing.  The Scheme functions creating a Book that have "book-part" in
> their name set the paper block to #f.
>
> That's it from the Scheme side.  The parser, however, assigns to the
> internal paper_ field bypassing any accessor functions.
>
> That looks fishy.

I meanwhile did some experiments:

Both of
\book { \bookpart { { r1 } } }
\book { \bookpart { \paper {} { r1 } } }
succeed without problems.

While for
bk-fail = \book { \bookpart { { r1 } } }  %% no paper in bookpart!!
bk-ok   = \book { \bookpart { \paper {} { r1 } } }
\bk-fail
\bk-ok

bk-fail returns:
/home/harm/lilydevel/usr/share/lilypond/current/scm/lily-library.scm:253:5:
In procedure ly:book-process in expression (process-procedure book
paper ...):
/home/harm/lilydevel/usr/share/lilypond/current/scm/lily-library.scm:253:5:
Wrong type (expecting real number): #<undefined>

After changing 'print-book-with' from lily-library.scm (where the
message points to) to get some debugging output:
(define (print-book-with book process-procedure)
  (let* ((paper (ly:parser-lookup '$defaultpaper))
         (layout (ly:parser-lookup '$defaultlayout))
         (outfile-name (get-outfile-name book)))
(format #t "\n\tbook:\t\t ~a" book)
(format #t "\n\tbookparts:\t ~a" (ly:book-book-parts book))
(format #t "\n\tpaper:\t\t ~a" paper)
(format #t "\n\tis-paper?:\t ~a"
           (module-ref (ly:output-def-scope paper) 'is-paper))
(format #t "\n\tlayout:\t\t ~a" layout)
(format #t "\n\tis-layout?:\t ~a"
           (module-ref (ly:output-def-scope layout) 'is-layout))
(format #t "\n\toutfile-name:\t ~a" outfile-name)
(format #t "\n\tprocess-procedure: ~a\n" process-procedure)
    (process-procedure book paper layout outfile-name)))

I get in terminal:
    book:         #<Book>
    bookparts:     (#<Book>)
    paper:         #< Output_def>
    is-paper?:     #t
    layout:         #< Output_def>
    is-layout?:     #t
    outfile-name:     atest-63
    process-procedure: #<primitive-procedure ly:book-process>

Which all looks fine.
So I'm at a loss here.


> In many cases of LilyPond's strangenesses I've been able to work out a
> nice theory and manufacture principles useful for ironing out the
> strangenesses and make the result appear to reflect a design that was
> not really all that apparent from the start.
>
> But I'm really sort-of adrift about what should and what should not be
> possible here, and how.  Need to stall on this (and the other
> discussion) until after the weekend as I am visiting accordionists in
> Klingenthal.  Really need to start packing.

I hope you enjoyed your weekend.

Best,
  Harm