Re: Gould question

2016-07-21 Thread Simon Albrecht 

On 12.07.2016 10:16, David Kastrup wrote:

Simon Albrecht  writes:


On 11.07.2016 22:33, Carl Sorensen wrote:

On 7/11/16 7:54 AM, "Simon Albrecht"  wrote:

Hello,

what do the authorities say on beaming something like this:

%%
\version "2.19.45"
{
\time 2/2
\repeat unfold 4 { \tuplet 6/4 { c16 e g c' g e } }
}
%%

Currently, it¹s beamed by half-measure, which I think impairs
legibility, so I introduced a patch changing this to beaming by quarter
note value (issue 4919).

The authorities say to beam by the beat, which is the half measure.  I
think that's why the default is what it is.

However, somewhere one has to draw the line – it’s certainly not an
option to have 16 32nd notes beamed together (unless subdivided).

In 2/2 splitting up the beams sub-beat is just wrong.  Now we have the
"unless subdivided" moniker here and LilyPond should likely do more in
_that_ respect.  In particular when beaming over several tuplet groups,
a subdivision corresponding to the number-carrying groups seems pretty
much mandatory to me irrespective of whether one uses binary subdivision
schemes (which I often find overdoing it) elsewhere.


And I’d draw it just below 16th notes.

For subdivision, yes.  But splitting beams completely inside of a beat
does not make sense automatically since we are then talking about a
judicious breach of rules, and that really should be done manually.


Now the patch is on countdown (again) and I have to return to this argument.
It’s probably a rare case that we’re talking about; 2/2 and 3/2 measures 
don’t often contain notes smaller than a 16th. But if they do, beaming 
all of them together without subdivision makes the rhythm very difficult 
to grasp. Plus, as Urs argued, the number of beams retained at a 
subdivision should correspond to the duration of the subdivided group, 
which in this case would mean zero beams.
So after all I still consider this a sensible change, regardless of the 
general rule of beaming by beat („Ausnahmen bestätigen die Regel“ – 
‘exceptions confirm the rule’ :-) ).
And now, after writing these elaborations, I notice that the question is 
quite outside the scope of this issue: The previous code already beamed 
32nd notes by quarter note instead of by beat. Tuplets may not even have 
been considered when that beaming exception was introduced, and in fact 
I just lowered the threshold a bit instead of creating it in the first 
place. So I would like to not take the patch out of countdown again.


Best, Simon

___
lilypond-user mailing list
lilypond-user@gnu.org
https://lists.gnu.org/mailman/listinfo/lilypond-user

Re: Problem coloring Ambitus ledger-lines

2016-07-21 Thread tisimst 
On Thu, Jul 21, 2016 at 10:33 AM, Patrick Karl-3 [via Lilypond] <
ml-node+s1069038n19293...@n5.nabble.com> wrote:

> When I use this technique in the following snippet:
>
> > \version "2.19.38"
> >
> > S =  \relative g' {
> > \key g\major
> > \once \override Staff.LedgerLineSpanner.color = #red
> > \grace s128 \stopStaff \startStaff
> > c4 e c' c % 1
> > }
> >
> > PRh =  \relative c'' {
> > \key g\major
> >  \grace s128
> >  g4 g g g% 1
> > }
> >
> > \score {  <<
> > \new StaffGroup  <<
> > \new Staff \with { \consists Ambitus_engraver }  \S
> > >>
> > \new PianoStaff  <<
> > \set PianoStaff.instrumentName = #"Piano"
> > \new Staff \PRh
> > >>
> >   >>
> > \layout {}
> > }
> >
> I get the attached output, which is lovely in all respects but one: the
> PianoStaff instrument name is missing.  The only way I have found to
> remedy this problem is to remove both lines containing "\grace s128",
> but, of course, then all of the ledger lines are colored red, not just
> those in the ambitus.
>
> How to fix?
>

Move the instrumentName definition to a \with block, like:

\new PianoStaff \with {
instrumentName = #"Piano"
} <<
\new Staff \PRh
>>

HTH,
Abraham




--
View this message in context: 
http://lilypond.1069038.n5.nabble.com/Problem-coloring-Ambitus-ledger-lines-tp192441p192933.html
Sent from the User mailing list archive at Nabble.com.___
lilypond-user mailing list
lilypond-user@gnu.org
https://lists.gnu.org/mailman/listinfo/lilypond-user

Re: Problem coloring Ambitus ledger-lines

2016-07-21 Thread Patrick Karl 

On 7/9/16 9:51 AM, Thomas Morley wrote:

2016-07-09 16:22 GMT+02:00 Patrick Karl :

The following MWE:

\version "2.19.38"

music =  { c'4 c''' r2 }

\score {
 \new Staff \music
 \layout {
\context { \Staff \consists "Ambitus_engraver"
\with { \override AmbitusNoteHead.color = #red
   \override AmbitusLine.color = #red
% \override LedgerLineSpanner.color = #red
}
}
 }
}

seems to illustrate a problem with Ambitus, namely, there doesn't seem to be
a way to change the color of ledger lines within the Ambitus.  The output of
the above snippet is attached; it shows the Ambitus ledger lines as black.
Uncommenting the "\override LedgerLineSpanner.color = #red" statement
changes the color of not only the ledger lines within the score, but also
within the Ambitus.

It looks like there should be a grob, AmbitusLedgerLineSpanner, independent
from LedgerLineSpanner.

We have the start/stopStaff-functionality to insert changes for p.e.
StaffSymbol and LedgerLineSpanner,.


Or am I overlooking something?

How about:

music =  {
   \once \override Staff.LedgerLineSpanner.color = #red
   \grace s128
   \stopStaff
   \startStaff
   c'4 c''' r2
}

\score {
 \new Staff \music
 \layout {
\context {
  \Staff
  \consists "Ambitus_engraver"
  \override AmbitusNoteHead.color = #red
  \override AmbitusLine.color = #red
}
 }
}

When I use this technique in the following snippet:


\version "2.19.38"

S =  \relative g' {
\key g\major
\once \override Staff.LedgerLineSpanner.color = #red
\grace s128 \stopStaff \startStaff
c4 e c' c % 1
}

PRh =  \relative c'' {
\key g\major
 \grace s128
 g4 g g g% 1
}

\score {  <<
\new StaffGroup  <<
\new Staff \with { \consists Ambitus_engraver }  \S
>>
\new PianoStaff  <<
\set PianoStaff.instrumentName = #"Piano"
\new Staff \PRh
>>
  >>
\layout {}
}

I get the attached output, which is lovely in all respects but one: the 
PianoStaff instrument name is missing.  The only way I have found to 
remedy this problem is to remove both lines containing "\grace s128", 
but, of course, then all of the ledger lines are colored red, not just 
those in the ambitus.


How to fix?

Thanks,
Pat



___
lilypond-user mailing list
lilypond-user@gnu.org
https://lists.gnu.org/mailman/listinfo/lilypond-user

Re: Laissez viber ties dotted

2016-07-21 Thread Simon Albrecht 

On 21.07.2016 13:12, Trevor Daniels wrote:

Andrew Bernard wrote Thursday, July 21, 2016 10:55 AM

On 21 July 2016 at 3:19:49 PM, Malte Meyn  wrote:

laissezVibrerTieDotted = \override LaissezVibrerTie.dash-definition =
#'((0 1 0.1 0.75))

Is it only me that finds the IR inadequate? There appears to be no mention
of being able to do this for LaissezVibrer ties in the IR. For Tie grobs, this
is mentioned in the tie interface page, but there is nothing about this property
in the semi-tie interface reference page. Are we supposed to just guess?

You have identified a defect in the Internals documentation.  This manual is
produced automatically from the source code to ensure it stays in step with
code changes, but in this case (and for PhrasingSlur)  it does not
reference tie-interface where dash-definition is defined.


That seems to me rather unreliable. Woudl it be reasonable to raise
somehwere a request for enhancement for the documentation?




Best, Simon

___
lilypond-user mailing list
lilypond-user@gnu.org
https://lists.gnu.org/mailman/listinfo/lilypond-user

Re: Hyphenating words in lyrics across long repeats and across multiple pitches

2016-07-21 Thread Simon Albrecht 

On 21.07.2016 12:16, Mojca Miklavec wrote:

So I guess that what you wrote me is because "Tra" would normally be
centred on the musical note, but now that a hyphen is considered to be
part of it, it gets wider, so the function shifts the note relative to
lyrics for 0.4 units to the left to compensate.


That’s not quite how it works. self-alignment-X sets the reference point 
for alignment. 0 means the center of the grob’s visible extent, -1 left 
edge, 1 right edge, and you can choose any other value which will be 
placed on that scale.




Another problem are cases which I would intuitively write
  tra -- _ -- la

where the first syllable "tra" would be sung across two pitches.

Simple: just omit the second hyphen. Hyphens will be extended to span the
whole distance until the next actual syllable comes. Same with extenders.

Great, thank you.

Could this be added to documentation, for example somewhere like

http://lilypond.org/doc/v2.19/Documentation/learning/aligning-lyrics-to-a-melody
http://lilypond.org/doc/v2.19/Documentation/notation/techniques-specific-to-lyrics

It really took me quite some time to figure out how to:
- hyphenate world (my initial attempt was a single '-' and perhaps
even without spaces)
- create an extended underline
- skip notes (my initial attempt was an empty string: "")
- create a "syllable" that contains space
- the two problems mentioned above


Most of these are in fact discussed in the LM section, e.g. stating ‘As 
an alternative to using slurs, the melismata may be indicated in just 
the lyrics by using an underscore |_| for each note that should be 
included in the melisma’.


HTH, Simon

___
lilypond-user mailing list
lilypond-user@gnu.org
https://lists.gnu.org/mailman/listinfo/lilypond-user

Re: Laissez viber ties dotted

2016-07-21 Thread Trevor Daniels 

Andrew Bernard wrote Thursday, July 21, 2016 10:55 AM

> On 21 July 2016 at 3:19:49 PM, Malte Meyn  wrote:
>>
>> laissezVibrerTieDotted = \override LaissezVibrerTie.dash-definition = 
>> #'((0 1 0.1 0.75)) 

> Is it only me that finds the IR inadequate? There appears to be no mention 
> of being able to do this for LaissezVibrer ties in the IR. For Tie grobs, 
> this 
> is mentioned in the tie interface page, but there is nothing about this 
> property 
> in the semi-tie interface reference page. Are we supposed to just guess? 

You have identified a defect in the Internals documentation.  This manual is
produced automatically from the source code to ensure it stays in step with
code changes, but in this case (and for PhrasingSlur)  it does not
reference tie-interface where dash-definition is defined.

> That seems to me rather unreliable. Woudl it be reasonable to raise 
> somehwere a request for enhancement for the documentation?

Yes; copying to Buglist.

> Andrew
___
lilypond-user mailing list
lilypond-user@gnu.org
https://lists.gnu.org/mailman/listinfo/lilypond-user

Re: Hyphenating words in lyrics across long repeats and across multiple pitches

2016-07-21 Thread Mojca Miklavec 
On 21 July 2016 at 11:29, Simon Albrecht wrote:
> On 21.07.2016 03:39, Mojca Miklavec wrote:
>>
>> When I try to start a syllable that continues after the repeat, I have
>> a problem.
>>
>> Lilypond complains loudly:
>>  repeats.ly:24:38: warning: unterminated hyphen; removing
>>
>> Below an example that should read
>> Oh, tralalala! Tralalali!
>>
>> (Of course the hyphen would "kind of" work if I add "li!" at the end –
>> it would pretend as if the word was "Tra -- li" and would place the
>> hyphen to the wrong place.)
>>
>> What's the best recipe to fix such cases?
>
>
> You have to revert to some kind of tricks; in this case, using "Tra -",
> which has the disadvantage of taking the hyphen from the font instead of
> Lily’s engraver tool, so it will probably look slightly different.

Yes, I tried using "Tra-" and noticed that the typesetting was
different (coming from TeX this seems unacceptable :) :) :) :)

OK, I don't mean that seriously. But if this is not easy to handle,
I'm fine with whatever is available and a differently typeset hyphen
is ok.

> See attached.

Thank you.

So I guess that what you wrote me is because "Tra" would normally be
centred on the musical note, but now that a hyphen is considered to be
part of it, it gets wider, so the function shifts the note relative to
lyrics for 0.4 units to the left to compensate.

I cannot decide whether it's more ugly to keep that source code or to
keep a slightly non-central position of the text. I guess it's more
tough to tolerate the ugly source code (plus, if I change the font, I
would have to fix the setting again). But I really like learning a new
trick.

>> Another problem are cases which I would intuitively write
>>  tra -- _ -- la
>>
>> where the first syllable "tra" would be sung across two pitches.
>
> Simple: just omit the second hyphen. Hyphens will be extended to span the
> whole distance until the next actual syllable comes. Same with extenders.

Great, thank you.

Could this be added to documentation, for example somewhere like

http://lilypond.org/doc/v2.19/Documentation/learning/aligning-lyrics-to-a-melody
http://lilypond.org/doc/v2.19/Documentation/notation/techniques-specific-to-lyrics

It really took me quite some time to figure out how to:
- hyphenate world (my initial attempt was a single '-' and perhaps
even without spaces)
- create an extended underline
- skip notes (my initial attempt was an empty string: "")
- create a "syllable" that contains space
- the two problems mentioned above

A zillion advanced techniques are discussed about how to do tricks
with both horizontal and vertical alignment, but some of the above
very simple techniques could probably be explained in a few words even
in the initial tutorial.

Thank you,
Mojca

___
lilypond-user mailing list
lilypond-user@gnu.org
https://lists.gnu.org/mailman/listinfo/lilypond-user

Re: \caps with Umlaut

2016-07-21 Thread Johan Vromans 
On Thu, 21 Jul 2016 11:19:16 +0200
Simon Albrecht  wrote:

> Or even, as the docs suggest, a font where you can change font-shape to 
> small caps.

Again, smallcaps is totally different from caps. The fact that a smallcaps
A with umlaut has long been used instead of a real Ä is just like
using minute signs '..' instead of quotes ‘..’. It once was better than what
we had, but it is plain stupid now.


___
lilypond-user mailing list
lilypond-user@gnu.org
https://lists.gnu.org/mailman/listinfo/lilypond-user

Re: \caps with Umlaut

2016-07-21 Thread Johan Vromans 
On Thu, 21 Jul 2016 11:18:22 +0200
Simon Albrecht  wrote:

> The issue is that caps and smallCaps are exactly the same to LilyPond, 
> which is in itself nonsense.

Exactly.

___
lilypond-user mailing list
lilypond-user@gnu.org
https://lists.gnu.org/mailman/listinfo/lilypond-user

Re: Laissez viber ties dotted

2016-07-21 Thread Andrew Bernard 
HI Malte,

Thanks very much for this. Just perfect.

Is it only me that finds the IR inadequate? There appears to be no mention
of being able to do this for LaissezVibrer ties in the IR. For Tie grobs,
this is mentioned in the tie interface page, but there is nothing about
this property in the semi-tie interface reference page. Are we supposed to
just guess? That seems to me rather unreliable. Woudl it be reasonable to
raise somehwere a request for enhancement for the documentation? {iunless
of course I have just missed it entirely by looking in the wrong places.]

Andrew

On 21 July 2016 at 3:19:49 PM, Malte Meyn  wrote:


laissezVibrerTieDotted = \override LaissezVibrerTie.dash-definition =
#'((0 1 0.1 0.75))
___
lilypond-user mailing list
lilypond-user@gnu.org
https://lists.gnu.org/mailman/listinfo/lilypond-user

Re: \caps with Umlaut

2016-07-21 Thread Simon Albrecht 



On 21.07.2016 00:47, Simon Albrecht wrote:

On 20.07.2016 23:01, Jonathan Scholbach wrote:

\version "2.19.22"

\markup{ \caps Bartholomäus }

How can I solve this problem? I mean, how can I achieve that \caps works
properly with umlauts and uses the uppercase umlaut?


In the long run, your best bet is to use a special small caps font.


Or even, as the docs suggest, a font where you can change font-shape to 
small caps.


Unfortunately, it’s not easy to find a good, free text font with 
matching small caps… Personally, I like Alegreya, but I know it’s 
quite unusual.


Best, Simon

___
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: \caps with Umlaut

2016-07-21 Thread Simon Albrecht 

On 21.07.2016 10:34, Johan Vromans wrote:

On Wed, 20 Jul 2016 23:01:49 +0200
Jonathan Scholbach  wrote:


And that was
when I found out, that \caps, as well as \smallCaps, "does not support
accented character" (quoted from
http://lilypond.org/doc/v2.19/Documentation/notation/font) - the ä - is
printed as a lowercase letter.

Any decent font nowadays has upcase versions for accented glyphs. It's
about time the \caps handling gets updated to the 21st century.

BTW forget about the \smallCaps, that's a distinct issue.


The issue is that caps and smallCaps are exactly the same to LilyPond, 
which is in itself nonsense. caps is a copy of smallCaps.


Best, Simon

___
lilypond-user mailing list
lilypond-user@gnu.org
https://lists.gnu.org/mailman/listinfo/lilypond-user

Re: Hyphenating words in lyrics across long repeats and across multiple pitches

2016-07-21 Thread Simon Albrecht 

On 21.07.2016 03:39, Mojca Miklavec wrote:

When I try to start a syllable that continues after the repeat, I have
a problem.

Lilypond complains loudly:
 repeats.ly:24:38: warning: unterminated hyphen; removing

Below an example that should read
Oh, tralalala! Tralalali!

(Of course the hyphen would "kind of" work if I add "li!" at the end –
it would pretend as if the word was "Tra -- li" and would place the
hyphen to the wrong place.)

What's the best recipe to fix such cases?


You have to revert to some kind of tricks; in this case, using "Tra -", 
which has the disadvantage of taking the hyphen from the font instead of 
Lily’s engraver tool, so it will probably look slightly different. See 
attached.



Another problem are cases which I would intuitively write
 tra -- _ -- la

where the first syllable "tra" would be sung across two pitches.


Simple: just omit the second hyphen. Hyphens will be extended to span 
the whole distance until the next actual syllable comes. Same with 
extenders.


Best, Simon
\version "2.19.30"

selfAl = #(define-music-function (num) (number?)
(once (propertyOverride '(LyricText self-alignment-X) num)))

\new PianoStaff <<
  \new Voice = "melody" \fixed c' {
\autoBeamOff
\time 2/4
a2 | a2 |
\repeat volta 2 {
  a4 a4 |
}
\alternative {
  { a4 a4 |}
  { a4 cis'8[ e'] | }
}
a'2
\bar "|."
  }
  % the last hyphen after 'Tra" is problematic and gets removed
  \context Lyrics = "lyrics" {
\lyricsto "melody" {
  Oh, tra -- la -- la -- la! \selfAl #-0.4 "Tra -"
  li! __ _ _
}
  }
>>
___
lilypond-user mailing list
lilypond-user@gnu.org
https://lists.gnu.org/mailman/listinfo/lilypond-user

Re: \caps with Umlaut

2016-07-21 Thread Johan Vromans 
On Wed, 20 Jul 2016 23:01:49 +0200
Jonathan Scholbach  wrote:

> And that was
> when I found out, that \caps, as well as \smallCaps, "does not support
> accented character" (quoted from
> http://lilypond.org/doc/v2.19/Documentation/notation/font) - the ä - is
> printed as a lowercase letter.

Any decent font nowadays has upcase versions for accented glyphs. It's
about time the \caps handling gets updated to the 21st century.

BTW forget about the \smallCaps, that's a distinct issue.

___
lilypond-user mailing list
lilypond-user@gnu.org
https://lists.gnu.org/mailman/listinfo/lilypond-user

Re: \caps with Umlaut

2016-07-21 Thread Pierre Perol-Schneider 
Hi Jonathan,

As a workaround you can use :

\version "2.19.22"

\markup\concat{ B \fontsize #-2 ARTHOLOMÄUS }

However, in the past I used a fairly old code, slightly adapted here :

 \version "2.19.45"

%% original code by N. Sceaux
#(use-modules (ice-9 regex))
#(define-public string-upper-case #f)
#(define accented-char-upper-case? #f)
#(define accented-char-lower-case? #f)
#(let ((lower-case-accented-string
"áàâäǎăāãåąæǣćĉčçďđðéèêëěĕēęəĝğģĥħíìîïǐĭīĩįĵķĺŀľļłńňñóòôöǒŏōõǫőøœŕřśŝšşťţþúùûüǔŭūųǘǜǚŵýŷÿȳźž")

   (upper-case-accented-string
"ÁÀÂÄǍĂĀÃÅĄÆǢĆĈČÇĎĐÐÉÈÊËĚĔĒĘƏĜĞĢĤĦÍÌÎÏǏĬĪĨĮĴĶĹĿĽĻŁŃŇÑÓÒÔÖǑŎŌÕǪŐØŒŔŘŚŜŠŞŤŢÞÚÙÛÜǓŬŪŲǗǛǙŴÝŶŸȲŹŽ"))

   (define (group-by-2 chars result)
  (if (or (null? chars) (null? (cdr chars)))
  (reverse! result)
  (group-by-2 (cddr chars)
  (cons (string (car chars) (cadr chars))
result
   (let ((lower-case-accented-chars
  (group-by-2 (string->list lower-case-accented-string) (list)))
 (upper-case-accented-chars
  (group-by-2 (string->list upper-case-accented-string) (list
 (set! string-upper-case
   (lambda (str)
 (define (replace-chars str froms tos)
   (if (null? froms)
   str
   (replace-chars (regexp-substitute/global #f (car froms)
str
'pre (car tos)
'post)
  (cdr froms)
  (cdr tos
 (string-upcase (replace-chars str
   lower-case-accented-chars
   upper-case-accented-chars
 (set! accented-char-upper-case?
   (lambda (char1 char2)
 (member (string char1 char2) upper-case-accented-chars
string=?)))
 (set! accented-char-lower-case?
   (lambda (char1 char2)
 (member (string char1 char2) lower-case-accented-chars
string=?)
#(define-markup-command (caps layout props text) (markup?)
  (define (string-list->markup strings lower)
(let ((final-string (string-upper-case
 (apply string-append (reverse strings)
  (if lower
  (markup #:fontsize -2 final-string)
  final-string)))
  (define (make-small-caps rest-chars currents current-is-lower
prev-result)
(if (null? rest-chars)
(make-concat-markup (reverse! (cons (string-list->markup
  currents current-is-lower)
prev-result)))
(let* ((ch1 (car rest-chars))
   (ch2 (and (not (null? (cdr rest-chars))) (cadr rest-chars)))
   (this-char-string (string ch1))
   (is-lower (char-lower-case? ch1))
   (next-rest-chars (cdr rest-chars)))
  (cond ((and ch2 (accented-char-lower-case? ch1 ch2))
 (set! this-char-string (string ch1 ch2))
 (set! is-lower #t)
 (set! next-rest-chars (cddr rest-chars)))
((and ch2 (accented-char-upper-case? ch1 ch2))
 (set! this-char-string (string ch1 ch2))
 (set! is-lower #f)
 (set! next-rest-chars (cddr rest-chars
  (if (or (and current-is-lower is-lower)
  (and (not current-is-lower) (not is-lower)))
  (make-small-caps next-rest-chars
   (cons this-char-string currents)
   is-lower
   prev-result)
  (make-small-caps next-rest-chars
   (list this-char-string)
   is-lower
   (if (null? currents)
   prev-result
   (cons (string-list->markup
currents current-is-lower)
 prev-result)))
  (interpret-markup layout props
(if (string? text)
(make-small-caps (string->list text) (list) #f (list))
text)))

%%Tests:
\markup \caps "A a Á á À à Â â Ä ä Ǎ ǎ Ă ă Ā ā Ã ã Å å Ą ą Æ æ Ǣ ǣ"
\markup \caps "B b"
\markup \caps "C c Ć ć Ĉ ĉ Č č Ç ç"
\markup \caps "D d Ď ď Đ đ Ð ð"
\markup \caps "E e É é È è Ê ê Ë ë Ě ě Ĕ ĕ Ē ē Ę ę Ə ə"
\markup \caps "F f"
\markup \caps "G g Ĝ ĝ Ğ ğ Ģ ģ"
\markup \caps "H h Ĥ ĥ Ħ ħ"
\markup \caps "I i Í í Ì ì Î î Ï ï Ǐ ǐ Ĭ ĭ Ī ī Ĩ ĩ Į į"
\markup \caps "J j Ĵ ĵ"
\markup \caps "K k Ķ ķ"
\markup \caps "L l Ĺ ĺ Ŀ ŀ Ľ ľ Ł ł"
\markup \caps "M m"
\markup \caps "N n Ń ń Ň ň Ñ ñ"
\markup \caps "O o Ó ó Ò ò Ô ô Ö ö Ǒ ǒ Ŏ ŏ Ō ō Õ õ Ǫ ǫ Ő ő Ø ø Œ œ"
\markup \caps "P p"
\markup \caps "Q q"
\markup \caps "R r Ŕ ŕ Ř ř"
\markup \caps "S s Ś ś Ŝ ŝ Š š Ş ş ß"
\markup \caps "T t Ť ť Ţ ţ Þ þ"
\markup \caps "U u Ú ú Ù ù Û û Ü ü Ǔ ǔ Ŭ ŭ Ū ū Ų ų Ǘ ǘ Ǜ ǜ Ǚ ǚ"
\markup \caps "V v"
\markup \caps "W w Ŵ