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.
Attachments:
-
[issue5393-regtest-diff.png](https://sourceforge.net/p/testlilyissues/issues/_discuss/thread/126d6a26/5818/attachment/issue5393-regtest-diff.png)
(123.5 kB; image/png)
---
** [issues:#5393] Another fingering vs. accidental problem**
**Status:** Started
**Created:** Thu Aug 02, 2018 12:21 PM UTC by Simon Albrecht
**Last Updated:** Thu Aug 30, 2018 05:28 PM UTC
**Owner:** Torsten Hämmerle
**Attachments:**
-
[atest-79-finger.png](https://sourceforge.net/p/testlilyissues/issues/5393/attachment/atest-79-finger.png)
(37.7 kB; image/png)
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:
~~~~
:::TeX
\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](http://lilypond.1069038.n5.nabble.com/file/t3887/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:
~~~~
:::TeX
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)](http://lists.gnu.org/archive/html/lilypond-user/2018-07/msg00534.html)
[(August
portion](http://lists.gnu.org/archive/html/lilypond-user/2018-08/msg00011.html)
---
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.------------------------------------------------------------------------------
Check out the vibrant tech community on one of the world's most
engaging tech sites, Slashdot.org! http://sdm.link/slashdot
_______________________________________________
Testlilyissues-auto mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/testlilyissues-auto
