Re: Microtone accidentals

[Trevor Bača]

On 7/26/07, Siska Ádám <address@hidden> wrote:
> Hello,
>
>
> after lot of people suggested to me to upgrade to version 2.11, I did
> it. I have to admit that the result is much better than in 2.10,
> specially with a lot of smart automation on text positioning, which up
> to now was done by myself. But I have some serious problems which I
> don't know how to solve. These are almost all related to textspanners.
>
> 1) If I simply use the method suggested by upgrade-ly for text spanners,
> that is:
>
> \override TextSpanner #'bound-details #'left #'text = <left-text>
> \override TextSpanner #'bound-details #'right #'text = <right-text>
>
> I don't get the dashed lines, only the texts (in my particular case,
> <left-text> was set to #(markup #:italic "restez IV"), and <right-text>
> to "", but also doesn't work with #(markup #:italic "sul sol") and "", etc.)

Please post the example where the dashes fail to print; dashes work
fine here with 2.11.x. Also, make sure you haven't set TextSpanner
#'dash-fraction = #0, which would remove the dashes as you describe.



> 2) I'm also getting the bug posted some time ago by Trevor Bača ('Overly
> thick results from markup with draw-line'). Is there some workaround
> related to this?

I think the developers posted back that that is, in fact, a bug but
has already been fixed in the repository. This means that 2.11.28 will
contain the fix. And, in fact, looking at the downloads page just now,
I see that 2.11.28 is available.

Argh, but trying the example just now shows that the overly thick nib
bug is still present in .28. Can you check and see if .28 still shows
the bug on your end? Maybe if we ask nicely, the fix will show up in
.29 ...



> 3) If there's a linebreak while a text spanner is active, the
> textspanner's end-text gets displayed on the end of the line, and the
> textspanner's begin-text gets displayed at the beginning of the new
> line. How can I avoid this behaviour and get the one that worked in
> 2.10? (No duplications of the begin and end texts.) The reason in my
> particular case is that the mentioned text-spanner tells the player that
> he has to go from ordinary bow to sul ponticello while playing, and he
> only has to reach the sul ponticello at the end of the text span. If I
> got the sp sign printed on the end of the line, and I get the ord sign
> printed at the beginning of the new line again, that would mean that the
> player should do this two times (the ord->sp transition).

Ah, for this there's a corresponding group of attributes for what
happens to TextSpanners around line breaks. These attributes can be
found at

 \override TextSpanner #'bound-details #'left-broken

and

 \override TextSpanner #'bound-details #'right-broken

which you can set like this ...

 \override TextSpanner #'bound-details #'left-broken #'text = ""

... if, for example, you do *not* want text to appear immediately
before or after a line break.



> 4) text spanners are printed for some reason some times very very far
> from the musical context, with no reason. Also, markup texts are placed
> always above text spanners, which not always is convenient, but I don't
> know how to change this behaviour. Also, if I have several text spanners
> the one after the other, every new text spanner gets placed above the
> prior one, causing the space between the staves to be enormous. The
> normal behaviour for this should be that in this cases they come one
> time above, the next time below the prior text spanner, respectively, to
> keep space. Can I force the spanners to do this somehow?

The first question about the relative vertical order of markups and
spanners can be solved, I think. Text spanners come from the
TextSpanner grob; markups come, less intuitively, from the TextScript
grob.

I think that both TextSpanner and TextScript will respect the
#'outside-staff-priority attribute which is an arbitrary and
relatively integer vertical ordering index. So you can say

 \override TextSpanner #'outside-staff-priority = #500
 \override TextScript #'outside-staff-priority = #100

... to, for example, specify that the TextSpanner should be closer to
the staff while the markup (TextScript) should be farther away from
the staff; bigger values mean "I really wanna be closer to the staff".

So compare these two scores:

\version "2.11.28"

\new Staff {
  c'4 ^ \markup { foo } \startTextSpan
  c'4 \stopTextSpan
}

\new Staff {
  \override TextSpanner #'outside-staff-priority = #200
  \override TextScript #'outside-staff-priority = #100
  c'4 ^ \markup { foo } \startTextSpan
  c'4 \stopTextSpan
}


The second part of your question about keeping spanners from
incrementally getting higher and higher on the page is harder for me
to answer. Try making these other fixes first and see if the problem
gets better. If now, post back again and we might try turning off
skyline spacing for spanners and perhaps a couple of other grobs.




> 5) There's a line in my score where I get no more linebreak. In 2.10,
> Lilypond broke me the line at that particular place, thus I got a very
> nice and balanced score (this was not a manual linebreak, however, it
> was a very good decision by the engine to put it there). Now, I don't
> get the linebreak, and thanks to this, I have two pages that contain
> single systems (I'm engraving a string quartet!), and in one of them the
> system is longer than the page... And even if I put a manual linebreak,
> it does nothing. In the particular case, there are several glissandi
> crossing that barline. Can this cause this error? Do you have any idea
> to avoid it?

The Glissando interface (and a couple of other spanner-type
interfaces) contain a new #'breakable attribute in the 2.11.x series.
Placing ...

 \override Score.Glissando #'breakable = ##t

... will fix this and the engine will happily line-break for you again.



> 6) At compilation time, I'm getting lots of 'warning: Found infinity or
> nan in output. Substituting 0.0' warnings, which I hadn't get before. Do
> you have any idea for this?

Try making the #'breakable fix in (5) and see if these warnings go away.




--
Trevor Bača
address@hidden

outside-staff-priority.png
Description: PNG image