[Top][All Lists]

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

Re: \override ClefModifier.text has no effect

From: David Kastrup
Subject: Re: \override ClefModifier.text has no effect
Date: Wed, 15 Aug 2018 12:39:39 +0200
User-agent: Gnus/5.13 (Gnus v5.13) Emacs/27.0.50 (gnu/linux)

Malte Meyn <address@hidden> writes:

> Hi list,
> I’m not sure: Is this a bug? According to the Internals Reference,
> ClefModifier has ly:text-interface::print as a stencil and should use
> the 'text property.

It does.  It just does not look whether the user has set it.

> But the following doesn’t show “8va” as expected but “8”:
> \version "2.21.0" % same for 2.19.82, 2.18.2
> {
>   % make sure the correct grob is targeted
>   \override Staff.ClefModifier.color = #red
>   % nothing happens:
>   \override Staff.ClefModifier.text = "8va"
>   \clef "treble^8"
>   R1
> }
> I suppose that there’s a reason for that behaviour (maybe in the
> definition of the \clef command?) but could be considered a bug
> nevertheless. I found the following workaround but it’s not very
> comfortable:
> {
>   \override Staff.ClefModifier.before-line-breaking =
>   #(lambda (grob)
>      (ly:grob-set-property! grob 'text "8va"))
>   \clef "treble^8"
>   R1
> }

The problem is that as of

commit 74b4c9351b01381f0dc1d6d4688dcd845fc59720
Author: Marc Hohl <address@hidden>
Date:   Sat Oct 27 22:22:25 2012 +0200

    Allows optional octavation for clefs
    Clef specifications like \clef "G_(8)" or
    \clef "bass^[15]" are supported.
    A new property clefOctavationStyle (and its cue
    clef couterpart cueClefOctavationStyle) is introduced.
    When set to 'default, the octavation number is displayed
    as before; 'parenthesized calls for parenthesized numbers
    and 'bracketed used brackets around the number.
    Furthermore, a scheme formatter function is used for
    displaying the ocatavation number, so can be customized
    more easily.

a number of _context_ variables for formatting the clef modifier have
been introduced and any grob callback placed in the 'text field would be
unable to take those into account.  One would need to redesign the
interface so that any grob callback would be able to access the
necessary information and then one could do the work in the callback,
making it both feasible for a user to replace not just the stencil
(which should be possible still I think, but have not checked) but also
the text and have the standard text->stencil callback for the stencil

David Kastrup

reply via email to

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