Re: List of Chordname attributs
2013/12/24 Helge Kruse > 2013/12/23 Johan Vromans > >> > This shows the modifier names. I was looking for that thingee that >> gives me >> > that small zero. >> >> That should be the "dim" > > > Yes, I found it as I already wrote. I just want to ask if it would be > possible to add the result of "C:dim" and all others chords to > http://www.lilypond.org/doc/v2.17/Documentation/notation/common-chord-modifiers > > Hi Helge I've added your request here: https://code.google.com/p/lilypond/issues/detail?id=3755 ___ bug-lilypond mailing list bug-lilypond@gnu.org https://lists.gnu.org/mailman/listinfo/bug-lilypond
Re: Issues with documentation not compiling when changing lilypond-texi2html.init
2013/12/9 Carl Peterson > On Mon, Dec 9, 2013 at 1:05 PM, David Kastrup wrote: > > > James writes: > > > > > Hello, > > > > > > On 09/12/13 14:03, Carl Peterson wrote: > > >> When trying to work the Documentation/lilypond-texi2html.init file, I > > have > > >> observed that changing this file does not trigger the documentation to > > >> rebuild when running make. However, > > >> changing Documentation/css/lilypond-manuals.css triggers the entire > > >> documentation to rebuild. This seems backwards, since > > >> lilypond-texi2html.init touches pretty much every part of the > > >> documentation, and the css file isn't actually involved in compiling > > >> anything. > > >> > > >> The command being run to make the documentation for the website is: > > >> > > >> make WEB_TARGETS="offline online" doc > > >> > > >> per > > >> > > > http://lilypond.org/doc/v2.17/Documentation/contributor/debugging-website-and-docs-locally > > > > > > Yes the doc build system does have its quirks - the website is built > > > by the same process as the PDFs. > > > > > > > > > http://lilypond.org/doc/v2.17/Documentation/contributor-big-page.html#building-documentation > > > > > > I cannot say if that is related to the website, but it is possible. > > > > I think the point was that the content of the css file is not relevant > > for creating any of the other files: the css is ultimately combined with > > the other files in the _browser_. So it seems nonsensical to declare it > > as a dependency for anything but those targets that copy the css file > > into a target directory. > > > > That's part of it. But the other part is that when I edit the > lilypond-texi2html.init file, it does not trigger any rebuilds when it > should force the entire documentation to rebuild. I have to touch one of > the manual files to get anything to happen, and then it only rebuilds that > manual. > > Hi Carl thanks for the report, I've just found the time to verify it and I've added an issue here: https://code.google.com/p/lilypond/issues/detail?id=3756 ___ bug-lilypond mailing list bug-lilypond@gnu.org https://lists.gnu.org/mailman/listinfo/bug-lilypond
Re: docs: #' no longer needed with \tag, \removeWithTag, \keepWithTag
On 26/12/13 07:51, David Kastrup wrote: James writes: Anyway, it is useful I think to mention this somehow in the documenation, but apart from numerals what other characters would break LP's syntax in this specific regard? Words are formed by letters and non-ASCII characters, with single hyphens or underlines allowed inside. So -wer--g-i-e--l- splits into - wer -- g-i-e -- l - Anything outside of the basic ASCII range behaves like a letter. So if I have this right (sorry to be so dull about this) you said: \tag #'violin1 but you cannot write \tag violin1 So could you write \tag violin-one or \tag violin£ or \tag violin" which as far as I can tell, are non-ASCII characters. James ___ bug-lilypond mailing list bug-lilypond@gnu.org https://lists.gnu.org/mailman/listinfo/bug-lilypond
Re: docs: #' no longer needed with \tag, \removeWithTag, \keepWithTag
James writes: > On 26/12/13 07:51, David Kastrup wrote: >> James writes: >> >>> Anyway, it is useful I think to mention this somehow in the >>> documenation, but apart from numerals what other characters would >>> break LP's syntax in this specific regard? >> Words are formed by letters and non-ASCII characters, with single >> hyphens or underlines allowed inside. >> >> So -wer--g-i-e--l- >> splits into - wer -- g-i-e -- l - >> >> Anything outside of the basic ASCII range behaves like a letter. >> > So if I have this right (sorry to be so dull about this) you said: > > \tag #'violin1 > > but you cannot write > > \tag violin1 > > > So could you write > > \tag violin-one > > or > > \tag violin£ On my first computer, a veritable Nascom II, I had £ instead of # as character 35 if I remember correctly. But you are right: in this time and day, it should work. > or > > \tag violin" > > which as far as I can tell, are non-ASCII characters. Yes, all of those should work as labels (or, following \, as the name part of, uh, a control sequence?). As would violin-I, violin①, violin② and a few others. -- David Kastrup ___ bug-lilypond mailing list bug-lilypond@gnu.org https://lists.gnu.org/mailman/listinfo/bug-lilypond
Re: docs: #' no longer needed with \tag, \removeWithTag, \keepWithTag
On 26/12/13 10:29, David Kastrup wrote: James writes: On 26/12/13 07:51, David Kastrup wrote: James writes: Anyway, it is useful I think to mention this somehow in the documenation, but apart from numerals what other characters would break LP's syntax in this specific regard? Words are formed by letters and non-ASCII characters, with single hyphens or underlines allowed inside. So -wer--g-i-e--l- splits into - wer -- g-i-e -- l - Anything outside of the basic ASCII range behaves like a letter. So if I have this right (sorry to be so dull about this) you said: \tag #'violin1 but you cannot write \tag violin1 So could you write \tag violin-one or \tag violin£ On my first computer, a veritable Nascom II, I had £ instead of # as character 35 if I remember correctly. But you are right: in this time and day, it should work. or \tag violin" which as far as I can tell, are non-ASCII characters. Yes, all of those should work as labels (or, following \, as the name part of, uh, a control sequence?). As would violin-I, violin①, violin② and a few others. Thanks, so looking at http://lilypond.org/doc/v2.17/Documentation/notation/different-editions-from-one-source#using-tags I wonder if we should now modify the example to use the 'new and improved' method of denoting the tag names as well as including the exceptions. James ___ bug-lilypond mailing list bug-lilypond@gnu.org https://lists.gnu.org/mailman/listinfo/bug-lilypond
Re: Bug in 2.17.97, acciaccatura causes blank staff lines.
2013/12/26 Keith OHara :
> Helge Hafting ntebb.no> writes:
>
>> \new PianoStaff
>> <<
>> \new Staff = "up" \relative a' {
>> a2 e2
>> \mark \default
>
> Due to issue 34, we need here: \grace s8
>
>> }
>> \new Staff = "down" \relative f' {
>> a2 e2
>> \acciaccatura e8 a1
>> }
>> >>
>
>
>> Orchestra has too many voices for this sort of workaround.
>
> That is true.
>
> There is a good concept for fixing the issue with grace timing, described
> in the issue tracker, but a great deal of care and patience is needed to
> rewrite the timing code without breaking things.
Though, it gives no warning with 2.14.2
2.14.2-output attached.
<>___
bug-lilypond mailing list
bug-lilypond@gnu.org
https://lists.gnu.org/mailman/listinfo/bug-lilypond
broken horizontal brackets don't clear prefatory material
In the following snippet, there is a collision between the broken analysis
bracket and the clef (see image):
\version "2.17.97"
{
c''1\startGroup
\break
c''1\stopGroup
}
\layout {
ragged-right = ##t
\context {
\Voice
\consists "Horizontal_bracket_engraver"
}
}
The collision is bad, but the problem here seems to me that the broken
analysis bracket ought to begin to the right of the prefatory material, as
other broken spanners do. If it's felt that starting the broken bracket
more to the right is the right approach, I've got the workings of a patch
which I can post to Rietveld.
--David
<>___
bug-lilypond mailing list
bug-lilypond@gnu.org
https://lists.gnu.org/mailman/listinfo/bug-lilypond
