Hi David,
to continue on this
2017-08-02 23:26 GMT+02:00 David Kastrup <d...@gnu.org>:
> Thomas Morley <thomasmorle...@gmail.com> writes:
>
>> 2017-08-02 22:38 GMT+02:00 David Kastrup <d...@gnu.org>:
>>
>>> 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
_______________________________________________
lilypond-user mailing list
lilypond-user@gnu.org
https://lists.gnu.org/mailman/listinfo/lilypond-user
