whiteout shouldn’t affect other grobs on same layer

classic Classic list List threaded Threaded
3 messages Options
Reply | Threaded
Open this post in threaded view
|

whiteout shouldn’t affect other grobs on same layer

Malte Meyn-3
Hi list,

in the following example the NoteHead.whiteout doesn’t only cover the
tie but also one NoteHead whites out the other:

%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%
\version "2.19.82"

\relative <<
   {
     \override NoteHead.whiteout = 3
     \override NoteHead.layer = -1
     r2 <f' a>
   } \\ {
     \override Tie.layer = -2
     <a d,>1~ q4
   }
 >>
%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%

Of course, it would be possible to use a \tweak here:

     r2 <\tweak whiteout 3 \tweak layer -1 f' a>

But that makes the code less readable and if more notes are affected
it’s a pain.

IMO it would be nice if a grob’s white box on one layer wouldn’t cover
grobs on the same layer; or at least not grobs of the same type on the
same layer.

Would it be possible to put the whiteout part half a layer below so that
\override NoteHead.layer = -1 puts the notehead at layer -1 and the
surrounding white box at layer -1.5? (Or, if you want only integers: -1
puts the notehead at layer -2 and the white box at layer -3.)

Cheers,
Malte

_______________________________________________
bug-lilypond mailing list
[hidden email]
https://lists.gnu.org/mailman/listinfo/bug-lilypond
Reply | Threaded
Open this post in threaded view
|

Re: whiteout shouldn’t affect other grobs on same layer

David Kastrup
Malte Meyn <[hidden email]> writes:

> IMO it would be nice if a grob’s white box on one layer wouldn’t cover
> grobs on the same layer; or at least not grobs of the same type on the
> same layer.
>
> Would it be possible to put the whiteout part half a layer below so
> that \override NoteHead.layer = -1 puts the notehead at layer -1 and
> the surrounding white box at layer -1.5? (Or, if you want only
> integers: -1
> puts the notehead at layer -2 and the white box at layer -3.)

I think that's a reasonable request but it would likely require
significant restructuring of the drawing process.  It would also mean
that whiteout would never work without assigning different layers.  In
practice, you cannot rely on its operation in other circumstances.

--
David Kastrup

_______________________________________________
bug-lilypond mailing list
[hidden email]
https://lists.gnu.org/mailman/listinfo/bug-lilypond
Reply | Threaded
Open this post in threaded view
|

Re: whiteout shouldn’t affect other grobs on same layer

Simon Albrecht-2
In reply to this post by Malte Meyn-3
Thanks Malte, I opened
https://sourceforge.net/p/testlilyissues/issues/5411/ as an enhancement
request.

Best, Simon


On 26.08.2018 16:49, Malte Meyn wrote:

> Hi list,
>
> in the following example the NoteHead.whiteout doesn’t only cover the
> tie but also one NoteHead whites out the other:
>
> %%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%
> \version "2.19.82"
>
> \relative <<
>   {
>     \override NoteHead.whiteout = 3
>     \override NoteHead.layer = -1
>     r2 <f' a>
>   } \\ {
>     \override Tie.layer = -2
>     <a d,>1~ q4
>   }
> >>
> %%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%
>
> Of course, it would be possible to use a \tweak here:
>
>     r2 <\tweak whiteout 3 \tweak layer -1 f' a>
>
> But that makes the code less readable and if more notes are affected
> it’s a pain.
>
> IMO it would be nice if a grob’s white box on one layer wouldn’t cover
> grobs on the same layer; or at least not grobs of the same type on the
> same layer.
>
> Would it be possible to put the whiteout part half a layer below so
> that \override NoteHead.layer = -1 puts the notehead at layer -1 and
> the surrounding white box at layer -1.5? (Or, if you want only
> integers: -1 puts the notehead at layer -2 and the white box at layer
> -3.)
>
> Cheers,
> Malte
>
> _______________________________________________
> bug-lilypond mailing list
> [hidden email]
> https://lists.gnu.org/mailman/listinfo/bug-lilypond


_______________________________________________
bug-lilypond mailing list
[hidden email]
https://lists.gnu.org/mailman/listinfo/bug-lilypond