TextScript.outside-staff-padding and text's baseline

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

TextScript.outside-staff-padding and text's baseline

Urs Liska-3
Hi,

I'm trying to place a number of TextScript elements on a common baseline
(similar to how lyrics are typeset).

Using outside-staff-padding on first sight seems to work but it doesn't
really do the job.

\version "2.19.82"

{
   \override TextScript.outside-staff-padding = 2
   g' _"g" ^"q"
   g' _"b" ^"b"
}

Here you can see that the padding is calculated against the TextScript's
*extent* - which spoils the vertica alignment when lower or upper
extenders are involved.

Is there a way to force text elements to a common *baseline* (as long as
collision avoidance doesn't force them farther away from the staff?

Urs


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

document.png (10K) Download Attachment
Reply | Threaded
Open this post in threaded view
|

Re: TextScript.outside-staff-padding and text's baseline

Kieren MacMillan
Hi Urs,

> Is there a way to force text elements to a common *baseline* (as long as collision avoidance doesn't force them farther away from the staff?

This is a long-standing irritation of mine, with respect to Lily’s text/markup handling…

The only hack I’ve found so far is to force a common height, either with a strut or a transparent combination which has both [maximum] ascenders and [maximum] descenders:

{
 \override TextScript.outside-staff-padding = 2
 g' _\markup \combine \transparent "Tj" "g" ^\markup \combine \transparent "Tj" "q"
 g' _\markup \combine \transparent "Tj" "b" ^\markup \combine \transparent "Tj" "b"
}

Hope that helps!
Kieren.
________________________________

Kieren MacMillan, composer
‣ website: www.kierenmacmillan.info
‣ email: [hidden email]


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

Re: TextScript.outside-staff-padding and text's baseline

David Kastrup
In reply to this post by Urs Liska-3
Urs Liska <[hidden email]> writes:

> Hi,
>
> I'm trying to place a number of TextScript elements on a common
> baseline (similar to how lyrics are typeset).
>
> Using outside-staff-padding on first sight seems to work but it
> doesn't really do the job.
>
> \version "2.19.82"
>
> {
>   \override TextScript.outside-staff-padding = 2
>   g' _"g" ^"q"
>   g' _"b" ^"b"
> }
>
> Here you can see that the padding is calculated against the
> TextScript's *extent* - which spoils the vertica alignment when lower
> or upper extenders are involved.
>
> Is there a way to force text elements to a common *baseline* (as long
> as collision avoidance doesn't force them farther away from the staff?

\version "2.19.82"

{
  \override TextScript.staff-padding = 2.5
  g' _"g" ^"q"
  g' _"b" ^"b"
}

--
David Kastrup

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

Re: TextScript.outside-staff-padding and text's baseline

Torsten Hämmerle
The only thing I do not like about staff-padding is that, strictly speaking,
we'd need different values for up and down direction:
Above the stave, just the descenders go between stave and text baseline,
whereas below the stave, the baseline has to be sufficiently far away from
the stave so that there's enough space for the full text height:

<http://lilypond.1069038.n5.nabble.com/file/t3887/staff-padding.png>

Wouldn't it be nice to have staff-padding accept a pair of values?

Just thinking...
Torsten
 



--
Sent from: http://lilypond.1069038.n5.nabble.com/User-f3.html

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

Re: TextScript.outside-staff-padding and text's baseline

David Kastrup
Torsten Hämmerle <[hidden email]> writes:

> The only thing I do not like about staff-padding is that, strictly speaking,
> we'd need different values for up and down direction:
> Above the stave, just the descenders go between stave and text baseline,
> whereas below the stave, the baseline has to be sufficiently far away from
> the stave so that there's enough space for the full text height:
>
> <http://lilypond.1069038.n5.nabble.com/file/t3887/staff-padding.png>
>
> Wouldn't it be nice to have staff-padding accept a pair of values?

Anything wrong with using a callback?

--
David Kastrup

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

Re: TextScript.outside-staff-padding and text's baseline

Urs Liska-3
In reply to this post by Kieren MacMillan
Hi Kieren,


Am 20.10.2018 um 21:22 schrieb Kieren MacMillan:

> Hi Urs,
>
>> Is there a way to force text elements to a common *baseline* (as long as collision avoidance doesn't force them farther away from the staff?
> This is a long-standing irritation of mine, with respect to Lily’s text/markup handling…
>
> The only hack I’ve found so far is to force a common height, either with a strut or a transparent combination which has both [maximum] ascenders and [maximum] descenders:
>
> {
>   \override TextScript.outside-staff-padding = 2
>   g' _\markup \combine \transparent "Tj" "g" ^\markup \combine \transparent "Tj" "q"
>   g' _\markup \combine \transparent "Tj" "b" ^\markup \combine \transparent "Tj" "b"
> }

First I found that very nice, but then I realized that the padding isn't
against the StaffSymbol but against the next object in general, so I'm
afraid the outside-staff-padding doesn't work at all:

\version "2.19.82"

{
  \override TextScript.outside-staff-padding = 2
  \once \stemUp
  c''2 _\markup \combine \transparent "Tj" "g" ^\markup \combine \transparent "Tj" "q"
  g' _\p _\markup \combine \transparent "Tj" "b" ^\markup \combine \transparent "Tj" "b"
}

The first upper letter is pushed outside by the stem, the second lower
letter by the dynamics.

Urs

> Hope that helps!
> Kieren.
> ________________________________
>
> Kieren MacMillan, composer
> ‣ website: www.kierenmacmillan.info
> ‣ email: [hidden email]
>


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

Re: TextScript.outside-staff-padding and text's baseline

Aaron Hill
In reply to this post by David Kastrup
On 2018-10-20 2:51 pm, David Kastrup wrote:

> Torsten Hämmerle <[hidden email]> writes:
>
>> The only thing I do not like about staff-padding is that, strictly
>> speaking,
>> we'd need different values for up and down direction:
>> Above the stave, just the descenders go between stave and text
>> baseline,
>> whereas below the stave, the baseline has to be sufficiently far away
>> from
>> the stave so that there's enough space for the full text height:
>>
>> <http://lilypond.1069038.n5.nabble.com/file/t3887/staff-padding.png>
>>
>> Wouldn't it be nice to have staff-padding accept a pair of values?
>
> Anything wrong with using a callback?

%%%%
\version "2.19.82"
{
   \override TextScript.staff-padding = #(lambda (grob)
     (let ((dir (ly:event-property (event-cause grob) 'direction)))
       (if (> dir 0) 2.5 3.5)))
   g' _"g" ^"q"
   g' _"b" ^"b"
}
%%%%

Semi-related question... Are there cases when you cannot use a callback?
  Or is it always the case that any property can be a callback?

-- Aaron Hill

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

Re: TextScript.outside-staff-padding and text's baseline

Kieren MacMillan
Hi Aaron,

> %%%%
> \version "2.19.82"
> {
>  \override TextScript.staff-padding = #(lambda (grob)
>    (let ((dir (ly:event-property (event-cause grob) 'direction)))
>      (if (> dir 0) 2.5 3.5)))
>  g' _"g" ^"q"
>  g' _"b" ^"b"
> }
> %%%%

The baselines above the staff seem aligned, but not below the staff.
Is that expected behaviour?

Thanks,
Kieren.
________________________________

Kieren MacMillan, composer
‣ website: www.kierenmacmillan.info
‣ email: [hidden email]


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

Re: TextScript.outside-staff-padding and text's baseline

Aaron Hill
On 2018-10-20 5:45 pm, Kieren MacMillan wrote:

> Hi Aaron,
>
>> %%%%
>> \version "2.19.82"
>> {
>>  \override TextScript.staff-padding = #(lambda (grob)
>>    (let ((dir (ly:event-property (event-cause grob) 'direction)))
>>      (if (> dir 0) 2.5 3.5)))
>>  g' _"g" ^"q"
>>  g' _"b" ^"b"
>> }
>> %%%%
>
> The baselines above the staff seem aligned, but not below the staff.
> Is that expected behaviour?

Hi Kieren,

The baselines are aligned.  It is just that "g" in the default font lies
above the baseline, so it looks odd.  Change _"g" to _"gb" and you can
see that the b's align.

-- Aaron Hill

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

Re: TextScript.outside-staff-padding and text's baseline

Aaron Hill
On 2018-10-20 5:49 pm, Aaron Hill wrote:
> On 2018-10-20 5:45 pm, Kieren MacMillan wrote:
>> The baselines above the staff seem aligned, but not below the staff.
>> Is that expected behaviour?
>
> Hi Kieren,
>
> The baselines are aligned.  It is just that "g" in the default font
> lies above the baseline, so it looks odd.  Change _"g" to _"gb" and
> you can see that the b's align.

Sorry, by "lies above the baseline", I meant that the upper body of the
"g" is higher than the baseline.  Obviously its descender is below the
baseline.  But this is pretty common for g's that form a loop in the
descender rather than just a simple hook.

-- Aaron Hill

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

Re: TextScript.outside-staff-padding and text's baseline

Kieren MacMillan
In reply to this post by Aaron Hill
Hi Aaron,

> The baselines are aligned.  It is just that "g" in the default font lies above the baseline, so it looks odd.  Change _"g" to _"gb" and you can see that the b's align.

Ah! Yes. Actually, changing it to 'q' makes more sense, so that the set above and below the staff are identical.

Thanks,
Kieren.
________________________________

Kieren MacMillan, composer
‣ website: www.kierenmacmillan.info
‣ email: [hidden email]


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

Re: TextScript.outside-staff-padding and text's baseline

Torsten Hämmerle
In reply to this post by David Kastrup
David Kastrup wrote
> Anything wrong with using a callback?

No, not at all, callbacks are fine and do solve the problem..
But given the fact that "aligning to the baseline" is specific to text so
that different up/down staff-padding values are rather the rule than the
exception, I thought it'd be nicer to simply say something like

  \override TextScript.staff-padding = #'(3 . 4)

instead of having to define a custom callback function for a standard
situation.

All the best,
Torsten



--
Sent from: http://lilypond.1069038.n5.nabble.com/User-f3.html

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

Re: TextScript.outside-staff-padding and text's baseline

David Kastrup
Torsten Hämmerle <[hidden email]> writes:

> David Kastrup wrote
>> Anything wrong with using a callback?
>
> No, not at all, callbacks are fine and do solve the problem..
> But given the fact that "aligning to the baseline" is specific to text so
> that different up/down staff-padding values are rather the rule than the
> exception, I thought it'd be nicer to simply say something like
>
>   \override TextScript.staff-padding = #'(3 . 4)
>
> instead of having to define a custom callback function for a standard
> situation.

Given how often this occurs, maybe we should create some function for
that purpose rather than putting pairs everywhere in peacemeal?

The principal question is what to do when the event does not have an
explicit direction.  Then one would have to refer to the grob callback
instead, maybe?

--
David Kastrup

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

Re: TextScript.outside-staff-padding and text's baseline

Torsten Hämmerle
David Kastrup wrote
> Given how often this occurs, maybe we should create some function for
> that purpose rather than putting pairs everywhere in peacemeal?
>
> The principal question is what to do when the event does not have an
> explicit direction.  Then one would have to refer to the grob callback
> instead, maybe?

Yes, the up/down padding decision can only be taken in a callback, I agree,
because we need to wait for the direction to be finally known.

I my practical cases, I often need both directions and as soon as
staff-padding is used, I get an unbalanced look without different up/down
values.
When setting the one single value too high, the text above the stave gets
pushed too far up, when setting a smaller value, the text below the stave
will not be aligned to the baseline any more and the aligning purpose of
staff-padding is not fulfilled.

All the best,
Torsten



--
Sent from: http://lilypond.1069038.n5.nabble.com/User-f3.html

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

Re: TextScript.outside-staff-padding and text's baseline

Urs Liska-3
In reply to this post by David Kastrup



Am 21.10.2018 um 11:03 schrieb David Kastrup:
Torsten Hämmerle [hidden email] writes:

David Kastrup wrote
Anything wrong with using a callback?
No, not at all, callbacks are fine and do solve the problem..
But given the fact that "aligning to the baseline" is specific to text so
that different up/down staff-padding values are rather the rule than the
exception, I thought it'd be nicer to simply say something like

  \override TextScript.staff-padding = #'(3 . 4) 

instead of having to define a custom callback function for a standard
situation.
Given how often this occurs, maybe we should create some function for
that purpose rather than putting pairs everywhere in peacemeal?

That sounds reasonable. Is there *any* chance that LilyPond actually accesses the font metrics to *calculate* the difference?
What I would expect a proper "staff-padding" behaviour for texts would be:

  • Define a property value in staff spaces, say "3"
  • Then I would want the actual whitespace between the staff and the innermost edge of the text to be three staff spaces.
  • So for a text above the staff the distance to the text's baseline should be 3 plus the (largest) lower extender's height, and
  • for a text below the staff the distance to the text's baseline should be 3 plus the (largest) capital's head (usually the X-height, isn't it?)

Providing a pair would actually be doing that calculation by trial-and-error.

One could probably calculate the difference "manually" by comparing the extents of (transparent) "T", "j", and "Tj" markups, but it would probably be more reliable if it could be retrieved from the font itself.


Urs



The principal question is what to do when the event does not have an
explicit direction.  Then one would have to refer to the grob callback
instead, maybe?



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