lilypond-user
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: Double-underline markup


From: Thomas Morley
Subject: Re: Double-underline markup
Date: Sat, 19 Oct 2019 11:56:58 +0200

Am Sa., 19. Okt. 2019 um 05:22 Uhr schrieb Andrew Bernard
<address@hidden>:
>
> I have not seen anything get added to lilypond proper for a long time.
> I may be wrong, but it's immensely difficult to get changes to core it would 
> seem. Fair enough too. That's why openlilylib exists.

Nothing against openlilyib or the LSR.

Though:
$ git log --oneline --since=1.9.2019
8ba40d3d69 (HEAD -> master, origin/staging, origin/master,
origin/HEAD) Issue 5571: streamline cat | sed | sed
75b16466ef Issue 5564: fix conversion warnings in beaming code
2d45d5247e Drop requirement for python-devel
a6a6f019a9 Fix header variables from musicxml2ly on Windows
fa6c70e39a Issue 5567: allow slurs instead of brackets with tuplets
cd11e1d06e Update python headers to match surrounding files
b7532cf6e6 Issue 5568: make build output terse by default
5674d4570d NR: add snippet to describe `NoteCollision.prefer-dotted-right'
058c7347c1 granados.ly: Improved and updated.
c95d96aa71 Typo.
d9555cda14 Issue 5565: simplify python-related makefiles
2f1649830b Issue 5559/4: fix regression (ambitus with ottava)
6f319a862d Issue 5556/3: make OttavaBracket text default bold
608aa55988 Issue 5559/2: add regtest
476194c706 Issue 5559/1: Add user-definable ottava markups
7e6a956625 Issue 5561/5562: slurs work without NoteHead stencil
2c2908c905 Issue 5563: make edges of brackets dashable
09bc2e2ed7 Issue 5560: remove script-chart.ly
7930d8777e Issue 5558/2: NR: various minor corrections
3064ac9d3d Issue 5558/1: NR: add many index entries for snippets
1d255547ba Run scripts/auxiliar/makelsr.py
9bef63308f Issue 5557: Remove spurious '% begin verbatim' in
Documentation/snippets/new
71c4990e47 run-and-check: Display correct log file directory.
c2b424f9f8 Remove old make-countdown-announcement.sh
ab3b23941f Issue 5555/3: TimeScaledMusic should not be music-wrapper-music
eed07c3e54 Issue 5555/2: add_post_events: check for time-scaled-music explicitly
4402d6c545 Issue 5555/1: reorder checks in add_post_events for efficiency
0457814df4 string-tunings-init: Fix typo in Banjo tuning.
1d3105fce4 run-and-check: Show output directory in case of error.
a6f8381ea4 stockhausen-klavierstueckII: Completely rewritten.
be39d353b7 Rename `Stockhausen_Klavierstueck2' to `stockhausen-klavierstueckII'.
805e6ef94c bach-schenker.ly: Completely revised.
89036755a7 Replace code.google.com by SourceForge
e926c294e3 Issue 5553: fix handling of @lilypond[verbatim]
227fac3a04 We now need texinfo 6.1 or newer.
b2799c1823 Issue 5552/2: NR: complete revision of all index entries
714792a1eb Issue 5552/1: HOWTO.index: new guide for creating index entries
1eed54e8ff Issue 5551/2: improve generated documentation
2165edafc5 Issue 5551/1: better indexing support

is not exactly what I'd call nothing ;)

>
> But in fact, while I think this is neat code, I personally strongly 
> disapprove of underlining, single or double, being a dreary minded classical 
> typographer myself, and underlining is generally frowned upon anyway in fine 
> printing (maybe music is not fine printing?) So I would not actually want to 
> see this encouraged, even though I can see people have uses for it.

I don't understand your point.
\underline is a markup-command for text. I think every
text-typesetting-program has this functionality. Why should we
disencourage it?
Speaking only for myself I use underline pretty often in educational
typesettings and have used it in some serious contemporary
music-typesetting as well (composer's request).

Cheers,
  Harm



reply via email to

[Prev in Thread] Current Thread [Next in Thread]