On Tue, 13 Sep 2016 at 19:55 Werner LEMBERG <w...@gnu.org> wrote:
> It's issue 3179
>
> https://sourceforge.net/p/testlilyissues/issues/3179/
>
> and commit dfff5d3d1a1001f65d1f7183837f56ccd64fb15a
>
>
> http://git.savannah.gnu.org/cgit/lilypond.git/commit/?id=dfff5d3d1a1001f65d1f7183837f56ccd64fb15a
>
> > There's no way I should see a dot placed on the space above or below
> > a note on a space -- obviously notes on a line are a different
> > matter. As far as I can tell the default should be never to place
> > the dot more than one staff position away from the top or bottom
> > note of a chord.
>
> Hmm. For some reasons the default value of `chord-dots-limit' is set
> to 3. I can't remember why Keith has decided to use this number, but
> I would rather change the default to value 0.
>
> Werner
>
Zero dosn't an ideal choice in the situations I've been testing; I think 1
is safer.
e.g. here misses a dot on the space above g'
```
\version "2.19.45"
\new Staff {
\override Staff.DotColumn.chord-dots-limit = 0
< b d' e' f' g' >2.
}
```
This chord needs a setting of 1.
This example even worse (actually taken from the piano part of my
composition, which inspired the problem:
```
\version "2.19.45"
\new Staff {
\override Staff.DotColumn.chord-dots-limit = 0
\relative c'{ <c d e f a>2. }
}
```
With dots limit 0 the a (treble clef 2nd space) gets no dot. With the
default chord-dots-limit = 3 there's a dot on the B- and G-spaces below
treble clef.
It's easy to produce a really horrible chord that confuses things
completely, and having two voices is by far the best way -- this I implied
by reference to the other issue on sourceforge about dot positioning around
shared vertical beams. Sensible writing would separate the two voices
horizontally for clarity, and that's how they should be dotted. (If one
ever came across such a pathological case in the wild).
But with a single voice it should be possible to come up with conclusive
test cases for every possibility (ignoring chromatic clusters like `< c cis
d dis e f >`, which in any case aren't typeset very well by standard
methods). I'd be happy to try to come up with the test cases, but
understanding and bug-fixing Scheme code gives me a headache ;-)
Could someone that owns a copy of Gould chip in with a "best practice"
recommendation? Once the maths bit is specified it should be relatively
easy to code.
Chris
_______________________________________________
lilypond-user mailing list
lilypond-user@gnu.org
https://lists.gnu.org/mailman/listinfo/lilypond-user
