# Fingering_engraver
The fingering/accidental collision bug remedy is not to avoid the accidental,
but to properly align the fingering (column) on the "correct" side of the stem,
i.e. on the "main noteheads".
This can be accomplished by using the note-column as parent and taking
advantage of the X-align-on-main-noteheads property of the
side-position-interface. Remark: it wasn't a viable option to just "pick" a
notehead on the correct side of the stem, because the stem direction is not yet
known when processing the fingering.
The X-align-on-main-notehead property will be set directly from the coding and
completely ignore the actual Fingering property value because there's no
discussion about the correct alignment and I needed this property for the
New_fingering_engraver, see below.
**Workaround for the time being:** this issue's bone of contention can be
manually resolved by just swapping the first two notes in the chord, so that
the fingering column will be aligned on the correct side of the stem: Voilà !
~~~
{
<f'' e'' cis'''>1 ^1^2^5
}
~~~
# New_fingering_engraver
The New_fingering_engraver now eventually takes chord accidentals into account
to avoid collisions.
If it were up to me, however, I'd much prefer a straight-column (with correct
alignment) for up/down orientation even for the New_fingering_engraver (and
Harm seems to agree, if I got him correctly).
Therefore, the New_fingering_engraver's behaviour now can be switched by
setting X-align-on-main-hoteheads property to ##t.
I did not set this as a default in scm/define-grobs.scm for
Fingering/StringNumber/StrokeFinger to keep up the standard behaviour of
New_fingering_engraver.
As an attachment, I have created a PNG file comparing the regtest differences
(including this issue's new regtests) between the old/new behaviour and to
demonstrate the new X-align-on-main-noteheads option of the
New_fingering_engraver.
All the best,
Torsten
Attachments:
-
[issue3692-regest-proof.png](https://sourceforge.net/p/testlilyissues/issues/_discuss/thread/415c7dad/6fa3/attachment/issue3692-regest-proof.png)
(191.4 kB; image/png)
---
** [issues:#3692] Fingering collision with accidentals**
**Status:** Started
**Created:** Sat Nov 30, 2013 09:17 AM UTC by Anonymous
**Last Updated:** Sat Sep 08, 2018 01:36 PM UTC
**Owner:** Torsten Hämmerle
**Attachments:**
-
[fingering.preview.png](https://sourceforge.net/p/testlilyissues/issues/3692/attachment/fingering.preview.png)
(4.6 kB; image/png)
http://codereview.appspot.com/341470043
*Originally created by:* *anonymous
*Originally created by:*
[[email protected]](http://code.google.com/u/101609726059656965678/)
Fingerings do not take accidentals into account, and fingerings align over the
first note inout of a chord, rather than centering over the whole chord.
\version "2.17.96"
\{
<e'' f'' cis'''>1 ^1^2^5
\}
From Keith Ohara:
"Unfortunately this is a different bug -- or two -- so it will
not be fixed at the same time as collisions between Fingerings.
\(1\) LilyPond has never looked at Accidentals when placing Fingering;
until recently that caused only small overlaps with sharps because
the Fingering did not previously fit so close to the chord.
\(2\) Fingering on a chord as a whole should center over the main column
of note-heads; instead it centers over the first-input note.
So, you can do the same as we did when using version 2.12: rearrange
the order of pitches in the chord so a main-column note comes first.
\{ <f'' e'' cis'''>1 ^1^2^5 \}
\*\*\*\*\*\*\*\*\*\*\*
From Janek :
This is similar to issues
[https://code.google.com/p/lilypond/issues/detail?id=2245](#2245)
[https://code.google.com/p/lilypond/issues/detail?id=2451](#2451)
[https://code.google.com/p/lilypond/issues/detail?id=2452](#2452)
and i believe to solve it in a general way we would have to teach
lilypond about different kinds of extents - see:
[http://lists.gnu.org/archive/html/lilypond-devel/2012-06/msg00230.html](http://lists.gnu.org/archive/html/lilypond-devel/2012-06/msg00230.html)
[https://code.google.com/p/lilypond/issues/detail?id=3239](#3239) \(sorry, that
issue got pretty messy\).
Currently the work i started on this is waiting until 2.18.0 is out...
What about leaving it for now and attacking this together after 2.18?
\*\*\*\*\*\*\*\*\*\*\*\*
Possibly a Known Issue in NR 1.7.1 would be in order.
---
Sent from sourceforge.net because [email protected] is
subscribed to https://sourceforge.net/p/testlilyissues/issues/
To unsubscribe from further messages, a project admin can change settings at
https://sourceforge.net/p/testlilyissues/admin/issues/options. Or, if this is
a mailing list, you can unsubscribe from the mailing list._______________________________________________
Testlilyissues-auto mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/testlilyissues-auto
