Re: how to increase Slur padding?

[Carl Sorensen]

Slur.details.free-head-distance will do what you want.  Make it larger, and the 
slur will move away from the heads of the notes.

HTH,

Carl


From: Kieren MacMillan 
Date: Sunday, October 21, 2018 at 7:28 PM
To: Lilypond-User Mailing List 
Subject: how to increase Slur padding?

Hi all,

In a current engraving project, I’ve got lots of slurs which I don’t have time 
to \shape manually. Mostly, I’d just like a little more "padding" between the 
slur and the highest note in an arpeggiating pattern:

[cid:969B7066-9D30-48E7-BA31-DD9308C8857C@home]

This could either be accomplished by making the slur a little "taller", or 
moving it a little up, or both.

I tried to adjust #'padding, but that didn’t work. I looked in #'details, but 
couldn’t make heads-nor-tails of which one(s) of the many parameters would be 
the one(s) to adjust.

Any pointers would be greatly appreciated.

Thanks,
Kieren.


Kieren MacMillan, composer
‣ website: www.kierenmacmillan.info
‣ email: i...@kierenmacmillan.info

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

Re: how to increase Slur padding?

[Kieren MacMillan]

Oh! Wait!
#'details.free-head-distance seems to be the parameter I need to adjust.

Sorry for the noise.
Hope this helps someone else one day.

Kieren.

> On Oct 21, 2018, at 9:28 PM, Kieren MacMillan  
> wrote:
> 
> Hi all,
> 
> In a current engraving project, I’ve got lots of slurs which I don’t have 
> time to \shape manually. Mostly, I’d just like a little more "padding" 
> between the slur and the highest note in an arpeggiating pattern:
> 
> 
> 
> This could either be accomplished by making the slur a little "taller", or 
> moving it a little up, or both.
> 
> I tried to adjust #'padding, but that didn’t work. I looked in #'details, but 
> couldn’t make heads-nor-tails of which one(s) of the many parameters would be 
> the one(s) to adjust.
> 
> Any pointers would be greatly appreciated.
> 
> Thanks,
> Kieren.


Kieren MacMillan, composer
‣ website: www.kierenmacmillan.info
‣ email: i...@kierenmacmillan.info


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

how to increase Slur padding?

[Kieren MacMillan]

Hi all,

In a current engraving project, I’ve got lots of slurs which I don’t have time 
to \shape manually. Mostly, I’d just like a little more "padding" between the 
slur and the highest note in an arpeggiating pattern:



This could either be accomplished by making the slur a little "taller", or 
moving it a little up, or both.

I tried to adjust #'padding, but that didn’t work. I looked in #'details, but 
couldn’t make heads-nor-tails of which one(s) of the many parameters would be 
the one(s) to adjust.

Any pointers would be greatly appreciated.

Thanks,
Kieren.


Kieren MacMillan, composer
‣ website: www.kierenmacmillan.info 
‣ email: i...@kierenmacmillan.info 
___
lilypond-user mailing list
lilypond-user@gnu.org
https://lists.gnu.org/mailman/listinfo/lilypond-user

Re: Stranges fonts SEMI-SOLVED

[Mario Moles]

Tanks!

I have removed fonts.conf from /home/mario/.config/fontconfig/

Now all is in the normality!


Il 21/10/2018 23:55, David Kastrup ha scritto:
> Looks like messed up font sizes.  Since all characters are messed up
> (time signatures, octave modifiers on clefs, all fingerings), this
> appears to be a general font inclusion problem.  If you produce output
> other than PDF (SVG or PS or PNG), does the problem appear the same?

-- 

oiram/bin/selom

Da ognuno secondo le proprie capacità ad ognuno secondo i propri bisogni.

MIB-kernellinux-tester

Linux 

MIB Lilypond
Frescobaldi
Rosegarden 

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

Re: Direction operators in event-function

[Urs Liska]

Am 21.10.2018 um 17:52 schrieb David Kastrup:

With explicit I refer to a direction explicitly assigned, either
thorugh ^/_ or an \override like \slurUp etc. If I call my function
with ^\propagate-direction there is an explicit direction in place
while the event-function is called, isn't it?

No.  I have no idea how you think direction operators work.  They don't
magically change the meaning of expressions such as

#{ -\markup #text #}

Expressions are evaluated from inside to outside, like with basically
every computer language implementing operators.


If OTOH I call it with -\propagate-direction or without an operator
the direction will only be generated/calculated at some later point,
depending on the layout algorithms.  Is that correct or am I missing
something?

You are missing something.  -postevent leaves postevent as-is,
^postevent sets it direction to #UP , _postevent sets it direction to
#DOWN .  Before it can do anything with that postevent, the postevent
has to be_there_  in the first place, like it is when being returned by
an event function.



Well, this explains my misunderstanding, and there's not much sense in 
trying to clarify all the follow-up misunderstandings. I mistook the 
direction operators to work like arguments passing information into the 
event-function which would then transparently be used inside.


If I have a fresh mind tomorrow I'll see how I can use this new 
understanding to solve my tasks ...


Urs

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

Re: Stranges fonts

[David Kastrup]

Mario Moles  writes:

> Hi!
>
> I after  I don't now wath I have this output!
>
> How I can to finder the problem!

Looks like messed up font sizes.  Since all characters are messed up
(time signatures, octave modifiers on clefs, all fingerings), this
appears to be a general font inclusion problem.  If you produce output
other than PDF (SVG or PS or PNG), does the problem appear the same?

-- 
David Kastrup

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

Re: Usage of ly:stencil-fonts ??

[Torsten Hämmerle]

Thomas Morley-2 wrote
> I like to understand the numerical values.
> The pair (-0.443862992125984 . 1.09258582677165) seems to be the
> extent in Y-axis.
> 
> But what about 3.865234375 and 1.1950157480315?

Hi Harm,

*The 3.865234375 is the font size (in millimetres!)*
Converting this into pt (1 inch = 72.27 pt = 25.4 mm), you'll end up with
the standard 11pt fontsize.
These font sizes are always (!) absolute and never depend on
global-staff-size etc.

*The 1.1950157480315 is the running width of the character*

HTH,
Torsten



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

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

Re: Direction operators in event-function

[David Kastrup]

David Kastrup  writes:

> Urs Liska  writes:
>
>> What I would *like* to do is a function like
>>
>> propagate-direction =
>> #(define-event-function (text)(markup?)
>>#{
>>  -\tweak direction #UP
>>  -(
>>  -\tweak direction #UP
>>  -\markup #text
>>#})
>>
>> but instead of hard-coding #UP I'd like to calculate the values based
>> on something. For example let the text have the opposite direction of
>> the slur and have the slur accept the ^\_ operator.
>
> Even assuming PostEvents are fixed, you'd still be stuck having to
> look at one event from another, independent one.  You'd be missing a
> reliable handle for that.  You'd need to use an engraver for doing
> that kind of interaction.

Correction: you could put a callback into a direction tweak on the text
event and this callback could check the _text_ event's direction and
then assume the _opposite_.  So after "assuming PostEvents are fixed"
should more or less work for this particular scenario, but

\tweak direction #UP \propagate-direction

would then override both tweaks.  I mean, you could still override with
a callback that reverses direction only on markup grobs but things get
increasingly murky and awkward when trying to do stuff like that.

-- 
David Kastrup

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

Re: Direction operators in event-function

[David Kastrup]

Urs Liska  writes:

> Am 21.10.2018 um 16:58 schrieb David Kastrup:
>> Urs Liska  writes:
>>
>>> But if I simply create two elements in the event-function the explicit
>>> direction operator takes no effect:
>>>
>>> propagate-direction =
>>> #(define-event-function (text)(markup?)
>>> #{
>>>   -(
>>>   -\markup #text
>>> #})
>>>
>>> {
>>>g'1 ^\propagate-direction "Up" g' )
>>> }
>>>
>>> (here both the slur and the text are printed below the staff.
>>>
>>> Why is that?
>> Multiple post events in one post event expression are temporarily
>> wrapped in one PostEvents music event.  This is then what gets the
>> up/down direction.  When it is unwrapped in use, the direction gets
>> lost.
>
> I see, this explains the observations.

It's also arguably a bug or at least a disservice (just because it's
straightforward to explain how behavior comes about does not make it
correct).

>>> And why can't I access the explicit direction operator from within the
>>> event-function? I understand that the *generated* direction isn't
>>> accessible at that moment, but an explicit setting should be known at
>>> that point, isn't it?
>> I have no idea what you are talking about.
>
> Somehow I was afraid I didn't express myself clearly enough :-(
>
>> What do you mean with
>> "explicit direction operator" here?  What do you mean with "generated"
>> direction?
>
> With explicit I refer to a direction explicitly assigned, either
> thorugh ^/_ or an \override like \slurUp etc. If I call my function
> with ^\propagate-direction there is an explicit direction in place
> while the event-function is called, isn't it?

No.  I have no idea how you think direction operators work.  They don't
magically change the meaning of expressions such as

#{ -\markup #text #}

Expressions are evaluated from inside to outside, like with basically
every computer language implementing operators.

> If OTOH I call it with -\propagate-direction or without an operator
> the direction will only be generated/calculated at some later point,
> depending on the layout algorithms.  Is that correct or am I missing
> something?

You are missing something.  -postevent leaves postevent as-is,
^postevent sets it direction to #UP , _postevent sets it direction to
#DOWN .  Before it can do anything with that postevent, the postevent
has to be _there_ in the first place, like it is when being returned by
an event function.

> What I would *like* to do is a function like
>
> propagate-direction =
> #(define-event-function (text)(markup?)
>#{
>  -\tweak direction #UP
>  -(
>  -\tweak direction #UP
>  -\markup #text
>#})
>
> but instead of hard-coding #UP I'd like to calculate the values based
> on something. For example let the text have the opposite direction of
> the slur and have the slur accept the ^\_ operator.

Even assuming PostEvents are fixed, you'd still be stuck having to look
at one event from another, independent one.  You'd be missing a reliable
handle for that.  You'd need to use an engraver for doing that kind of
interaction.

> From what I can understand this information *should* be present at
> that moment,

I have no idea what you mean with "that moment".  There is no musical
moment while music is being input, that is only available when
iterating.  And if you mean "that point of input processing" this is
nonsense since ^ and _ cannot affect an input expression before it has
been returned by the event function.

> while I'm aware that it is *not* possible to do the same relying on
> the automatically determined direction of the slur (which is only
> calculated later).
>
> Does that make my question clearer?

Not to me.  The words you use do not make sense with regard how LilyPond
can be reasonably expected to process input.  I just don't see any
viable connection between the handwaving expectations expressed therein
and any feasible manner of implementation.  So when you use sort-of
technical terms, I have no idea how to map them to the actual things
happening.

>> The only direction operator I see here is clearly applied _after_
>> calling the event function.  It cannot magically affect expressions
>> you create inside of the function before the function even returns.

Still the essence of my problem with your statements.

-- 
David Kastrup

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

Re: Usage of ly:stencil-fonts ??

[Thomas Morley]

Hi Torsten,
Am So., 21. Okt. 2018 um 17:17 Uhr schrieb Torsten Hämmerle
:
>
> Hi Harm,
>
> As it looks like, this function has not been working for some time, I've
> tested it back to 2.14.2

I even checked with 2.12.3 (without useful result)

> What does it do?
>
> In lily/stencil-interpret.cc, the function find_expression_fonts gets a
> scheme variable called expr with the following contents:
>
>
> *(A) in your NoteHead example:*
>
> (named-glyph #
> noteheads.s0)
>
> -> Font_metric contains "Emmentaler-20"
>
>
> *(B) I've changed the TextScript example to \markup \italic "italic"*
>
> Now, the expressiong gets a bit convoluted, but there's still a
>  information contained (but with font-name #f and dummy size
> 1.0), but there still are font names in the glyph-string (this time it is
> "TeXGyreSchola-Italic")
>
> (translate-stencil (0.0 . 0.0) (glyph-string #
> TeXGyreSchola-Italic 3.865234375 #f (quote ((0.717009448818898
> (-0.0341433070866142 . 1.4340188976378) 0.0 0.0 i) (0.785296062992126
> (-0.0341433070866142 . 1.36573228346457) 0.0 0.0 t) (1.26330236220472
> (-0.0341433070866142 . 1.02429921259843) 0.0 0.0 a) (0.717009448818898
> (-0.0341433070866142 . 1.60473543307087) 0.0 0.0 l) (0.717009448818898
> (-0.0341433070866142 . 1.4340188976378) 0.0 0.0 i) (0.990155905511811
> (-0.0341433070866142 . 1.05844251968504) 0.0 0.0 c)
>

Yep, (A) and (B) is the the stencil-expression.
It's what you get, after uncommenting the lines starting with
(pretty-print (ly:stencil-expr ...
in my example-code.

>
> It calls function *interpret_stencil_expression* and (in our two cases),
> "named-glyph" and "glyph-string" should use function *find_font_function*
>
> But this function just takes care of "text" and "char".
>
> Unfortunately, we have "named-glyph" and "glyph-string" instead (I think
> font handling has considerably changed in the meantime), so that the
> function returns nothing.
>
>
> *Experimental correction*
>
> When implementing "named-glyph" (giving back cadr) and "glyph-string"
> (giving back caddr), we actually get
>
> (#) for the NoteHead and
> ("TeXGyreSchola-Italic") for the TextScript in a first simple attempt.
>
> With just your \number "1" example, TextScript will report ("Emmentaler-20")
>
> So, basically, the information is there and it could be done.
> But this looks like a tracker issue, because, as you found out, the function
> currently just does nothing where it should give back a result.

Agreed, I'll put up a tracker issue.

Some background:

I'm pretty sure I can get the used fonts from (ly:stencil-expr
some-stencil), though this is tedious (I did similar before) and I
hoped ly:stencil-fonts could do the work for me ;)

My goal would be to understand how exatly in/decreased fonts affect
the final stencil and how to get this info out of a given stencil
compared to a default font size.

As an intermediate step, look at the stencil-expression from:

\markup "g"

You'll get:

(translate-stencil
  (0.0 . 0.0)
  (glyph-string
#
"TeXGyreSchola-Regular"
3.865234375
#f
'((1.1950157480315
   (-0.443862992125984 . 1.09258582677165)
   0.0
   0.0
   "g"

I like to understand the numerical values.
The pair (-0.443862992125984 . 1.09258582677165) seems to be the
extent in Y-axis.

But what about 3.865234375 and 1.1950157480315?

Any hints?

Thanks.
  Harm

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

Re: Direction operators in event-function

[Urs Liska]

Am 21.10.2018 um 16:58 schrieb David Kastrup:

Urs Liska  writes:


But if I simply create two elements in the event-function the explicit
direction operator takes no effect:

propagate-direction =
#(define-event-function (text)(markup?)
#{
  -(
  -\markup #text
#})

{
   g'1 ^\propagate-direction "Up" g' )
}

(here both the slur and the text are printed below the staff.

Why is that?

Multiple post events in one post event expression are temporarily
wrapped in one PostEvents music event.  This is then what gets the
up/down direction.  When it is unwrapped in use, the direction gets
lost.


I see, this explains the observations.



Arguably, dissolving a PostEvents into separate events should try
applying some fields (tweaks, color, direction?).  Unfortunately, there
are a lot.  Alternatively, directions and tweaks should bypass
PostEvents and go through the enclosed events.  Either would have some
performance impact.  Maybe just walk the property list of a PostEvents
and copy _everything_ found there?


And more importantly: how can I achieve the goal of creating more than
one element in an event-function and still have the explicit
directions from the calling code be applied?

And why can't I access the explicit direction operator from within the
event-function? I understand that the *generated* direction isn't
accessible at that moment, but an explicit setting should be known at
that point, isn't it?

I have no idea what you are talking about.


Somehow I was afraid I didn't express myself clearly enough :-(


What do you mean with
"explicit direction operator" here?  What do you mean with "generated"
direction?


With explicit I refer to a direction explicitly assigned, either thorugh 
^/_ or an \override like \slurUp etc. If I call my function with 
^\propagate-direction there is an explicit direction in place while the 
event-function is called, isn't it? If OTOH I call it with 
-\propagate-direction or without an operator the direction will only be 
generated/calculated at some later point, depending on the layout 
algorithms.

Is that correct or am I missing something?

What I would *like* to do is a function like

propagate-direction =
#(define-event-function (text)(markup?)
   #{
 -\tweak direction #UP
 -(
 -\tweak direction #UP
 -\markup #text
   #})

but instead of hard-coding #UP I'd like to calculate the values based on 
something. For example let the text have the opposite direction of the 
slur and have the slur accept the ^\_ operator. From what I can 
understand this information *should* be present at that moment, while 
I'm aware that it is *not* possible to do the same relying on the 
automatically determined direction of the slur (which is only calculated 
later).


Does that make my question clearer?

Urs


The only direction operator I see here is clearly applied
_after_ calling the event function.  It cannot magically affect
expressions you create inside of the function before the function even
returns.




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

Re: Usage of ly:stencil-fonts ??

[Torsten Hämmerle]

Hi Harm,

As it looks like, this function has not been working for some time, I've
tested it back to 2.14.2

What does it do?

In lily/stencil-interpret.cc, the function find_expression_fonts gets a
scheme variable called expr with the following contents:


*(A) in your NoteHead example:*

(named-glyph #
noteheads.s0)

-> Font_metric contains "Emmentaler-20"


*(B) I've changed the TextScript example to \markup \italic "italic"*

Now, the expressiong gets a bit convoluted, but there's still a
 information contained (but with font-name #f and dummy size
1.0), but there still are font names in the glyph-string (this time it is
"TeXGyreSchola-Italic")

(translate-stencil (0.0 . 0.0) (glyph-string #
TeXGyreSchola-Italic 3.865234375 #f (quote ((0.717009448818898
(-0.0341433070866142 . 1.4340188976378) 0.0 0.0 i) (0.785296062992126
(-0.0341433070866142 . 1.36573228346457) 0.0 0.0 t) (1.26330236220472
(-0.0341433070866142 . 1.02429921259843) 0.0 0.0 a) (0.717009448818898
(-0.0341433070866142 . 1.60473543307087) 0.0 0.0 l) (0.717009448818898
(-0.0341433070866142 . 1.4340188976378) 0.0 0.0 i) (0.990155905511811
(-0.0341433070866142 . 1.05844251968504) 0.0 0.0 c)


It calls function *interpret_stencil_expression* and (in our two cases),
"named-glyph" and "glyph-string" should use function *find_font_function* 

But this function just takes care of "text" and "char".

Unfortunately, we have "named-glyph" and "glyph-string" instead (I think
font handling has considerably changed in the meantime), so that the
function returns nothing.


*Experimental correction*

When implementing "named-glyph" (giving back cadr) and "glyph-string"
(giving back caddr), we actually get

(#) for the NoteHead and
("TeXGyreSchola-Italic") for the TextScript in a first simple attempt.

With just your \number "1" example, TextScript will report ("Emmentaler-20")

So, basically, the information is there and it could be done.
But this looks like a tracker issue, because, as you found out, the function
currently just does nothing where it should give back a result.

All the best,
Torsten






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

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

Re: Direction operators in event-function

[David Kastrup]

Urs Liska  writes:

> But if I simply create two elements in the event-function the explicit
> direction operator takes no effect:
>
> propagate-direction =
> #(define-event-function (text)(markup?)
>#{
>  -(
>  -\markup #text
>#})
>
> {
>   g'1 ^\propagate-direction "Up" g' )
> }
>
> (here both the slur and the text are printed below the staff.
>
> Why is that?

Multiple post events in one post event expression are temporarily
wrapped in one PostEvents music event.  This is then what gets the
up/down direction.  When it is unwrapped in use, the direction gets
lost.

Arguably, dissolving a PostEvents into separate events should try
applying some fields (tweaks, color, direction?).  Unfortunately, there
are a lot.  Alternatively, directions and tweaks should bypass
PostEvents and go through the enclosed events.  Either would have some
performance impact.  Maybe just walk the property list of a PostEvents
and copy _everything_ found there?

> And more importantly: how can I achieve the goal of creating more than
> one element in an event-function and still have the explicit
> directions from the calling code be applied?
>
> And why can't I access the explicit direction operator from within the
> event-function? I understand that the *generated* direction isn't
> accessible at that moment, but an explicit setting should be known at
> that point, isn't it?

I have no idea what you are talking about.  What do you mean with
"explicit direction operator" here?  What do you mean with "generated"
direction?  The only direction operator I see here is clearly applied
_after_ calling the event function.  It cannot magically affect
expressions you create inside of the function before the function even
returns.

-- 
David Kastrup

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

Direction operators in event-function

[Urs Liska]

I'm scratching my head  thanks to some weird behaviour (at least it 
looks like that for me). In a simple event-function any explicit 
direction operator used when calling the event will be propagated to the 
created objects:


\version "2.19.82"

propagate-direction =
#(define-event-function (text)(markup?)
   #{
 -\markup #text
   #})

{
  g'1 ^\propagate-direction "Up"
}

When I use explicit tweaks I can specify directions for multiple 
elements as well (but independently from any direction operators):


propagate-direction =
#(define-event-function (text)(markup?)
   #{
 -\tweak direction #UP
 -(
 -\tweak direction #UP
 -\markup #text
   #})

{
  g'1 \propagate-direction "Up" g' )
}

But if I simply create two elements in the event-function the explicit 
direction operator takes no effect:


propagate-direction =
#(define-event-function (text)(markup?)
   #{
 -(
 -\markup #text
   #})

{
  g'1 ^\propagate-direction "Up" g' )
}

(here both the slur and the text are printed below the staff.

Why is that?
And more importantly: how can I achieve the goal of creating more than 
one element in an event-function and still have the explicit directions 
from the calling code be applied?


And why can't I access the explicit direction operator from within the 
event-function? I understand that the *generated* direction isn't 
accessible at that moment, but an explicit setting should be known at 
that point, isn't it?


Thanks
Urs


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

Usage of ly:stencil-fonts ??

[Thomas Morley]

Hi,

in the IR one can find:
"
Function: ly:stencil-fonts s
Analyze s, and return a list of fonts used in s.
"

Though, how to get some output from it?

At least the code below returns nothing relevant.
(I used old syntax to check with all lily-version available, i.e.
since 2.12.3 up to 2.21.0)

#(use-modules (ice-9 pretty-print))

{
  \override NoteHead #'after-line-breaking =
  #(lambda (grob)
;(pretty-print (ly:stencil-expr (ly:grob-property grob 'stencil)))
(write (ly:stencil-fonts (ly:grob-property grob 'stencil

  c'1

  \override TextScript #'after-line-breaking =
  #(lambda (grob)
;(pretty-print (ly:stencil-expr (ly:grob-property grob 'stencil)))
(write (ly:stencil-fonts (ly:grob-property grob 'stencil
  s-\markup \number "1"
}

Something wrong with my code? Or stopped it working long time ago? Did
it ever work?
(I found not a single usage)

Afaict, ly:stencil-fonts was last changed with

 commit 7a6c3f44dad456a55a4d67c8647332d16022e7d1
 Author: Han-Wen Nienhuys 
 Date:   Fri Jan 7 12:40:11 2005 +

 *** empty log message ***

Any hints?

Cheers,
  Harm

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

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

[Urs Liska]

Am 21.10.2018 um 11:03 schrieb David Kastrup:

Torsten Hämmerle  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
lilypond-user@gnu.org
https://lists.gnu.org/mailman/listinfo/lilypond-user

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
lilypond-user@gnu.org
https://lists.gnu.org/mailman/listinfo/lilypond-user

Re: Optionnal finger indication

[Thomas Morley]

Am So., 21. Okt. 2018 um 09:27 Uhr schrieb Jean-Julien Fleck
:
>
> Thanks a lot Harm, it works perfectly !

A further thought:
Currently the code will return TextScript not Fingering. Thus we need
to mimic aligning/fontsize like Fingering and loose the possibility to
apply Fingering-overrides/tweaks and fingeringOrientations.

Below a code which will return proper Fingering. It may be called
directly or predefined for certain finger.

\version "2.19.82"

parDoigt =
#(define-event-function (doigt)(ly:music?)
  (if (music-is-of-type? doigt 'fingering-event)
  #{
-\tweak text
\markup {
  \number
  \concat {
\fontsize #-2 "("
$(number->string (ly:music-property doigt 'digit))
\fontsize #-2 ")"
  }
}
$doigt
  #}
  doigt))


%% predefined using ""
"(1)" = \parDoigt -1
"(2)" = \parDoigt -2
"(3)" = \parDoigt -3
"(4)" = \parDoigt -4
"(5)" = \parDoigt -5

%% predefined using unicode-signs
⑴ = \parDoigt -1

%% predefined using superscript
par¹ = \parDoigt -1


{
  %% direct call
  c''-1\parDoigt -1

  c''-1\"(1)"
  c''-1\"(2)"
  c''-1\"(3)"
  c''-1\"(4)"

  c''-1\par¹

  c''-1\⑴

  \set fingeringOrientations = #'(left)
  <
   c'-1^\"(2)"_\"(1)"
   e'-2^\"(3)"_\"(3)"
   g'-3^\"(4)"_\"(5)"
  >
}

Cheers,
  Harm

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

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

[David Kastrup]

Torsten Hämmerle  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
lilypond-user@gnu.org
https://lists.gnu.org/mailman/listinfo/lilypond-user

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

[Torsten Hämmerle]

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
lilypond-user@gnu.org
https://lists.gnu.org/mailman/listinfo/lilypond-user

Re: Optionnal finger indication

[Jean-Julien Fleck]

Thanks a lot Harm, it works perfectly !

Cheers,


> Use \fontsize instead of \magnify.
> Also, use either \fontsize #(magnification->font-size 0.5), if you
> really want to keep the numerical value for some reason.
> Though, (magnification->font-size 0.5) evaluates to -6.0. Thus
> \fontsize #-6.0 would do the trick as well.
>
> Btw, no reason to use \override #'(font-encoding . fetaText) here.
> \number is does the same and is shorter.
> For aligning I'd use \center-align in \markup and a tweak for
> parent-alignment-X.
> Furthermore I think the parens are little too tall. I made them smaller.
>
> \version "2.19.82"
>
> doigte =
>   -\tweak parent-alignment-X #CENTER
>   -\markup {
> \center-align
> \number
> \fontsize #-6.0
> %"(4)"
> \concat {
>   \fontsize #-2 "("
>   "4"
>   \fontsize #-2 ")"
> }
>   }
>
>
> \new Staff \with { \magnifyStaff 1 }
> { c''1^1-\doigte  }
>
> \new Staff \with { \magnifyStaff #5/7 }
> { c''1^1-\doigte }
>
> \new Staff \with { \magnifyStaff 2 }
> { c''1^1-\doigte }
>
>
> HTH,
>   Harm
>


-- 
JJ Fleck
Physique et Informatique
PCSI1 Lycée Kléber
___
lilypond-user mailing list
lilypond-user@gnu.org
https://lists.gnu.org/mailman/listinfo/lilypond-user