lilypond-user
[Top][All Lists]
Advanced

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

Re: Setting paper for bookpart


From: David Kastrup
Subject: Re: Setting paper for bookpart
Date: Wed, 02 Aug 2017 23:26:51 +0200
User-agent: Gnus/5.13 (Gnus v5.13) Emacs/26.0.50 (gnu/linux)

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.

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



reply via email to

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