lilypond-user
[Top][All Lists]
Advanced

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

Re: Slur with left and/or right arrow head


From: Aaron Hill
Subject: Re: Slur with left and/or right arrow head
Date: Fri, 19 Apr 2019 08:59:36 -0700
User-agent: Roundcube Webmail/1.3.8

On 2019-04-19 3:29 am, Thomas Morley wrote:
Am Mi., 17. Apr. 2019 um 21:16 Uhr schrieb Thomas Morley
<address@hidden>:

Am Di., 16. Apr. 2019 um 23:45 Uhr schrieb Aaron Hill

> Also, I "fixed" the font-size issue by bypassing the font settings
> within the grob itself, because simply scaling the glyph results in
> thicker lines.  So while font-size is now consistent between the
> different grobs, it is unfortunately now a hard-coded value.  I am
> uncertain whether this tradeoff would be acceptable.

Not sure either, why does Tie has a font-size property at all?

Hi Aaron,

still on the journey to understand all subtleties of your code...

One detail: meanwhile I don't think it's nice hardcoding the
font-size, looks bad for high or low staff-spaces.

How about looking at staff-space and derive a suitable value from it?
I.e. in `curve-adjusted-arrow-head´:

[...]
      (let* ((staff-space (ly:staff-symbol-staff-space curve))
             ;; reducing fs-from-staff-space a bit looks nicer
(fs-from-staff-space (1- (magnification->font-size staff-space)))
             (grob-font
               (ly:paper-get-font
                 (ly:grob-layout curve)
                 `(((font-encoding . fetaMusic)
                    (font-size . ,fs-from-staff-space)))))
[...]

Seems a reasonable approach, but isn't font-size already relative to staff-space?

My understanding is that a 20pt staff results in a 5pt staff-space and a font of 11pt at font-size 0. If you change the staff size, fonts will scale accordingly (unless you are using something like \abs-fontsize). That means that a font-size of 0 will always be 11/5 of the staff-space.

So if the issue is the arrow head being too big, then we should only need to set the font-size to a smaller, though still constant, value.

The main reason I was unhappy with hard-coding the size is that for some slurs/ties, a user might want a larger arrow head, meaning we should ideally be listening to font-size of the grob so each individual curve could have its own sized arrow heads. For instance, PhrasingSlurs, which typically extend a larger distance, could use a larger arrow head. But shorter curves read better with smaller arrow heads. So any hard-coded size means all arrows are the same.

Since Ties have a default font-size of -6, a user of this code would need to manually override that to something suitable just as they will need to provide a value for Slurs and PhrasingSlurs. Providing they are not using the debug annotations, then font-size for any of these grobs is unused as a property, so we can party on it without concern. (Well, the only concern is that we document things clearly, lest folks are confused why slurs and ties seem to behave differently without the overrides.)


-- Aaron Hill



reply via email to

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