Re: Slur with left and/or right arrow head

[Aaron Hill]

On 2019-04-16 10:37 am, Thomas Morley wrote:
> Am Mo., 15. Apr. 2019 um 19:26 Uhr schrieb Lukas-Fabian Moser 
> <address@hidden>:
> > Folks,
> >
> > in 
> > https://archiv.lilypondforum.de/index.php?topic=1744.msg9669#msg9669,
> > Harm invented a truly wonderful new feature allowing to add an arrow
> > head to the right end of a Slur (or, for that matter, a Tie,
> > PhrasingSlur etc.). I reproduce it here with only trivial changes
> > (mainly omitting parser/location).
> >
> > Now I also need slurs with arrows pointing to the left (and ideally,
> > also the option to have an arrow tip at both ends of the Slur). At 
> > first
> > glance the asymmetry favoring the right hand side of a Slur seems to 
> > be
> > hard-coded pretty deeply in Harm's code. Is there a cheap way to add a
> > choice of "left or right end" (if not even the "or/and" possibility)?
> >
> > Best
> > Lukas
>
> Hi Lukas,
>
> I started to implement the functionality, finally I more or less
> rewrote anything.
> As David K once said: rewriting all means at least knowing where the 
> bugs are...

Harm,

There is an annoying optical issue where using the angle of the curve at 
the end points does not work well for an arrow head that partially 
overlaps the curve.  Instead, one needs to consider the slope of the 
curve a little inwards from the ends so that the arrow appears to be 
aligned properly.

I took a stab at patching your code to address this.  This involved some 
additional computational work for various metrics of a Bezier curve.  
See the attached files.

Among the things I changed is that the code that adds the arrows to the 
ends of the curve no longer applies an offset.  This offset was strictly 
horizontal which did not work well for more heavily rotated arrows.  
Instead, the offset is done within the code that computes and rotates 
the arrow, so that the center of rotation is properly defined.  What I 
found is that no special case for ties needed to be applied, as the 
results looked uniform between the different grobs.

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.


-- Aaron Hill

arrow-slur-03-patch.ly
Description: Text document

arrow-slur-03-patch.pdf
Description: Adobe PDF document