Re: Slur with left and/or right arrow head

[Aaron Hill]

On 2019-04-18 6:40 am, Carl Sorensen wrote:
> On 4/17/19, 1:41 PM, "Aaron Hill" <address@hidden> wrote:
>
>     On 2019-04-17 12:16 pm, Thomas Morley wrote:
>
>     > [ . . . ] why does Tie has a font-size property at all?
>
>     That I cannot speak to.  I'd have to dig through the code to see 
> where
>     it is used.
>
> Ties and slurs are not Bezier curves, but Bezier sandwiches (bounded
> by upper and lower Bezier curves).  As the font size gets smaller, the
> ties get thicker as a function of the thickness parameter (making the
> elements a little bit darker, just like the Emmentaler fonts).

That is all well and good, but it does not explain why Ties (or Slurs) 
need a "font-size" property.  The code that handles the thickness of the 
Bezier sandwich consults "thickness" and "line-thickness" of the grob as 
well as the thickness of the StaffSymbol.  "font-size" never enters into 
it.

It turns out that the reason for needing "font-size" is because of debug 
annotations.  When LilyPond is compiled with DEBUG_TIE_SCORING (or 
DEBUG_SLUR_SCORING), the function ly:tie::print (or ly:slur::print) will 
attach whatever string is set in the "annotation" property to the 
stencil.

However, there is an important difference between ly:tie::print and 
ly:slur::print.  For Ties, the annotation is simply added to the stencil 
without any special handling of "font-size".  But a Slur specifically 
checks for a "font-size" property and, upon finding none, adds a default 
value of -6 to the list of properties when interpreting the annotation 
markup.

It is currently necessary for define-grobs.scm to set the default value 
for "font-size" to -6 in order for the debug annotations to match 
between the two grobs.  However, ideally the logic in tie.cc for 
printing should be virtually identical to that in slur.cc.  In fact, a 
comment in the code mentions a TODO for merging the code.  If this were 
done, define-grobs.scm would no longer need to set a default value to 
support such a debug annotation.


-- Aaron Hill