lilypond-user
[Top][All Lists]
Advanced

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

Re: Double-underline markup


From: David Kastrup
Subject: Re: Double-underline markup
Date: Sat, 19 Oct 2019 12:42:01 +0200
User-agent: Gnus/5.13 (Gnus v5.13) Emacs/27.0.50 (gnu/linux)

David Kastrup <address@hidden> writes:

> Thomas Morley <address@hidden> writes:
>
>> Am Fr., 18. Okt. 2019 um 19:21 Uhr schrieb Carl Sorensen <address@hidden>:
>>>
>>> Why not add it to lilypond proper?  I think that we would want to be
>>> careful about property names (perhaps with an underline-details
>>> property to minimize namespace pollution), but I think it would make
>>> a great addition to Lilypond.
>>
>> \underline-h is backwards compatible with builtin \underline,
>> nevertheless I hesitated to put up a patch, exactly because of that
>> namespace pollution:
>> underline-h introduces two additional properties (gap and amount).
>> I see no problem with "gap", it's an already established and
>> documented property, so why not use it?
>> Though, "amount" would be new. Ofcourse one could replace it with
>> "count" or even something else. Alas the main motivation to introduce
>> it at all was the backwards compatibilty.
>> It would be more naturally to have "amount" a simple additional
>> argument to underline-h and loose backwards compatibilty.
>>
>> So I see two possibilties:
>>
>> (1) replace builtin-underline with the new code and condone a little
>> namespace pollution.
>>      Carl: I don't understand your details-suggestion, could you
>> explain more detailed?
>>
>> (2) implement a multiple-underline-markup-command (with an
>> "amount"-argument) and let underline be derived from it as a special
>> case.
>>
>> Opinions?
>
> "amount" sounds like something you'd use for a floating-point measure as
> opposed to "count" you'd use for, well, countable items.  I rather
> dislike that name as it is so very unspecific.  It would even match some
> criterion like "thickness".

Frankly, I think the most satisfactory course would be to let have
\underline some default padding/outline action that will make nested
applications of \underline just work according to naive expectations.

It would likely make for sensible bounding boxes/outlines with regard to
cropping and boxing, and it will provide a working option for people not
investing any thought into it.  And things like underlining with several
colors for reflecting, say, presence in different editions would also
work unproblematically.

-- 
David Kastrup



reply via email to

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