subject:"Re\: Possible bug"

Re: Possible bug(s) with vertical alignment on Dynamics staff

2018-08-31 Thread Thomas Morley

2018-08-31 16:14 GMT+02:00 Peter Toye :
> In a dynamic staff there aren't engraved notes to attach the text to. My 
> issue (which I wasn't 100% clear about) is that dynamics and text are treated 
> differently - dynamics ( s2\p ) appear to be centred on the staff (at least, 
> they're half-way between the two piano staves) and text is either raised or 
> lowered. In this context, #CENTER would have a legitimate meaning.

I don't see any good in special-casing "-" for Dynamics-context.
The main reason why DynamicText and TextScript behave different is the
different procedure used to calculate the Y-offset.

DynamicText uses `(scale-by-font-size -0.6)` to calculate the
Y-offset. You'll find it in define-grobs.scm, the definition of
`scale-by-font-size` in output-lib.scm.
Using this for both works here:

\new Dynamics
  \with { \override TextScript.Y-offset = #(scale-by-font-size -0.6) }
  {
s2^\p
s2_\markup \dynamic "p"
s2^\markup { ggTT \dynamic "p" }
  }



Cheers,
  Harm

___
bug-lilypond mailing list
bug-lilypond@gnu.org
https://lists.gnu.org/mailman/listinfo/bug-lilypond

Re: Possible bug(s) with vertical alignment on Dynamics staff

2018-08-31 Thread Peter Toye

Hi Malte,

Thanks very much for this.I'd not read your comment - I've not had a Lilypond 
Digest yet today so didn't know you'd commented. 

Your answer below is far fuller. My comments are inserted into it.

Sorry for my ignorance - I don't use LP much and this is the first time I've 
had to tweak anything seriously.

Best regards,

Peter
mailto:lilyp...@ptoye.com
www.ptoye.com

-
Friday, August 31, 2018, 2:03:59 PM, Malte Meyn wrote:

> Hi Peter,

> have you read my latest answer on the user list? 
> (https://lists.gnu.org/archive/html/lilypond-user/2018-08/msg00412.html)

> Am 31.08.18 um 13:36 schrieb Peter Toye:
>> 1. Just inserting the text by attaching it to a silent note using "^" or "_" 
>> works as expected. See examples 1 & 2

> I suppose that’s not one of your “possible bugs”, is it? ;)

Err No :)> I included them to use as comparisons to the other three.

>> 2. Trying "-" is the same as "_". This isn't documented, and probably 
>> shouldn't be. But it would be useful to have this syntax for horizontally 
>> aligned text. See example 3.

> _ and ^ set the direction property of an Event (in this case a
> TextScriptEvent) to #DOWN and #UP. “-” doesn’t
> set it at all—this means 
> that LilyPond decides whether to set it down or up depending on
> different things (type of grob, voice direction in polyphony, …). Your
> suggestion would mean that “-” sets the
> direction to #CENTER. This isn’t 
> supported at the moment, it’ll throw an error (you can try that:
> \override TextScript.direction = #CENTER).

> Now what should #CENTER behave like? If there
> is some space like in your 
> example, your suggestion is legitimate IMO. But in most cases one has
> only two options, up and down (f. e. think of
> articulations). Letting 
> “-” set the direction to #CENTER, even if
> #CENTER would mean “automatic 
> default behaviour” would be wrong because
> direction information coming 
> from \voiceX commands would be overridden.

In a dynamic staff there aren't engraved notes to attach the text to. My issue 
(which I wasn't 100% clear about) is that dynamics and text are treated 
differently - dynamics ( s2\p ) appear to be centred on the staff (at least, 
they're half-way between the two piano staves) and text is either raised or 
lowered. In this context, #CENTER would have a legitimate meaning. Or are the 
dynamics shifted and the text centered? Not easy to tell.

>> 3. Tweaking the Y-offset by 0.0 using "_" appears to change it to having 
>> used "^" if you see what I mean. Example 4. Tweaking it to -0.6 gives the 
>> result I want. Example 5.

> The Y-offset is calculated (see my answer to 4. below) depending on
> different things including the 'direction
> property. So if you tweak the 
> Y-offset, the direction will be ignored (at
> least for the positioning 
> question).

I didn't know that. Thanks.

>> 4. In the Internals manual, the unit for the Y-offset property is not 
>> mentioned. This wastes a lot of time in experimentation, especially given 
>> issue 3!

> What do you mean by unit? Yes, the IR 
> (http://lilypond.org/doc/v2.19/Documentation/internals/user-backend-properties)
> doesn’t say whether Y-offset is measured in staff-spaces, half
> staff-spaces or some different unit. But I
> suppose you mean “value” 
> here? That value is calculated by a procedure that uses information
> about the context (type of grob, neighbouring
> grobs, font sizes, line 
> breaks, voice direction, …). That’s why the manual cannot give the
> default value as a number—there is no such
> thing as a default value.

I meant the unit (staff-spaces, etc.). Without knowing that, it's not exactly 
easy to work out what value to insert to shift the text by the amount needed. 
Hence my comment on experimentation. Maybe it's a documentation bug.

> I hope I made clear what the problems are here.
> If not, just ask ;) (And 
> have a look at the \offset command I mentioned on the user list :))

You've pointed out the problems, but not of course the answer to my new point 
on number 2.

I shall look at \offset. It's not mentioned in the Learning manual at all. 
Thanks again.

> Cheers,
> Malte

> ___
> bug-lilypond mailing list
> bug-lilypond@gnu.org
> https://lists.gnu.org/mailman/listinfo/bug-lilypond
___
bug-lilypond mailing list
bug-lilypond@gnu.org
https://lists.gnu.org/mailman/listinfo/bug-lilypond

Re: Possible bug(s) with vertical alignment on Dynamics staff

2018-08-31 Thread Malte Meyn

Hi Peter,

have you read my latest answer on the user list?
(https://lists.gnu.org/archive/html/lilypond-user/2018-08/msg00412.html)

Am 31.08.18 um 13:36 schrieb Peter Toye:

1. Just inserting the text by attaching it to a silent note using "^" or "_" works
as expected. See examples 1 & 2

I suppose that’s not one of your “possible bugs”, is it? ;)

2. Trying "-" is the same as "_". This isn't documented, and probably shouldn't
be. But it would be useful to have this syntax for horizontally aligned text. See example 3.

_ and ^ set the direction property of an Event (in this case a
TextScriptEvent) to #DOWN and #UP. “-” doesn’t set it at all—this means
that LilyPond decides whether to set it down or up depending on
different things (type of grob, voice direction in polyphony, …). Your
suggestion would mean that “-” sets the direction to #CENTER. This isn’t
supported at the moment, it’ll throw an error (you can try that:
\override TextScript.direction = #CENTER).

Now what should #CENTER behave like? If there is some space like in your
example, your suggestion is legitimate IMO. But in most cases one has
only two options, up and down (f. e. think of articulations). Letting
“-” set the direction to #CENTER, even if #CENTER would mean “automatic
default behaviour” would be wrong because direction information coming
from \voiceX commands would be overridden.

3. Tweaking the Y-offset by 0.0 using "_" appears to change it to having used
"^" if you see what I mean. Example 4. Tweaking it to -0.6 gives the result I want.
Example 5.

The Y-offset is calculated (see my answer to 4. below) depending on
different things including the 'direction property. So if you tweak the
Y-offset, the direction will be ignored (at least for the positioning
question).

4. In the Internals manual, the unit for the Y-offset property is not
mentioned. This wastes a lot of time in experimentation, especially given issue
3!

What do you mean by unit? Yes, the IR
(http://lilypond.org/doc/v2.19/Documentation/internals/user-backend-properties)
doesn’t say whether Y-offset is measured in staff-spaces, half
staff-spaces or some different unit. But I suppose you mean “value”
here? That value is calculated by a procedure that uses information
about the context (type of grob, neighbouring grobs, font sizes, line
breaks, voice direction, …). That’s why the manual cannot give the
default value as a number—there is no such thing as a default value.

92 matches

Mail list logo