lilypond-auto
[Top][All Lists]
Advanced

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

[Lilypond-auto] [LilyIssues-auto] [testlilyissues:issues] #3692 Fingerin


From: Auto mailings of changes to Lily Issues via Testlilyissues-auto
Subject: [Lilypond-auto] [LilyIssues-auto] [testlilyissues:issues] #3692 Fingering collision with accidentals
Date: Sat, 08 Sep 2018 14:06:49 -0000

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:


[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:

http://codereview.appspot.com/341470043

Originally created by: *anonymous

Originally created by: address@hidden

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
https://code.google.com/p/lilypond/issues/detail?id=2451
https://code.google.com/p/lilypond/issues/detail?id=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
https://code.google.com/p/lilypond/issues/detail?id=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 address@hidden 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
address@hidden
https://lists.sourceforge.net/lists/listinfo/testlilyissues-auto

reply via email to

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