Han-Wen Nienhuys wrote:
> I'm quite sure that I didn't port over the code for tie breaks,
> smaller cautionaries and parentheses. That's because I still have a
> question: how should restoration-natural signs be typeset in
> combination with chords?
Oh, true, you didn't. :-(
Well, I am not sure with the restauration signs, but I think that I
would prefer them always be glued to the new accidental. I know that
this contradicts the way that key signatures are printed - but the two
matters are so different that I still consider this the easiest to read
way of doing it. Probably also the one simplest to implement :)
> And cautionaries in combination with
> naturals? Is it like
>
> (n #)
>
> or
>
> n (#)
This is a far more interresting problem. I have actually given this a
lot of thought without really coming up with anything.
Definitely n(#) should NEVER be used.
The problem is that (n)# might come in need from time to time:
There is actually another bug in my accidentals routine:.
The problem is that if one has modern-cautionaries and then has
cisis1 | cis1
Then the cuationary-typesetting-algorithm wants two accidentals on the
cis (because it remembers the cisis from previous measure) while the
normal-typesetting-algorithm only wants one accidental (because IT
doesn't remember accidentals across barlines).
Currently the cautionary algorithm wins because it wants the largest
number of accidentals - and the result is (n#) - which is very bad
because the sharp is real and not cautionary. The result should be (n)#.
In the accidental engraver it is the code here
if (abs (num_caut)>abs (num))
{
num = num_caut;
cautionary = true;
}
that should be changed. (in the "cisis | cis" case, before this code,
num_caut==2 and num==1).
After this code is executed, num_caut currently isn't used for anything.
The stuff that I haven't thought through is that it should also be
possible for the user to manually set all of this.
And we should add syntax for editorial accidentals (and "no
accidentals"). Perhaps not before 1.7 but it would be stupid not to give
this a thought while having your hands deep down in the code.
Sorry, busy, perhaps returning tomorrow.
-Rune
_______________________________________________
Lilypond-devel mailing list
[EMAIL PROTECTED]
http://mail.gnu.org/mailman/listinfo/lilypond-devel
