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.
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.
--
David Kastrup
_______________________________________________
lilypond-user mailing list
lilypond-user@gnu.org
https://lists.gnu.org/mailman/listinfo/lilypond-user
