#5393 Another fingering vs. accidental problem

[Simon Albrecht]

http://codereview.appspot.com/346920043

It appears that there are several issues with the interaction of fingering and accidentals; we already have [#3692] as well as the fixed issues [#728] and [#193]. Now this is the report by Pierre Perol-Schneider:

\version "2.18.2" % or 2.19

<<
   \clef "G_8"
   \time 2/4 {
     \set fingeringOrientations = #'(left)
     | % mes.7
      <e-1>8 fis <gis-1> a
   } \\ {
     \set fingeringOrientations = #'(left)
     | % mes.7
      <gis,-3>8 a,
      %% uncomment the following line:
      %\once \override Fingering.Y-extent = #'()
      <b,-2> c
   }
>>

The first fingerings are independently positioned while the second integrate the accidental sign to calculate the padding.
This happend with sharp glyph only.
I guess it has something to do with upper 'Y-extent from the fingering -- not from the accidental glyph(?) --, however I did not find any issue.

and more examples by Torsten Hämmerle:

Fingering positions at the left concerned:
1. Why aren't the numbers placed below the accidental even if there's plenty
of space?
2. Why do numbers above an accidental overlap?

This strange effect can be perfectly explained when assuming that horizontal positioning is done in a state where the numbers still sit on their baselines and these baselines are at the height of their corresponding notehead.
After horizontal positioning, these numbers will be centred vertically, i.e. shifted down by half a staff-space (because they happen to be about a staff-space high).
This shift will make them either overlap an accidental below or create an unnecessary gap.

I've tried to illustrate this in the following PDF: test-accidental-fingering2.pdf

and Thomas Morley (output attached):

I tried to Y-center the Fingering-stencil.

Though, with the example below the result is not all that convincing. If fingerings are 'right the default is already inconsistent, for different numbers.
Additionally, if fingeringOrientations contains 'left or 'right a FingeringColumn is built at Staff-level, so the 'snap-radius-property comes into play.

No real clue how to proceed...

Here my testings:

yCenterFingeringStil =
  \override Fingering.stencil =
    #(lambda (grob)
      (ly:stencil-aligned-to (ly:text-interface::print grob) Y CENTER))

mus = {
    <d'-8 ais'-4 bis'-5 d''-8 e''-8 >4. r8
    <d'-1 ais'-2 bis'-3 d''-4 e''-5 >4. r8
}

{
    \time 2/4
    \mark "Fingerings left"
    \set fingeringOrientations = #'(left)
    <>^"default"
    \mus
    \yCenterFingeringStil
    <>^"tweaked"
    \mus
    <>^"snap-radius tweaked as well"
    \override Staff.FingeringColumn.snap-radius = 1
    \mus
}

{
    \time 2/4
    \mark "Fingerings right"
    \set fingeringOrientations = #'(right)
    <>^"default"
    \mus
    \yCenterFingeringStil
    <>^"tweaked"
    \mus
    <>^"snap-radius tweaked as well"
    \override Staff.FingeringColumn.snap-radius = 1
    \mus
}

Here’s the e-mail thread: (July portion) (August portion

[Torsten Hämmerle]

Right hand fingerings (guitar stroke fingers p, m, i...) and string numbers suffer from the same problem, so they will be considered here, too.

[Torsten Hämmerle]

issue 5393: Another fingering vs. accidental problem

modified:   ../input/regression/finger-chords-accidental.ly
modified:   ../input/regression/finger-chords-dot.ly

Existing regression tests supplemented by critical collision cases.

modified:   ../lily/new-fingering-engraver.cc

• dots of all noteheads considered to avoid collisionts with fingerings
• Y-offset callback had been too late for correct X positioning:
  (A) Y-center stencil for FingeringColumn
  ---or---
  (B) Setting Y-offset (considering Y-offset set by user plus
  self-alignment-Y and parent-alignment-Y)
  This is compatible to current behaviour (except for being in time)
• add_string function removed (obsolete, never used)

http://codereview.appspot.com/346920043

[Torsten Hämmerle]

Please find attached a file showing the three regtest differences caused by this issue's changes.
The first two regtests (collisions of fingerings and accidentals resp. dots) have been amended by critical collision examples, showing that fingerings now correctly "duck" under accidentals and don't overlap anymore. Dot collisions do no occur anymore, either.
The (unchanged) snap-radius regtest now just lets the fingering slip below the # as expected, there is enough space.

FingeringColumn only kicks in for more than one horizontal (i.e. left or right) fingering, therefore I've created test cases for both one and more than one fingering.

[Anonymous]

Passes make. make check and a full make doc.

Reg test diffs attached

[Anonymous]

Patch on countdown for September 4th

[Anonymous]

Patch counted down - please push.

[Torsten Hämmerle]

Hi James,

patch against current master attached - please push it for me.

Thanks,
Torsten

[Anonymous]

author  Torsten Hämmerle <torsten.haemmerle@web.de> 
    Tue, 31 Jul 2018 22:30:28 +0100 (23:30 +0200)
committer   James Lowe <pkx166h@runbox.com> 
    Fri, 7 Sep 2018 07:52:05 +0100 (07:52 +0100)
commit  e3cca3885584b730c4da90e7e1dc0380f5abe046

Thank you Torsten