Re: Issue 1495 in lilypond: mac line endings and line comment disaster
Comment #5 on issue 1495 by d...@gnu.org: mac line endings and line comment disaster http://code.google.com/p/lilypond/issues/detail?id=1495 Uh, that's sort of embarrassing. I have push access, and verified the fix pushed with commit cc043cb11f95f3d565df2ab791d5a571bb365cd5 given the example file. But I am not able to change the bug status. Anybody else care to at least close the bug? It has High Priority after all. ___ bug-lilypond mailing list bug-lilypond@gnu.org http://lists.gnu.org/mailman/listinfo/bug-lilypond
Re: alpha test, horizontal spacing
Jan Warchoł wrote Saturday, February 12, 2011 9:25 AM I agree too, but in my opinion it's a less important problem than the one marked in red in the attachment. (However, it was present in 2.12.3 too). The natural on c is perhaps moved because of the dot on f, but i don't think it should be moved this way. Agreed. Although two almost identical situations are typeset correctly in the same example, with the accidental sliding neatly over the dot. This must be a bug, so copying to Bug list for bug squad to process. Trevor attachment: why so much space.PNG___ bug-lilypond mailing list bug-lilypond@gnu.org http://lists.gnu.org/mailman/listinfo/bug-lilypond
Re: Issue 1495 in lilypond: mac line endings and line comment disaster
Updates: Status: Fixed Labels: fixed_2_13_49 Comment #6 on issue 1495 by philehol...@googlemail.com: mac line endings and line comment disaster http://code.google.com/p/lilypond/issues/detail?id=1495 Marking it fixed, as requested. ___ bug-lilypond mailing list bug-lilypond@gnu.org http://lists.gnu.org/mailman/listinfo/bug-lilypond
make translation-status fails
Hello everybody, Wishing to update the translations status before 2.14 jumps out, since its last update was in November 2010, I get this error, which I'm unable to deal with: make translation-status PYTHONPATH=/home/jcharles/GIT/Traduc/python:/home/jcharles/GIT/Traduc/python/auxiliar /usr/bin/python /home/jcharles/GIT/Traduc/scripts/auxiliar/translations-status.py translations-status.py Reading documents... Generating status pages... translations-status.py:717: warning: using markup = TexiMarkup (): ugly HTML output, questionable PDF and info output. Consider using HTML-only markup = HTMLMarkup () Traceback (most recent call last): File /home/jcharles/GIT/Traduc/scripts/auxiliar/translations-status.py, line 727, in module updated = markup.paragraph (markup.emph (translation[l] (last_updated_string) % date_time)) TypeError: not all arguments converted during string formatting make: *** [translation-status] Erreur 1 Compilation exited abnormally with code 2 at Sat Feb 12 16:35:09 I've primarily updated all fatal objects and put the @c Translators when missing. Cheers, Jean-Charles ___ bug-lilypond mailing list bug-lilypond@gnu.org http://lists.gnu.org/mailman/listinfo/bug-lilypond
Re: make translation-status fails
2011/2/12 Jean-Charles Malahieude lily...@orange.fr: Hello everybody, Wishing to update the translations status before 2.14 jumps out, since its last update was in November 2010, I get this error, which I'm unable to deal with: make translation-status ... Traceback (most recent call last): File /home/jcharles/GIT/Traduc/scripts/auxiliar/translations-status.py, line 727, in module updated = markup.paragraph (markup.emph (translation[l] (last_updated_string) % date_time)) TypeError: not all arguments converted during string formatting It fails for l = cs :-( -- Francisco Vila. Badajoz (Spain) www.paconet.org , www.csmbadajoz.com ___ bug-lilypond mailing list bug-lilypond@gnu.org http://lists.gnu.org/mailman/listinfo/bug-lilypond
Re: Issue 1161 in lilypond: Lyrics is not centered with CENTER affinity if there is another Lyrics with one of UP or DOWN
Comment #3 on issue 1161 by philehol...@googlemail.com: Lyrics is not centered with CENTER affinity if there is another Lyrics with one of UP or DOWN http://code.google.com/p/lilypond/issues/detail?id=1161 In the latest version of Lily, with the new spacing code, we get a different but still not wholly expected behaviour. See the attached test file and image. Attachments: LyricSpacing.ly 1.4 KB LyricSpacing.png 10.2 KB ___ bug-lilypond mailing list bug-lilypond@gnu.org http://lists.gnu.org/mailman/listinfo/bug-lilypond
Re: Issue 1105 in lilypond: clean up our css files
Updates: Status: Fixed Comment #22 on issue 1105 by philehol...@googlemail.com: clean up our css files http://code.google.com/p/lilypond/issues/detail?id=1105 postprocess_html.py updated, patch pushed. Can't find any other references to the old CSS files. ___ bug-lilypond mailing list bug-lilypond@gnu.org http://lists.gnu.org/mailman/listinfo/bug-lilypond
Re: Issue 1059 in lilypond: left-over strings in bibliography
Comment #8 on issue 1059 by philehol...@googlemail.com: left-over strings in bibliography http://code.google.com/p/lilypond/issues/detail?id=1059 I've looked hard and can find no references to the terms anywhere. For example, the first lower-case indexing name at http://lilypond.org/doc/v2.13/Documentation/essay/long-literature-list is apel53. Searching the lilypond-git directories gives us 29 files that include this text: /home/phil/lilypond-git/Documentation/essay/colorado.bib /home/phil/lilypond-git/build/out-www/offline-root/Documentation/essay-big-page.de.html /home/phil/lilypond-git/build/out-www/offline-root/Documentation/essay-big-page.es.html /home/phil/lilypond-git/build/out-www/offline-root/Documentation/essay-big-page.html /home/phil/lilypond-git/build/out-www/offline-root/Documentation/essay/long-literature-list.it.html /home/phil/lilypond-git/build/out-www/offline-root/Documentation/essay/long-literature-list.cs.html /home/phil/lilypond-git/build/out-www/offline-root/Documentation/essay/long-literature-list.es.html /home/phil/lilypond-git/build/out-www/offline-root/Documentation/essay/long-literature-list.de.html /home/phil/lilypond-git/build/out-www/offline-root/Documentation/essay/long-literature-list.zh.html /home/phil/lilypond-git/build/out-www/offline-root/Documentation/essay/long-literatur-list.de.html /home/phil/lilypond-git/build/out-www/offline-root/Documentation/essay/long-literature-list.html /home/phil/lilypond-git/build/out-www/offline-root/Documentation/essay/long-literature-list.nl.html /home/phil/lilypond-git/build/out-www/offline-root/Documentation/essay/long-literature-list.hu.html /home/phil/lilypond-git/build/out-www/offline-root/Documentation/essay/long-literature-list.fr.html /home/phil/lilypond-git/build/out-www/offline-root/Documentation/essay/long-literature-list.ja.html /home/phil/lilypond-git/build/Documentation/out/colorado.itexi /home/phil/lilypond-git/build/Documentation/out/colorado.texi /home/phil/lilypond-git/build/Documentation/out-www/essay-big-page.de.html /home/phil/lilypond-git/build/Documentation/out-www/colorado.itexi /home/phil/lilypond-git/build/Documentation/out-www/essay-big-page.es.html /home/phil/lilypond-git/build/Documentation/out-www/essay-big-page.html /home/phil/lilypond-git/build/Documentation/out-www/essay/long-literature-list.es.html /home/phil/lilypond-git/build/Documentation/out-www/essay/long-literatur-list.de.html /home/phil/lilypond-git/build/Documentation/out-www/essay/long-literature-list.html /home/phil/lilypond-git/build/Documentation/out-www/colorado.texi /home/phil/lilypond-git/build/Documentation/es/out-www/essay/long-literature-list.html /home/phil/lilypond-git/build/Documentation/es/out-www/colorado.texi /home/phil/lilypond-git/build/Documentation/de/out-www/essay/long-literatur-list.html /home/phil/lilypond-git/build/Documentation/de/out-www/colorado.texi They're all generated from the original .bib file. Searching the WWW using Google only leads to the essay references list. There are no tags in the HTML code that would allow anyone to link to them. In short, I'm pretty certain that they have no use except to serve as a header and sort method. I actually think it's potentially less safe to dive into bib2html.py and other similar build files, than it is to edit the titles direct. ___ bug-lilypond mailing list bug-lilypond@gnu.org http://lists.gnu.org/mailman/listinfo/bug-lilypond
Re: Issue 572 in lilypond: Feature request: vertical instrumentName alignment should ignore non-stafflike contexts
Updates: Status: Fixed Comment #3 on issue 572 by philehol...@googlemail.com: Feature request: vertical instrumentName alignment should ignore non-stafflike contexts http://code.google.com/p/lilypond/issues/detail?id=572 Well - I reckon comment 3 fixed this - it's easy to vertically centre instrument names on the overall staff, so marking this fixed. ___ bug-lilypond mailing list bug-lilypond@gnu.org http://lists.gnu.org/mailman/listinfo/bug-lilypond
Re: make translation-status fails
Le 12/02/2011 17:22, Francisco Vila disait : 2011/2/12 Jean-Charles Malahieudelily...@orange.fr: Hello everybody, Wishing to update the translations status before 2.14 jumps out, since its last update was in November 2010, I get this error, which I'm unable to deal with: make translation-status ... Traceback (most recent call last): File /home/jcharles/GIT/Traduc/scripts/auxiliar/translations-status.py, line 727, inmodule updated = markup.paragraph (markup.emph (translation[l] (last_updated_string) % date_time)) TypeError: not all arguments converted during string formatting It fails for l = cs Did some more investigating, in fact doc-clean, edit langdefs.py, make doc and make translation-status several times, it appears that make translation-status fails as soon as you enable either Czech or Chinese languages. I'm really unable to go further. Cheers, Jean-Charles ___ bug-lilypond mailing list bug-lilypond@gnu.org http://lists.gnu.org/mailman/listinfo/bug-lilypond
Re: Issue 1294 in lilypond: Version 2.13.35 does not properly represent lyric tie
Comment #15 on issue 1294 by pnorcks: Version 2.13.35 does not properly represent lyric tie http://code.google.com/p/lilypond/issues/detail?id=1294 After further testing (on a GNU/Linux system) with the lyric tie example from comment 2, here is a PostScript header comparison: 2.12.3: %%DocumentSuppliedResources: font CenturySchL-Roma %%DocumentSuppliedResources: font DejaVuSans %%DocumentSuppliedResources: font Emmentaler-20 2.13.48: %%DocumentSuppliedResources: font CenturySchL-Roma %%DocumentSuppliedResources: font Emmentaler-20 %%DocumentSuppliedResources: font Sazanami-Mincho-Regular And a comparison of dependency versions: 2.12.3: Fontconfig 2.7.3 Ghostscript 8.70 Pango 1.26.0 2.13.48: Fontconfig 2.8.0 Ghostscript 8.70 Pango 1.26.0 So, it looks like the next step is to figure out what changed in Fontconfig between 2.7.3 and 2.8.0 that might cause less-than-desirable font selection. ___ bug-lilypond mailing list bug-lilypond@gnu.org http://lists.gnu.org/mailman/listinfo/bug-lilypond
Re: Issue 1294 in lilypond: Version 2.13.35 does not properly represent lyric tie
Updates: Labels: -Priority-High Priority-Critical Regression Comment #16 on issue 1294 by percival.music.ca: Version 2.13.35 does not properly represent lyric tie http://code.google.com/p/lilypond/issues/detail?id=1294 (No comment was entered for this change.) ___ bug-lilypond mailing list bug-lilypond@gnu.org http://lists.gnu.org/mailman/listinfo/bug-lilypond
Re: Issue 1294 in lilypond: Version 2.13.35 does not properly represent lyric tie
Updates: Status: Started Owner: pnorcks Labels: -Type-Build Type-Defect Comment #17 on issue 1294 by pnorcks: Version 2.13.35 does not properly represent lyric tie http://code.google.com/p/lilypond/issues/detail?id=1294 On my system, I downgraded Fontconfig, compiled LilyPond git against that, and I'm not seeing a difference in font selection. That is, Sazanami-Mincho-Regular is still selected, when I expected DejaVuSans to be selected. I interpret this as meaning that the Fontconfig bump to 2.8.0 was okay... I now believe that this is a defect with LilyPond's Pango integration. I'll investigate. ___ bug-lilypond mailing list bug-lilypond@gnu.org http://lists.gnu.org/mailman/listinfo/bug-lilypond
Re: Issue 1294 in lilypond: Version 2.13.35 does not properly represent lyric tie
Updates: Status: Fixed Labels: fixed_2_13_50 Comment #18 on issue 1294 by pnorcks: Version 2.13.35 does not properly represent lyric tie http://code.google.com/p/lilypond/issues/detail?id=1294 The regression occurred between 2.13.3 and 2.13.4 with commit d3ee0333e179bf7b55c6941bfebcbed2a477b493. I've pushed a commit that fixes the regression. ___ bug-lilypond mailing list bug-lilypond@gnu.org http://lists.gnu.org/mailman/listinfo/bug-lilypond
Re: Issue 1294 in lilypond: Version 2.13.35 does not properly represent lyric tie
Comment #19 on issue 1294 by pnorcks: Version 2.13.35 does not properly represent lyric tie http://code.google.com/p/lilypond/issues/detail?id=1294 Should this have a regression test? I'm not how I would write one, considering that the fix just modifies the default font-family specification sent to Pango/Fontconfig. ___ bug-lilypond mailing list bug-lilypond@gnu.org http://lists.gnu.org/mailman/listinfo/bug-lilypond
Re: Issue 1294 in lilypond: Version 2.13.35 does not properly represent lyric tie
Comment #20 on issue 1294 by pnorcks: Version 2.13.35 does not properly represent lyric tie http://code.google.com/p/lilypond/issues/detail?id=1294 Should this have a regression test? I'm not sure how I would write one, considering that the fix just modifies the default font-family specification sent to Pango/Fontconfig. ___ bug-lilypond mailing list bug-lilypond@gnu.org http://lists.gnu.org/mailman/listinfo/bug-lilypond
Re: Issue 1294 in lilypond: Version 2.13.35 does not properly represent lyric tie
Comment #21 on issue 1294 by percival.music.ca: Version 2.13.35 does not properly represent lyric tie http://code.google.com/p/lilypond/issues/detail?id=1294 If we compared pngs in the official regtest checks, it would catch this. I'm not certain if we *want* to compare pngs, and if we did, it would *definitely* wait until after 2.14. I certainly don't see any benefit to trying to invent a regression test right now. ___ bug-lilypond mailing list bug-lilypond@gnu.org http://lists.gnu.org/mailman/listinfo/bug-lilypond
Slur+Dot Collision
This is not a regression from 2.12. I know how to manually fix it, but
it'd be nice if it avoided the dot automatically.
Related bugs: 868, 1091, 1174, 1230, 1352. I didn't see any listed
related to dot-slur collisions specifically so I thought it may be
useful.
Thanks!
-Jay
\version 2.13.49
\score
{
\new Staff \relative c'''
{
\time 6/8
{
\repeat unfold 6 \repeat unfold 6 g8 |
g4. e8( f8. c16) | % Collision between dot and slur
}
}
}
___
bug-lilypond mailing list
bug-lilypond@gnu.org
http://lists.gnu.org/mailman/listinfo/bug-lilypond
