> Draft regtest and pdf output attached.
Thanks for your work!
Werner
___
lilypond-devel mailing list
lilypond-devel@gnu.org
http://lists.gnu.org/mailman/listinfo/lilypond-devel
On 9/2/09 9:50 AM, "Trevor Daniels" wrote:
>
>
> Carl Sorensen wrote Wednesday, September 02, 2009 1:06 PM
>
>> On 9/2/09 2:41 AM, "Trevor Daniels" wrote:
>>>
>>> So instead I propose to change the definition
>>> of \fermataMarkup to:
>>>
>>> fermataMarkup =
>>> #(make-music 'MultiMeasur
Carl Sorensen wrote Wednesday, September 02, 2009 1:06 PM
On 9/2/09 2:41 AM, "Trevor Daniels" wrote:
So instead I propose to change the definition
of \fermataMarkup to:
fermataMarkup =
#(make-music 'MultiMeasureTextEvent
'tweaks (list
; Set the 'text based on the 'direction
On 9/2/09 2:41 AM, "Trevor Daniels" wrote:
>
>
> Werner LEMBERG wrote Tuesday, September 01, 2009 4:30 PM
>>
>>> It seems sensible to have a distinct, lower, value, but something
>>> like 40 would place it below everything else while retaining some
>>> future flexibility.
>>
>> OK. Shall
Werner LEMBERG wrote Tuesday, September 01, 2009 4:30 PM
It seems sensible to have a distinct, lower, value, but something
like 40 would place it below everything else while retaining some
future flexibility.
OK. Shall I commit this or will you do that?
Werner, I'll do it, but I've had se
> It seems sensible to have a distinct, lower, value, but something
> like 40 would place it below everything else while retaining some
> future flexibility.
OK. Shall I commit this or will you do that?
Werner
___
lilypond-devel mailing list
li
Werner LEMBERG wrote Tuesday, September 01, 2009 6:44 AM
Hmm. I currently can't imagine a situation where a value > 0 is
needed, so I vote to remove the setting of
#'outside-staff-priority for MultiMeasureRestText -- however,
I'm
not sure whether this has any influence to issue #495 (this
lo
>>> Hmm. I currently can't imagine a situation where a value > 0 is
>>> needed, so I vote to remove the setting of
>>> #'outside-staff-priority for MultiMeasureRestText -- however, I'm
>>> not sure whether this has any influence to issue #495 (this looks
>>> rather unrelated to #'outside-staff-pr
>> Hmm. I currently can't imagine a situation where a value > 0 is
>> needed, so I vote to remove the setting of #'outside-staff-priority
>> for MultiMeasureRestText -- however, I'm not sure whether this has any
>> influence to issue #495 (this looks rather unrelated to
>> #'outside-staff-priorit
2009/8/22 Werner LEMBERG :
> Hmm. I currently can't imagine a situation where a value > 0 is
> needed, so I vote to remove the setting of #'outside-staff-priority
> for MultiMeasureRestText -- however, I'm not sure whether this has any
> influence to issue #495 (this looks rather unrelated to
> #
>> Any idea how to fix my issue?
>
> Change MultiMeasureRestText #'outside-staff-priority so it's lower
> than TextScript #'outside-staff-priority.
OK.
>> Shall this be added to the bug tracker as a regression?
>
> I don't think so; we just need to agree on a more appropriate value
> than the c
2009/8/14 Werner LEMBERG :
> Any idea how to fix my issue?
Change MultiMeasureRestText #'outside-staff-priority so it's lower
than TextScript #'outside-staff-priority.
> Shall this be added to the bug tracker
> as a regression?
I don't think so; we just need to agree on a more appropriate value
>> That patch changed the grob type from TextScript (?) to
>> MultiMeasureText, so
>
> The grob type hasn't changed: if you add a markup to a multi-bar
> rest, the function `script-to-mmrest-text' converts the ScriptEvent
> to a MultiMeasureTextEvent.
>
>> yes, it changed the priority, from what I
2009/8/13 Reinhold Kainhofer :
> That patch changed the grob type from TextScript (?) to MultiMeasureText, so
The grob type hasn't changed: if you add a markup to a multi-bar rest,
the function `script-to-mmrest-text' converts the ScriptEvent to a
MultiMeasureTextEvent.
> yes, it changed the pri
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
Am Donnerstag, 13. August 2009 23:04:32 schrieb Werner LEMBERG:
> >> As can be seen in the attached image, the text markup gets a higher
> >> `inside' priority than the fermata. I think this is wrong, since
> >> in most cases there is nothing between
>> As can be seen in the attached image, the text markup gets a higher
>> `inside' priority than the fermata. I think this is wrong, since
>> in most cases there is nothing between a rest and the fermata above
>> it. BTW, this problem doesn't happen if you replace the rests with
>> notes in the
2009/8/12 Werner LEMBERG :
> As can be seen in the attached image, the text markup gets a higher
> `inside' priority than the fermata. I think this is wrong, since in
> most cases there is nothing between a rest and the fermata above it.
> BTW, this problem doesn't happen if you replace the rests
[git d4310174]
Consider this snippet:
\new Staff {
<< { s1^"Foobar"
s1 }
{ R1
R1^\fermataMarkup }
>>
}
As can be seen in the attached image, the text markup gets a higher
`inside' priority than the fermata. I think this is wrong, since in
most cases there i
18 matches
Mail list logo
