Access the first/last line of a markup
Hi, returning to my notorious "center-markup-over-measure" issue I was pointed to yet another issue: vertical alignment when the last line contains descenders or the first line does not contain ascenders. Since I am manually placing the markups (given as arguments) using ly:stencil-combine-at-edge above and below the staff I can't use staff-padding for padding against the baseline. So what I *think* I need is retrieving the first and last lines of the markup (which would be the same if it's a single line markup) and analyze that. However, that seems difficult. I checked with \displayMusic -\markup ... to see if I could retrieve stuff from that expression, and although it seems complicated-but-feasible for most cases it would fail with e.g. \wordwrap because there's no notion of the resutling lines yet. I can also access the resulting stencils after using grob-interpret-markup. However, I have no idea if/how it is possible to get to the information I need (either a "sub-stencil" for the first/last line or some information through the stencil-extent). Do you think there's any automatic solution I can pursue - or will I be left manually adjusting the padding on a case-by-case basis? Thanks for any suggestions Urs ___ lilypond-user mailing list lilypond-user@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-user
Re: lilypond.org error 500
On Sun, Mar 10, 2019 at 09:37:10AM +0100, bart deruyter wrote: >I've got the same thing here in Belgium. >[1]https://esmiltania.be >[2]On Twitter >[3]On Google+ >Op zo 10 mrt. 2019 om 09:25 schreef Andrew Bernard ><[4]andrew.bern...@gmail.com>: > > Also seeing it here in Australia. Error 500. > On Sun, 10 Mar 2019 at 19:02, Saul Tobin <[5]saul.james.to...@gmail.com> > wrote: > >Currently getting Internal Server Error 500 on Lilypond.org. Also >looks like the site is only on http, no https. Works fine here from Germany now. Might be solved already... HTTP, not HTTPS... Gabriel > ___ lilypond-user mailing list lilypond-user@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-user
Re: Access the first/last line of a markup
On 2019-03-11 2:49 am, Urs Liska wrote:
Hi,
returning to my notorious "center-markup-over-measure" issue I was
pointed to yet another issue: vertical alignment when the last line
contains descenders or the first line does not contain ascenders.
Since I am manually placing the markups (given as arguments) using
ly:stencil-combine-at-edge above and below the staff I can't use
staff-padding for padding against the baseline. So what I *think* I
need is retrieving the first and last lines of the markup (which would
be the same if it's a single line markup) and analyze that. However,
that seems difficult. I checked with \displayMusic -\markup ... to see
if I could retrieve stuff from that expression, and although it seems
complicated-but-feasible for most cases it would fail with e.g.
\wordwrap because there's no notion of the resutling lines yet.
I can also access the resulting stencils after using
grob-interpret-markup. However, I have no idea if/how it is possible
to get to the information I need (either a "sub-stencil" for the
first/last line or some information through the stencil-extent).
Do you think there's any automatic solution I can pursue - or will I
be left manually adjusting the padding on a case-by-case basis?
Thanks for any suggestions
A *hack* using transparent glyphs to force alignment:
\version "2.19.82"
#(define-markup-command (ascender-descender-placeholder layout props) ()
(let* ((sten (interpret-markup layout props #{
\markup \transparent \overlay { d p } #} ))
(yex (ly:stencil-extent sten Y)))
(ly:make-stencil (ly:stencil-expr sten) empty-interval yex)))
#(define-markup-command (apply-hack layout props arg) (markup?)
(interpret-markup layout props #{ \markup \concat {
\ascender-descender-placeholder $arg } #} ))
bad = -\tweak color #(rgb-color 0.9 0 0) \etc
good = -\tweak color #(rgb-color 0 0.8 0) \etc
{ \time 3/4
f'4\bad^"d" _"d" f'4\bad^"x" \bad_"x" f'4^"p" \bad_"p"
f'4\good^\markup \apply-hack "d" _\markup \apply-hack "d"
f'4\good^\markup \apply-hack "x" \good_\markup \apply-hack "x"
f'4^\markup \apply-hack "p" \good_\markup \apply-hack "p"
f'2.^\markup \override #'(line-width . 35) \wordwrap \apply-hack
{ raucous racoon commune consume cocoa-cream macaroons }
_\markup \override #'(line-width . 35) \wordwrap \apply-hack
{ museum owner unaware wax moose wears mauve mascara }
}
This presumes that "d" and "p" are suitable exemplars of ascenders and
descenders in the font being used.
If you want to visualize what is happening, replace "\transparent" in
the markup command definition with something like "\with-color #blue".
-- Aaron Hill___
lilypond-user mailing list
lilypond-user@gnu.org
https://lists.gnu.org/mailman/listinfo/lilypond-user
Character encoding / poor man's letterspacing
Hi,
I've written a poor-man's implementation of a simple \letterspaced
markup command:
#(define-markup-command
(letterspaced layout props text)(markup?)
(let*
((chars (string->list text))
(dummy (ly:message "Chars: ~a" chars))
(spaced-text
(string-join
(map string chars) " ")))
(interpret-markup layout props
(markup spaced-text
However, this scrambles umlauts and presumably other UTF-8 characters as
you can see with
{
s1 ^\markup \letterspaced "Täst"
}
=>Chars: (T � � s t)
Obviously the characters are wrongly en/decoded along the way, which
makes me think whether I have simply forgotten an encoding setting
somewhere (although I have no idea where and how I should include that)
or whether that whole routine is totally clumsy.
Any pointer would be appreciated.
Best Urs
___
lilypond-user mailing list
lilypond-user@gnu.org
https://lists.gnu.org/mailman/listinfo/lilypond-user
Re: Character encoding / poor man's letterspacing
On 2019-03-11 9:56 am, Urs Liska wrote:
Hi,
I've written a poor-man's implementation of a simple \letterspaced
markup command:
#(define-markup-command
(letterspaced layout props text)(markup?)
(let*
((chars (string->list text))
(dummy (ly:message "Chars: ~a" chars))
(spaced-text
(string-join
(map string chars) " ")))
(interpret-markup layout props
(markup spaced-text
However, this scrambles umlauts and presumably other UTF-8 characters
as you can see with
{
s1 ^\markup \letterspaced "Täst"
}
=>Chars: (T � � s t)
Obviously the characters are wrongly en/decoded along the way, which
makes me think whether I have simply forgotten an encoding setting
somewhere (although I have no idea where and how I should include
that) or whether that whole routine is totally clumsy.
It is my understanding that proper Unicode support is not in Guile 1.8.
As such, I believe string->list will not understand that multiple bytes
could represent a single codepoint. Also, in Guile characters values of
the form #\nnn are limited to 256 possible values (#\000 to #\377). If
you try to specify a larger value, it just wraps around: (eq? #\012
#\412)
You should be able to achieve what you want, but you'll have to examine
the characters in the list by hand looking for UTF-8 sequences and only
inserting spaces between actual characters. Note that means that you
would need to watch out for combining characters and other special
things.
I do not have the time right now, but I can definitely take a stab at
this later in the day if you would like.
-- Aaron Hill
___
lilypond-user mailing list
lilypond-user@gnu.org
https://lists.gnu.org/mailman/listinfo/lilypond-user
Re: Character encoding / poor man's letterspacing
Urs Liska writes:
> Hi,
>
> I've written a poor-man's implementation of a simple \letterspaced
> markup command:
>
> #(define-markup-command
> (letterspaced layout props text)(markup?)
> (let*
>((chars (string->list text))
> (dummy (ly:message "Chars: ~a" chars))
> (spaced-text
> (string-join
> (map string chars) " ")))
>(interpret-markup layout props
> (markup spaced-text
>
> However, this scrambles umlauts and presumably other UTF-8 characters
> as you can see with
>
> {
> s1 ^\markup \letterspaced "Täst"
> }
>
> =>Chars: (T � � s t)
>
> Obviously the characters are wrongly en/decoded along the way, which
> makes me think whether I have simply forgotten an encoding setting
> somewhere (although I have no idea where and how I should include
> that) or whether that whole routine is totally clumsy.
>
> Any pointer would be appreciated.
Guile-1.8 has only byte strings, not Unicode character strings.
However, the regexp procedures are locale aware, so you can use
something like
#(use-modules (ice-9 regex))
#(define-markup-command
(letterspaced layout props text)(string?)
(let*
((chars (map match:substring (list-matches "." text)))
(spaced-text (string-join chars " ")))
(interpret-markup layout props
(markup spaced-text
{
s1 ^\markup \letterspaced "Täst"
}
--
David Kastrup
___
lilypond-user mailing list
lilypond-user@gnu.org
https://lists.gnu.org/mailman/listinfo/lilypond-user
re: cannot access server
I'm having similar trouble again 3/11 3:00 pm EDT >> >> For what its worth, that link as well as the rest of the site appears to >> be working for me.? Mayhaps the issue was resolved? >> >> -- Aaron Hill >> >> ___ >> lilypond-user mailing list >> lilypond-user@gnu.org >> https://lists.gnu.org/mailman/listinfo/lilypond-user >> > When Joseph posted the link it failed for me exactly as he said, as did > http://lilypond.org. Aaron, as you have noticed it is working now. I > therefore agree it was probably an issue at the server end that has been > fixed. > > -- > J Martin Rushton MBCS > > -- ___ lilypond-user mailing list lilypond-user@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-user
Re: Character encoding / poor man's letterspacing
On 2019-03-11 11:30 am, David Kastrup wrote:
Urs Liska writes:
Hi,
I've written a poor-man's implementation of a simple \letterspaced
markup command:
#(define-markup-command
(letterspaced layout props text)(markup?)
(let*
((chars (string->list text))
(dummy (ly:message "Chars: ~a" chars))
(spaced-text
(string-join
(map string chars) " ")))
(interpret-markup layout props
(markup spaced-text
However, this scrambles umlauts and presumably other UTF-8 characters
as you can see with
{
s1 ^\markup \letterspaced "Täst"
}
=>Chars: (T � � s t)
Obviously the characters are wrongly en/decoded along the way, which
makes me think whether I have simply forgotten an encoding setting
somewhere (although I have no idea where and how I should include
that) or whether that whole routine is totally clumsy.
Any pointer would be appreciated.
Guile-1.8 has only byte strings, not Unicode character strings.
However, the regexp procedures are locale aware, so you can use
something like
/./ isn't smart enough to match Unicode graphemes. You would need /\X/,
however that is not supported in POSIX ERE. Neither is the
approximation /\P{M}\p{M}*+/.
-- Aaron Hill
___
lilypond-user mailing list
lilypond-user@gnu.org
https://lists.gnu.org/mailman/listinfo/lilypond-user
Re: Simple example with vertical spacing and dynamic contexts
I found a temporary way to control the vertical spacing in the middle of
the piece. It looks awful, but it works. I still hope that someone will
suggest a more correct way.
\new StaffGroup
<<
\new Staff
{
c' c' c' c' \break
% Add an invisible very low note to push the staffs.
c'4*1/2 \once \hideNotes c,8 c'4 c' c'
}
\new Staff { c' c' c' c' c' c' c' c' }
>>
вт, 5 мар. 2019 г. в 21:07, Павел Буданов :
> How to control vertical spacing in the middle of a piece?
>
> \new StaffGroup \with
> { \override StaffGrouper.staff-staff-spacing.padding = 10 } % It's OK
> <<
>\new Staff
>{
> c' c' c' c'
> \break
> \override StaffGrouper.staff-staff-spacing.padding = 30 % It isn't
> work
> c' c' c' c'
>}
>\new Staff { c' c' c' c' c' c' c' c' }
> >>
>
> пт, 1 февр. 2019 г. в 11:41, Павел Буданов :
>
>> It really helped me, I am very grateful to you. Would you like to change
>> the vertical spacing chapter
>>
>> in the learning manual? You were able to explain a lot of things in plain
>> language.
>>
>> пт, 1 февр. 2019 г. в 05:54, Aaron Hill :
>>
>>> On 2019-01-31 9:11 am, Павел Буданов wrote:
>>> > I've solved this problem partially with for lower contexts, but i
>>> > can't find the necessary properties for upper contexts. Can you help
>>> > me?
>>> >
>>> > \new StaffGroup
>>> > <<
>>> > \new Dynamics { s2.\< s4\ff }
>>> > \new Lyrics \lyricmode { Ly4 -- ric ly -- ric }
>>> > \new Staff \with
>>> > { \override VerticalAxisGroup.staff-staff-spacing =
>>> > #'((basic-distance . 20) (padding . 0.5)) }
>>> > { a'4 a' a' a' }
>>> > \new Staff { d'4 d' d' d' }
>>> > \new Lyrics \with
>>> > {
>>> > \override VerticalAxisGroup.nonstaff-relatedstaff-spacing =
>>> > #'((basic-distance . 10) (padding . 0.5))
>>> > \override VerticalAxisGroup.nonstaff-nonstaff-spacing =
>>> > #'((basic-distance . 10) (padding . 0.5))
>>> > }
>>> > \lyricmode { Ly4 -- ric ly -- ric }
>>> > \new Dynamics { s2.\< s4\ff }
>>> > >>
>>>
>>> Be sure to examine the output of LilyPond for warnings, not just errors:
>>>
>>> > warning: staff-affinities should only decrease
>>>
>>> This is telling you that you need to manually adjust
>>> VerticalAxisGroup.staff-affinity. By default, Dynamics uses a
>>> staff-affinity of CENTER (0) as it typically appears between two staves,
>>> whereas Lyrics uses UP (1) as it typically appears below a staff. Your
>>> upper Lyrics context is trying to locate its "relatedstaff" above, but
>>> there is none to be found. You will need to set its staff-affinity to
>>> DOWN (-1). (You could leave the two Dynamics contexts set to CENTER
>>> staff-affinity; but it arguably better to also explicitly set them to
>>> UP/DOWN based on where they appear.)
>>>
>>> There is a second issue that unfortunately there is no warning for. You
>>> are setting basic-distance but not minimum-distance as well. By
>>> omitting minimum-distance from the spacing alist, you are using the
>>> default value of zero. LilyPond only attempts to honor basic-distance,
>>> but will collapse down to minimum-distance if needed (and often a little
>>> too eagerly). If you tried to set only basic-distance for the upper
>>> contexts, you may find that it has no effect.
>>>
>>> It may be easier to see what it going on by only using padding, although
>>> a combination of basic-distance, minimum-distance, padding, and
>>> stretchability is often required to get the most out of the flexible
>>> spacing system. Consider the following:
>>>
>>>
>>> \version "2.19.82"
>>>
>>> % Forcibly reset all default spacing variables to zero.
>>> \layout {
>>>\context { \Dynamics
>>> \override VerticalAxisGroup.nonstaff-nonstaff-spacing = #'(())
>>> \override VerticalAxisGroup.nonstaff-relatedstaff-spacing = #'(())
>>> \override VerticalAxisGroup.nonstaff-unrelatedstaff-spacing = #'(())
>>>}
>>>\context { \Lyrics
>>> \override VerticalAxisGroup.nonstaff-nonstaff-spacing = #'(())
>>> \override VerticalAxisGroup.nonstaff-relatedstaff-spacing = #'(())
>>> \override VerticalAxisGroup.nonstaff-unrelatedstaff-spacing = #'(())
>>>}
>>>\context { \Staff
>>> \override VerticalAxisGroup.default-staff-staff-spacing = #'(())
>>> \override VerticalAxisGroup.staff-staff-spacing = #'(())
>>>}
>>> }
>>>
>>> \new StaffGroup <<
>>>\new Dynamics \with {
>>>% Dynamics is above Staff.
>>>\override VerticalAxisGroup.staff-affinity = #DOWN
>>>% Spacing between this Dynamics and the following Lyrics.
>>>\override VerticalAxisGroup.nonstaff-nonstaff-spacing =
>>> #'((padding . 2))
>>> }
>>> { s2.\< s4\ff }
>>>\new Lyrics \with {
>>>% Lyrics is above Staff.
>>>\override VerticalAxisGroup.staff-affinity = #DOWN
>>>% Spacing between this Lyrics and the following Staff.
>>>\override
Re: Simple example with vertical spacing and dynamic contexts
On 3/11/2019 3:33 PM, Павел Буданов wrote:
I found a temporary way to control the vertical spacing in the middle
of the piece. It looks awful, but it works. I still hope that someone
will suggest a more correct way.
\new StaffGroup
<<
\new Staff
{
c' c' c' c' \break
% Add an invisible very low note to push the staffs.
c'4*1/2 \once \hideNotes c,8 c'4 c' c'
}
\new Staff { c' c' c' c' c' c' c' c' }
>>
Hello,
I'm sure other people have different ways they approach this, but for me
this works great so far with no negative side effects in my projects.
Granted, I don't use this code often but it's never failed me yet.
Basically, it's just a very small markup blank space or if you prefer, a
vertical spacer instead. Hope this helps you.
\version "2.19.82"
% _\markup \lower #3 " "
% or
% ^\markup \raise #3 " "
% also you could define something like this
verticalSpacer = -\markup \transparent \draw-line #'(0 . 12)
% and input it inline with music
\new StaffGroup
<<
\new Staff
{
c'4 c' c' c' \break
c' c' c' c'
}
\new Staff { c' c' c' c' c' c'^\markup \raise #10 " " c' c' }
>>
\new StaffGroup
<<
\new Staff
{
c'4 c' c' c' \break
c' c' c' c'
}
\new Staff { c' c' c' c' c' c'^\verticalSpacer c' c' }
>>
___
lilypond-user mailing list
lilypond-user@gnu.org
https://lists.gnu.org/mailman/listinfo/lilypond-user
Re: Bug: restarting staff destroys DynamicLineSpanner.staff-padding after line break
On Thu, Mar 7, 2019 at 2:14 AM David Kastrup wrote:
> Trevor Bača writes:
>
> > Restarting the staff during the lifespan of a multisystem
> > DynamicLineSpanner destroys the value of DynamicLineSpanner properties
> > (like staff-padding) that were set when the DynamicLineSpanner was
> > created.
>
> It doesn't. It's just that the DynamicLineSpanner has a relation with
> the Staff it was started in.
>
> > In the MWE below, the hairpin should exhibit staff-padding equal to 10
> > staff spaces below all four systems; but the value of staff-padding is
> lost
> > at the point (in system 2) that the staff is restarted; we see evidence
> of
> > this after the next line break (in systems 3 and 4) where no staff
> padding
> > appears.
> >
> > %%% BEGIN %%%
> >
> > \version "2.19.82"
> >
> > \new Staff
> > {
> >
> > \override DynamicLineSpanner.staff-padding = 10
> > c'1
> > \p
> > \<
> > c'1
> > c'1
> > \break
> >
> > c'1
> > \stopStaff
> > \startStaff
> > c'1
> > c'1
> > \break
> >
> > c'1
> > c'1
> > c'1
> > \break
> >
> > c'1
> > c'1
> > c'1
> > \f
> >
> > }
> >
> > \paper
> > {
> > indent = 0
> > ragged-right = ##t
> > system-system-spacing.minimum-distance = 30
> > }
> >
> > %%% END %%%
> >
> > [image: restart-staff-dynamic-line-spanner-bug.png]
>
> If you start a new DynamicLineSpanner like
>
> c'1\!
> \stopStaff
> \startStaff
> c'1\<
>
> it will be properly spaced. It's probably not the only spanner
> unprepared to span pieces of interrupted staff symbols.
>
Isn't this still a bug? Or, rather a gap in system functionality for which
no workaround exists?
Starting a new DynamicLineSpanner creates two separate hairpins:
%%% BEGIN %%%
\version "2.19.82"
\new Staff
{
\override DynamicLineSpanner.staff-padding = 10
c'1
\p
\<
c'1
c'1
\break
c'1
\!
\stopStaff
\startStaff
c'1
\<
c'1
\break
c'1
c'1
c'1
\break
c'1
c'1
c'1
\f
}
\paper
{
indent = 0
ragged-right = ##t
system-system-spacing.minimum-distance = 30
}
%%% END %%%
[image: two-hairpins-instead-of-one.png]
... when what's needed is one single hairpin that governs the music of all
four systems.
Or am I missing something, and there is a way to generate a single
multisystem hairpin that governs all four systems?
Trevor.
--
Trevor Bača
www.trevorbaca.com
soundcloud.com/trevorbaca
___
lilypond-user mailing list
lilypond-user@gnu.org
https://lists.gnu.org/mailman/listinfo/lilypond-user
Re: Character encoding / poor man's letterspacing
Am 11.03.19 um 20:22 schrieb Aaron Hill:
On 2019-03-11 11:30 am, David Kastrup wrote:
Urs Liska writes:
Hi,
I've written a poor-man's implementation of a simple \letterspaced
markup command:
#(define-markup-command
(letterspaced layout props text)(markup?)
(let*
((chars (string->list text))
(dummy (ly:message "Chars: ~a" chars))
(spaced-text
(string-join
(map string chars) " ")))
(interpret-markup layout props
(markup spaced-text
However, this scrambles umlauts and presumably other UTF-8 characters
as you can see with
{
s1 ^\markup \letterspaced "Täst"
}
=>Chars: (T � � s t)
Obviously the characters are wrongly en/decoded along the way, which
makes me think whether I have simply forgotten an encoding setting
somewhere (although I have no idea where and how I should include
that) or whether that whole routine is totally clumsy.
Any pointer would be appreciated.
Guile-1.8 has only byte strings, not Unicode character strings.
However, the regexp procedures are locale aware, so you can use
something like
/./ isn't smart enough to match Unicode graphemes. You would need
/\X/, however that is not supported in POSIX ERE. Neither is the
approximation /\P{M}\p{M}*+/.
I can confirm that the suggestion doesn't work for me, even with the
given example. It's still "T s t" (see attached).
Urs
-- Aaron Hill
___
lilypond-user mailing list
lilypond-user@gnu.org
https://lists.gnu.org/mailman/listinfo/lilypond-user
___
lilypond-user mailing list
lilypond-user@gnu.org
https://lists.gnu.org/mailman/listinfo/lilypond-user
Re: Character encoding / poor man's letterspacing
Urs Liska writes:
> Am 11.03.19 um 20:22 schrieb Aaron Hill:
>> On 2019-03-11 11:30 am, David Kastrup wrote:
>>> Urs Liska writes:
>>>
Hi,
I've written a poor-man's implementation of a simple \letterspaced
markup command:
#(define-markup-command
(letterspaced layout props text)(markup?)
(let*
((chars (string->list text))
(dummy (ly:message "Chars: ~a" chars))
(spaced-text
(string-join
(map string chars) " ")))
(interpret-markup layout props
(markup spaced-text
However, this scrambles umlauts and presumably other UTF-8 characters
as you can see with
{
s1 ^\markup \letterspaced "Täst"
}
=>Chars: (T � � s t)
Obviously the characters are wrongly en/decoded along the way, which
makes me think whether I have simply forgotten an encoding setting
somewhere (although I have no idea where and how I should include
that) or whether that whole routine is totally clumsy.
Any pointer would be appreciated.
>>>
>>> Guile-1.8 has only byte strings, not Unicode character strings.
>>> However, the regexp procedures are locale aware, so you can use
>>> something like
>>
>> /./ isn't smart enough to match Unicode graphemes. You would need
>> /\X/, however that is not supported in POSIX ERE. Neither is the
>> approximation /\P{M}\p{M}*+/.
>
>
> I can confirm that the suggestion doesn't work for me, even with the
> given example. It's still "T s t" (see attached).
Do you have an UTF-8 locale set?
--
David Kastrup
___
lilypond-user mailing list
lilypond-user@gnu.org
https://lists.gnu.org/mailman/listinfo/lilypond-user
Re: Flared hairpin across line break
Am Mo., 11. März 2019 um 05:52 Uhr schrieb Andrew Bernard
:
>
> I'd like to have flared hairpins that only flare at the terminating end after
> a line break.
>
> The following example shows that using the flared hairpin stencil in a simple
> minded way causes it to flare at the first break, which I want to not have.
>
> Is there some magic that can be done with alter-broken?
>
> Andrew
>
> %==
> \version "2.19.82"
>
> {
> \time 2/4
> c''2
> \once \override Hairpin.stencil = #flared-hairpin
> c''\<
> \break
> c''2 c''\!
> }
>
> %==
Hi Andrew,
using alterBroken leads to
{
\alterBroken stencil
#(list
ly:hairpin::print
ly:hairpin::print
(elbowed-hairpin '((0 . 0.) (0.95 . 0.4) (1.0 . 1.0)) #t))
Hairpin
c'1\< \break c' \break s c'\!
}
Note the 0. value. A continued Hairpin starts with 1/3 height.
alterBroken has some (documented) inconveniences, though ...
Cheers,
Harm
___
lilypond-user mailing list
lilypond-user@gnu.org
https://lists.gnu.org/mailman/listinfo/lilypond-user
Re: Flared hairpin across line break
Hello Harm. Again, really excellent. Does exactly what I need. Very much appreciated. I think that would be a good example of how to do something significant with hairpins (I can't be the only one wanting this notation) and how to use alter-broken in a rather sophisticated way for the LSR. Andrew ___ lilypond-user mailing list lilypond-user@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-user
Re: Bug: restarting staff destroys DynamicLineSpanner.staff-padding after line break
Am Mo., 11. März 2019 um 23:01 Uhr schrieb Trevor Bača :
>
> On Thu, Mar 7, 2019 at 2:14 AM David Kastrup wrote:
> > It's probably not the only spanner
> > unprepared to span pieces of interrupted staff symbols.
> >
>
> Isn't this still a bug?
In the sense David pointed out.
> Or, rather a gap in system functionality for which
> no workaround exists?
Here an attempt for a workaround.
It's not tested beyond the given example, up to you ;)
\new Staff {
\override DynamicLineSpanner.after-line-breaking =
#(lambda (grob)
(let* ((staffs
(filter
(lambda (e) (grob::has-interface e 'staff-symbol-interface))
(ly:grob-array->list
(ly:grob-object (ly:grob-parent grob Y) 'elements)
(for-each
(lambda (staff) (set! (ly:grob-object grob 'staff-symbol) staff))
staffs)
;(format #t"\nstaff-padding: ~a\nY-offset: ~a\nstaff-symbol ~a\n"
; (ly:grob-property grob 'staff-padding)
; (ly:grob-property grob 'Y-offset)
; (ly:grob-object grob 'staff-symbol))
))
\override DynamicLineSpanner.staff-padding = 10
c'1\p\< c'1 c'1
\break
c'1 \stopStaff \startStaff c'1 c'1
\break
c'1 c'1 c'1
\break
c'1 c'1 c'1\f
}
\paper {
indent = 0
ragged-right = ##t
}
Cheers,
Harm
___
lilypond-user mailing list
lilypond-user@gnu.org
https://lists.gnu.org/mailman/listinfo/lilypond-user
Re: Character encoding / poor man's letterspacing
On 2019-03-11 3:40 pm, David Kastrup wrote:
Urs Liska writes:
Am 11.03.19 um 20:22 schrieb Aaron Hill:
On 2019-03-11 11:30 am, David Kastrup wrote:
Urs Liska writes:
Hi,
I've written a poor-man's implementation of a simple \letterspaced
markup command:
#(define-markup-command
(letterspaced layout props text)(markup?)
(let*
((chars (string->list text))
(dummy (ly:message "Chars: ~a" chars))
(spaced-text
(string-join
(map string chars) " ")))
(interpret-markup layout props
(markup spaced-text
However, this scrambles umlauts and presumably other UTF-8
characters
as you can see with
{
s1 ^\markup \letterspaced "Täst"
}
=>Chars: (T � � s t)
Obviously the characters are wrongly en/decoded along the way,
which
makes me think whether I have simply forgotten an encoding setting
somewhere (although I have no idea where and how I should include
that) or whether that whole routine is totally clumsy.
Any pointer would be appreciated.
Guile-1.8 has only byte strings, not Unicode character strings.
However, the regexp procedures are locale aware, so you can use
something like
/./ isn't smart enough to match Unicode graphemes. You would need
/\X/, however that is not supported in POSIX ERE. Neither is the
approximation /\P{M}\p{M}*+/.
I can confirm that the suggestion doesn't work for me, even with the
given example. It's still "T s t" (see attached).
Do you have an UTF-8 locale set?
That's because the file you attached was not in UTF-8. I was able to
open it using ISO 8859-1. In UTF-8, the 0xe4 for ä becomes U+FFFD
(Replacement Character). It should have been encoded as 0xc3 0xa4.
Either fixing the encoding or just retyping the umlaut A results in a
successful result.
Also, I should have been clear before. David's code should work for
most cases. I was just being pedantic that /./ would not work if the
input has combining characters. For instance, if you type U+0308
(Combining Diaeresis) after an 'a', you'll get an ä. But the simple
regex would not treat that as a single grapheme. The result would be "T
a ̈ s t".
-- Aaron Hill
___
lilypond-user mailing list
lilypond-user@gnu.org
https://lists.gnu.org/mailman/listinfo/lilypond-user
