bug-lilypond
[Top][All Lists]
Advanced

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

Re: Apparent error in NR section 1.8.1


From: Phil Holmes
Subject: Re: Apparent error in NR section 1.8.1
Date: Wed, 20 Jun 2012 17:24:32 +0100

"Philip Thomas" <address@hidden> wrote in message news:address@hidden
Hi there, Documentation Wardens,

There's seems to be an error in NR > section 1.8.1 > Text marks > Selected
Snippets > Aligning marks with various notation objects.

The first block of substantive input code in the example reads, in the PDF
version (page 203):

 % the RehearsalMark will be centered above the Clef
 \override Score.RehearsalMark #'break-align-symbols = #'(clef)
 \key a \major
 \clef treble
 \mark ""
 e1

The same block of code in the web version reads:

 % the RehearsalMark will be centered above the Clef
 \override Score.RehearsalMark #'break-align-symbols = #'(clef)
 \key a \major
 \clef treble
 \mark "↓"
 e1

There is a difference in the second last line of each, where a "↓" symbol
(= \char ##x2193) appears in the web version but nothing at all appears in
the PDF version. (I hope it appears in this email, too, or I will seem
pretty confusing myself!)

In the other blocks of input code in the same snippet, the corresponding
line always reads "\mark \markup { \char ##x2193 }", in both web and PDF
versions.

The compiled output appears to be shown as intended in both web and PDF
versions, despite the error in the PDF version of the input code.

Suggestion:

My suggestion would be to use "\mark \markup { \char ##x2193 }" in _all_
parts of the snippet in both web and PDF versions, so that people who copy
the input code but do not use UTF-8 coding will not get incorrect or
confusing results.

Alternatively, if there is a good reason for using the "↓" example in the
snippet, it should appear correctly in _both_ web and PDF versions, and its
use (as an alternative, provided that UTF-8 coding is being used, to using
\char ##x2193) should be explained.

Cheers, Philip Thomas

Think it's likely this is related to http://code.google.com/p/lilypond/issues/detail?id=2146. It's a snippet from the LSR - simplest thing may be to update the snippet to use the \char syntax. Anyone object if I do this?

--
Phil Holmes
Bug Squad




reply via email to

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