Re: Issue 2146 in lilypond: Error: Illegal entry in bfrange block in ToUnicode CMap
Comment #2 on issue 2146 by lemzw...@gmail.com: Error: Illegal entry in bfrange block in ToUnicode CMap http://code.google.com/p/lilypond/issues/detail?id=2146 This is a bug directly in pdftex; I've just reported the problem as http://tug.org/pipermail/pdftex/2011-December/008788.html In short: There is a version mismatch of the `CenturySchL-Roma' font between lilypond and pdftex, incorrectly ignored by the latter. Since we rely on this font family, I believe the only solution is to add our own font mapping to pdftex (using \pdfmapfile) so that `our' Century fonts are used, overriding the ones coming from the TeX distribution. Unfortunately, I don't have time to test and implement this. It shouldn't be too difficult, however. ___ bug-lilypond mailing list bug-lilypond@gnu.org https://lists.gnu.org/mailman/listinfo/bug-lilypond
Re: Issue 2026 in lilypond: Make markup utility definitions available via new (scm markup-utility-defs) scheme module
Updates: Labels: Patch-review Comment #23 on issue 2026 by lilypond...@gmail.com: Make markup utility definitions available via new (scm markup-utility-defs) scheme module http://code.google.com/p/lilypond/issues/detail?id=2026#c23 Patchy the autobot says: LGTM. ___ bug-lilypond mailing list bug-lilypond@gnu.org https://lists.gnu.org/mailman/listinfo/bug-lilypond
Re: Issue 2146 in lilypond: Error: Illegal entry in bfrange block in ToUnicode CMap
Comment #1 on issue 2146 by lemzw...@gmail.com: Error: Illegal entry in bfrange block in ToUnicode CMap http://code.google.com/p/lilypond/issues/detail?id=2146 Of course you mean texi2pdf... ___ bug-lilypond mailing list bug-lilypond@gnu.org https://lists.gnu.org/mailman/listinfo/bug-lilypond
Re: Issue 2092 in lilypond: lily-git.tcl should using a "working" branch
Updates: Labels: Patch-new Comment #6 on issue 2092 by carl.d.s...@gmail.com: lily-git.tcl should using a "working" branch http://code.google.com/p/lilypond/issues/detail?id=2092#c6 Update lilygit.tcl (Issue 2092) Makes lilygit.tcl respect the environment variable $LILYPOND_GIT. If $LILYPOND_GIT is unset, default of $HOME/lilypond-git will be used. Also does all working on dev/local_working branch, instead of master Adds a Push Patch button to push patch to staging. http://codereview.appspot.com/5504092 ___ bug-lilypond mailing list bug-lilypond@gnu.org https://lists.gnu.org/mailman/listinfo/bug-lilypond
Re: Issue 2149 in lilypond: Patch: Creates non-negative-integer? predicate.
Updates: Labels: Patch-review Comment #2 on issue 2149 by lilypond...@gmail.com: Patch: Creates non-negative-integer? predicate. http://code.google.com/p/lilypond/issues/detail?id=2149#c2 Patchy the autobot says: LGTM. ___ bug-lilypond mailing list bug-lilypond@gnu.org https://lists.gnu.org/mailman/listinfo/bug-lilypond
Re: Issue 2147 in lilypond: Patch: Fixes width of NR A.11 - List of special character
Updates: Labels: Patch-review Comment #2 on issue 2147 by lilypond...@gmail.com: Patch: Fixes width of NR A.11 - List of special character http://code.google.com/p/lilypond/issues/detail?id=2147#c2 Patchy the autobot says: LGTM. ___ bug-lilypond mailing list bug-lilypond@gnu.org https://lists.gnu.org/mailman/listinfo/bug-lilypond
Re: Issue 2137 in lilypond: Patch: Doc: NR improve 'visibility' of 'q' operation
Updates: Labels: Patch-review Comment #4 on issue 2137 by lilypond...@gmail.com: Patch: Doc: NR improve 'visibility' of 'q' operation http://code.google.com/p/lilypond/issues/detail?id=2137#c4 Patchy the autobot says: LGTM. ___ bug-lilypond mailing list bug-lilypond@gnu.org https://lists.gnu.org/mailman/listinfo/bug-lilypond
Re: Issue 1629 in lilypond: Tuplet line collides with fingering
Updates: Labels: Patch-review Comment #3 on issue 1629 by lilypond...@gmail.com: Tuplet line collides with fingering http://code.google.com/p/lilypond/issues/detail?id=1629#c3 Patchy the autobot says: LGTM. ___ bug-lilypond mailing list bug-lilypond@gnu.org https://lists.gnu.org/mailman/listinfo/bug-lilypond
Re: add-grace-property and midi
On Wed, Dec 28, 2011 at 9:55 PM, Keith OHara wrote: > Is there a way to make add/remove-grace-property cooperate with midi ? Hi Keith -- Thanks for your bug report. I reproduced this issue in 2.14 also. I've added this as issue 2151 -- Brett W. McCoy -- http://www.brettwmccoy.com "In the rhythm of music a secret is hidden; If I were to divulge it, it would overturn the world." -- Jelaleddin Rumi ___ bug-lilypond mailing list bug-lilypond@gnu.org https://lists.gnu.org/mailman/listinfo/bug-lilypond
Issue 2151 in lilypond: add-grace-note usage interferes with MIDI output in same score block
Status: Accepted
Owner:
New issue 2151 by idragos...@gmail.com: add-grace-note usage interferes
with MIDI output in same score block
http://code.google.com/p/lilypond/issues/detail?id=2151
add/remove-grace-property does not cooperate with midi in the same score
block. Compile produces:
Wrong type argument in position 1 (expecting Context)
This error is not present when MIDI output block is removed.
Workaround is to place MIDI output in separate score block. Also reproduced
in 2.14.2
\version "2.15.18" % In earlier versions, replace $ by #
\score {
\new Staff {
$(add-grace-property 'Voice 'Fingering 'font-size -6)
\new Voice { b2 \grace b-2 c'-3 }
}
\layout{}
\midi{} %% Wrong type argument in position 1 (expecting Context)
}
___
bug-lilypond mailing list
bug-lilypond@gnu.org
https://lists.gnu.org/mailman/listinfo/bug-lilypond
Re: Issue 2150 in lilypond: 2.15.23 doesn't compile on Mageia
Updates: Status: Duplicate Mergedinto: 1826 Comment #1 on issue 2150 by k-ohara5...@oco.net: 2.15.23 doesn't compile on Mageia http://code.google.com/p/lilypond/issues/detail?id=2150 Tom, please email bug reports to bug-lilypond@gnu.org The 2 MB attachment eats into a 50 MB quota. ___ bug-lilypond mailing list bug-lilypond@gnu.org https://lists.gnu.org/mailman/listinfo/bug-lilypond
Re: Issue 1826 in lilypond: Guile 2.0 compat: `conditional-circle-markup' definition needs to be relocated
Comment #10 on issue 1826 by k-ohara5...@oco.net: Guile 2.0 compat: `conditional-circle-markup' definition needs to be relocated http://code.google.com/p/lilypond/issues/detail?id=1826 Issue 2150 has been merged into this issue. ___ bug-lilypond mailing list bug-lilypond@gnu.org https://lists.gnu.org/mailman/listinfo/bug-lilypond
Issue 2150 in lilypond: 2.15.23 doesn't compile on Mageia
Status: New Owner: New issue 2150 by tomspuh...@gmail.com: 2.15.23 doesn't compile on Mageia http://code.google.com/p/lilypond/issues/detail?id=2150 This is the line where it stops [/home/spuhler/Mageia_SVN/lilypond/BUILD/lilypond-2.15.22/out/share/lilypond/current/scm/define-woodwind-diagrams.scm fatal error: Not a markup command: conditional-circle-markup /current/scm/bezier-tools.scm Attached is the build log BTW, 2.15.22 didn't build with gcc-4.6.2 but did build with gcc-4.5.2 Attachments: log.lilypond 2.3 MB ___ bug-lilypond mailing list bug-lilypond@gnu.org https://lists.gnu.org/mailman/listinfo/bug-lilypond
add-grace-property and midi
Is there a way to make add/remove-grace-property cooperate with midi ?
\version "2.15.18" % In earlier versions, replace $ by #
\score {
\new Staff {
$(add-grace-property 'Voice 'Fingering 'font-size -6)
\new Voice { b2 \grace b-2 c'-3 }
}
\layout{}
\midi{} %% Wrong type argument in position 1 (expecting Context)
}
The workaround is to use a separate \score for the midi output, which we
usually need to do anyway.
___
bug-lilypond mailing list
bug-lilypond@gnu.org
https://lists.gnu.org/mailman/listinfo/bug-lilypond
Re: Issue 1943 in lilypond: lilypond after 2.15.8 fails on x86 Macs
Comment #24 on issue 1943 by stans...@gmail.com: lilypond after 2.15.8 fails on x86 Macs http://code.google.com/p/lilypond/issues/detail?id=1943 I tested the applications on an iMac x86 running OS X 10.5.8 and on a PowerBook G4 running OS X 10.5.8. LilyPond loaded without error on both platforms. I loaded a file which had previously compiled with an earlier version of LilyPond, applied convert-ly, and compiled the converted file successfully on both platforms. I noted that the version number reported when using "Get Info" is 2.15.22 on the PPC machine and 2.15.23 on the x86 machine. Bottom line- it appears you have solved the issue. Thanks! ___ bug-lilypond mailing list bug-lilypond@gnu.org https://lists.gnu.org/mailman/listinfo/bug-lilypond
Re: Issue 2142 in lilypond: accidental right-padding should depend on the tightness of music
Comment #7 on issue 2142 by janek.li...@gmail.com: accidental right-padding should depend on the tightness of music http://code.google.com/p/lilypond/issues/detail?id=2142 Hmm? Accidentals' right-padding isn't calculated, it's a constant value. It doesn't depend on anything, as far as i know. "The only way this could be pulled off in the current model of LilyPond is if the padding is set as the smaller of the two values and then the larger accidental is slotted in if there is enough room, but this is supposing that the height of the two accidentals are the same." Yes, i think this should work. I also think that Werner has a point. If i understand how Lily horizontal engine works, the solution would produce results like this: (1) a Notecolumn which has constant width (2) a spring between NoteColumn (1) and the accidental belonging to next NoteColumn (3) "accidentalColumn", something like a spring which minimal value equals width of narrow version of acidental and maximum value equal to width of normal version of accidental (4) a spring between accidental (3) and NoteColumn (5) to which it belongs (5) NoteColumn It may not work perfectly, but the results should be good enough i think. ___ bug-lilypond mailing list bug-lilypond@gnu.org https://lists.gnu.org/mailman/listinfo/bug-lilypond
Re: Issue 2143 in lilypond: accidental arrangement should depend on tightness of music
Comment #6 on issue 2143 by janek.li...@gmail.com: accidental arrangement should depend on tightness of music http://code.google.com/p/lilypond/issues/detail?id=2143 Ok, i agree that aligning vertically sharps in sixth doesn't look good; especially in Lily engraving (sharps from Feta font are bigger than the ones in that engraved example). Thanks for the alternative engraving example, Keith. I attach a comparison of these two engraving - notice that the example with staggered accidentals takes 48% more horizontal space! That's a huge difference. As for aligning octaves vs. not aligning them, i agree - let's keep this out of discussion at the moment. Concerning flats in sixths, i'm puzzled by the rule that they shouldn't be aligned. I'd say that we can keep them staggered when there's plenty of space, but in tight situations i can't see how we can keep them staggered. I attach my revised thoughts on the subject. Attachments: comparison.png 113 KB suggested output2.png 65.6 KB ___ bug-lilypond mailing list bug-lilypond@gnu.org https://lists.gnu.org/mailman/listinfo/bug-lilypond
Re: Issue 2143 in lilypond: accidental arrangement should depend on tightness of music
Comment #5 on issue 2143 by lemzw...@gmail.com: accidental arrangement should depend on tightness of music http://code.google.com/p/lilypond/issues/detail?id=2143 It's obviously a matter of tightness... My feeling is that we should delay handling of non-standard alignment (this is, not having octave accidentals aligned vertically) until the standard alignment has been fixed as good as possible. ___ bug-lilypond mailing list bug-lilypond@gnu.org https://lists.gnu.org/mailman/listinfo/bug-lilypond
Re: Issue 2142 in lilypond: accidental right-padding should depend on the tightness of music
Comment #6 on issue 2142 by lemzw...@gmail.com: accidental right-padding should depend on the tightness of music http://code.google.com/p/lilypond/issues/detail?id=2142 This `conditional skylines' approach is overkill IMHO for chords and its accidentals. I would rather consider the accidentals be part of the spring, this is, you construct a chord, then its accidentals, and the accidental configuration is handled as a rectangular block which can be squeezed and stretched horizontally to a certain extent. Wouldn't this simplify the problem so that it can be handled with `conventional' means of lilypond? ___ bug-lilypond mailing list bug-lilypond@gnu.org https://lists.gnu.org/mailman/listinfo/bug-lilypond
Re: Issue 2142 in lilypond: accidental right-padding should depend on the tightness of music
Comment #5 on issue 2142 by m...@apollinemike.com: accidental right-padding should depend on the tightness of music http://code.google.com/p/lilypond/issues/detail?id=2142 In the current model, I think that the only way to get this sorta thing implemented is by faking a spacing calculation between the two columns and then adding a rod that simulates this sorta padding. ___ bug-lilypond mailing list bug-lilypond@gnu.org https://lists.gnu.org/mailman/listinfo/bug-lilypond
Re: Issue 2142 in lilypond: accidental right-padding should depend on the tightness of music
Comment #4 on issue 2142 by m...@apollinemike.com: accidental right-padding should depend on the tightness of music http://code.google.com/p/lilypond/issues/detail?id=2142 The problem is that right-padding is calculated in order to calculate the springs that are then used in spring-and-rod calculations. The only way this could be pulled off in the current model of LilyPond is if the padding is set as the smaller of the two values and then the larger accidental is slotted in if there is enough room, but this is supposing that the height of the two accidentals are the same. Otherwise, the pure height approximations will use the larger of the two, which would lead to spacing weirdness in certain situations. ___ bug-lilypond mailing list bug-lilypond@gnu.org https://lists.gnu.org/mailman/listinfo/bug-lilypond
Re: Issue 2066 in lilypond: Patch: Prevents accidentals from hanging over barlines.
Comment #14 on issue 2066 by d...@gnu.org: Patch: Prevents accidentals from hanging over barlines. http://code.google.com/p/lilypond/issues/detail?id=2066 Personally, similar to chord names hanging over, I see little problem with letting accidentals hang over barlines. It would be a strict no-go to let them hang over key changes however; and whatever is made to hang over should have a sizeable padding keeping it away visually from preceding material. I have no reference, but that's my gut feeling. ___ bug-lilypond mailing list bug-lilypond@gnu.org https://lists.gnu.org/mailman/listinfo/bug-lilypond
Re: Issue 2143 in lilypond: accidental arrangement should depend on tightness of music
Comment #4 on issue 2143 by k-ohara5...@oco.net: accidental arrangement should depend on tightness of music http://code.google.com/p/lilypond/issues/detail?id=2143 Schirmer's engraver for the Carl Mikuli edition followed the rules -- including aligning accidentals in octaves (issue 726) at the expense of adding a column. Attachments: 2143.png 71.8 KB 726.png 25.7 KB ___ bug-lilypond mailing list bug-lilypond@gnu.org https://lists.gnu.org/mailman/listinfo/bug-lilypond
Re: Little wish: Abolish lyqi-hint from Lilypond website.
Hello, On 28 December 2011 17:17, Trevor Daniels wrote: > Thanks Heiko > > Forwarding to the bug list, as I know nothing about emacs. > > To help, could you please reply to all with the url of the offending page. > > Trevor > > - Original Message - From: "Heiko Schroeder" > > To: > Sent: Wednesday, December 28, 2011 12:12 PM > Subject: Little wish: Abolish lyqi-hint from Lilypond website. > > >> Dear Mr. Daniels, >> >> since Lilypond is a very good software, it would be >> nice and save Emacs users a lot of time, if any hint >> to the lyqi-mode could be abolished from the Lilypond- >> Documentation. Perhaps lyqi was a great thing, but to >> document a product in a wrong way like the authors web- >> site does, is far worse than no documentation. The only reference I could find for lyqi is Nicolas Sceaux's site http://lilypond.org/easier-editing.html specifically: http://nicolas.sceaux.free.fr/lilypond/lyqi.html This is NOT Lilypond Documentation. This is a developer's own 'utility', I suggest you take it up with Mr Sceaux. His contact details are on the website, but he also reads these lists too. However if there is a specific place in the LilyPond documentation you are referring to, then I'd be happy to update it. >> >> This mail has NOT the aim to ask for support, of course! of course. >> But it would be good to improve the documentation by avoi- >> ding to give annoying hints. and so all suggestions/patches are welcome. -- -- James ___ bug-lilypond mailing list bug-lilypond@gnu.org https://lists.gnu.org/mailman/listinfo/bug-lilypond
Re: Issue 2142 in lilypond: accidental right-padding should depend on the tightness of music
Comment #3 on issue 2142 by janek.li...@gmail.com: accidental right-padding should depend on the tightness of music http://code.google.com/p/lilypond/issues/detail?id=2142 Mike, do you mean that generally changing accidentals' right-padding depending on situation is very hard, or is it only the idea of introducing narrower accidentals that may make the computations hard to do? ___ bug-lilypond mailing list bug-lilypond@gnu.org https://lists.gnu.org/mailman/listinfo/bug-lilypond
Re: Issue 1943 in lilypond: lilypond after 2.15.8 fails on x86 Macs
Comment #23 on issue 1943 by chh...@gmail.com: lilypond after 2.15.8 fails on x86 Macs http://code.google.com/p/lilypond/issues/detail?id=1943 Here is a next trial to finally resolve this issue. I tested the x86 version on 10.5.8 and 10.7.2. Please test on as many configurations (x86, ppc) as possible. http://klarinett.li/lilypond/lilypond-2.15.23-1.darwin-ppc.tar.gz http://klarinett.li/lilypond/lilypond-2.15.23-1.darwin-x86.tar.gz Both use the same application bundle again. The app bundle (no lilypond binary included): http://klarinett.li/lilypond/osx-lilypad-universal.tar.gz ___ bug-lilypond mailing list bug-lilypond@gnu.org https://lists.gnu.org/mailman/listinfo/bug-lilypond
Re: Issue 2141 in lilypond: accidental spacing - some accidentals are too far from each other
Comment #3 on issue 2141 by janek.li...@gmail.com: accidental spacing - some accidentals are too far from each other http://code.google.com/p/lilypond/issues/detail?id=2141 Werner, I would force naturals in sixths (m. 75) closer than they are typeset currently by Lily only when music is tight. It's possible that they don't need to be smaller in order to be closer together. As for the upper flat in m. 9 (double flats) - I guess you're right. I shortened it so that both accidentals would be the same length, but it's a bit weird indeed. ___ bug-lilypond mailing list bug-lilypond@gnu.org https://lists.gnu.org/mailman/listinfo/bug-lilypond
Re: Issue 2149 in lilypond: Patch: Creates non-negative-integer? predicate.
Comment #1 on issue 2149 by mts...@gmail.com: Patch: Creates non-negative-integer? predicate. http://code.google.com/p/lilypond/issues/detail?id=2149#c1 Creates non-negative-integer? predicate. http://codereview.appspot.com/5501081 ___ bug-lilypond mailing list bug-lilypond@gnu.org https://lists.gnu.org/mailman/listinfo/bug-lilypond
Issue 2149 in lilypond: Patch: Creates non-negative-integer? predicate.
Status: New Owner: Labels: Type-Enhancement Patch-new New issue 2149 by mts...@gmail.com: Patch: Creates non-negative-integer? predicate. http://code.google.com/p/lilypond/issues/detail?id=2149 Creates non-negative-integer? predicate. http://codereview.appspot.com/5501081 ___ bug-lilypond mailing list bug-lilypond@gnu.org https://lists.gnu.org/mailman/listinfo/bug-lilypond
Re: Issue 2143 in lilypond: accidental arrangement should depend on tightness of music
Comment #3 on issue 2143 by philehol...@gmail.com: accidental arrangement should depend on tightness of music http://code.google.com/p/lilypond/issues/detail?id=2143 FWIW, Elaine Gould allows accidentals a sixth apart to align when the upper one is a flat, but says they should be offset when the upper is a sharp or natural. Where they are both sharps, she says "the closest that two sharps may be placed together is so that the edges of their crossbars align vertically. The sharps cannot overlap, as the vertical strokes would jin up". ___ bug-lilypond mailing list bug-lilypond@gnu.org https://lists.gnu.org/mailman/listinfo/bug-lilypond
Re: Issue 2066 in lilypond: Patch: Prevents accidentals from hanging over barlines.
Comment #13 on issue 2066 by n.putt...@gmail.com: Patch: Prevents accidentals from hanging over barlines. http://code.google.com/p/lilypond/issues/detail?id=2066 I've just had a quick flick through Turangalîla-Symphonie and Quatuor pour la Fin du Temps. There are no cases where accidentals breach barlines (though in the former it's exceedingly rare for any clusters to be isolated from other instruments, so there's always some spacing constraints preventing really tight spacing. The Quatuor has at least one example of really tight accidentals in the piano part on page 45 (Seventh movement, at rehearsal mark `I' and three bars before `J'), but they never hang over the barline - the left edge of the first accidental is very slightly to the right. ___ bug-lilypond mailing list bug-lilypond@gnu.org https://lists.gnu.org/mailman/listinfo/bug-lilypond
Re: Issue 2142 in lilypond: accidental right-padding should depend on the tightness of music
Comment #2 on issue 2142 by m...@apollinemike.com: accidental right-padding should depend on the tightness of music http://code.google.com/p/lilypond/issues/detail?id=2142 Welcome to my world of pain. I toyed around with ideas like this in my summer-of-lily but gave up because of the following reason : In LilyPond, springs and rods are calculated based on the distances between paper columns, which requires knowing the columns' horizontal skylines. What you're suggesting are having conditional skylines that can change in different spacing situations. This means that a given spring-and-rod problem will need to be solved 2**n times, where n is the number of conditional spacing variations that could happen in it. If there are 10ish conditional variations (meaning accidentals) per line, you're looking at compilation times that last well into the end of Western music (if not earth). I've suggested several times that linear programming & the simplex method (or a commensurately effective solver) could be the solution to these woes, but Han-Wen told me that in the early days of LilyPond this is how things were done & compilation times got outta hand. I'd be interested in seeing how linear programming w/ 1ish variables would fare on a modern computer - if it's hackable, it may be worth looking into this. ___ bug-lilypond mailing list bug-lilypond@gnu.org https://lists.gnu.org/mailman/listinfo/bug-lilypond
Re: Little wish: Abolish lyqi-hint from Lilypond website.
Thanks Heiko Forwarding to the bug list, as I know nothing about emacs. To help, could you please reply to all with the url of the offending page. Trevor - Original Message - From: "Heiko Schroeder" To: Sent: Wednesday, December 28, 2011 12:12 PM Subject: Little wish: Abolish lyqi-hint from Lilypond website. Dear Mr. Daniels, since Lilypond is a very good software, it would be nice and save Emacs users a lot of time, if any hint to the lyqi-mode could be abolished from the Lilypond- Documentation. Perhaps lyqi was a great thing, but to document a product in a wrong way like the authors web- site does, is far worse than no documentation. This mail has NOT the aim to ask for support, of course! But it would be good to improve the documentation by avoi- ding to give annoying hints. Best regards Heiko Schroeder ___ bug-lilypond mailing list bug-lilypond@gnu.org https://lists.gnu.org/mailman/listinfo/bug-lilypond
Re: Issue 2143 in lilypond: accidental arrangement should depend on tightness of music
Comment #2 on issue 2143 by n.putt...@gmail.com: accidental arrangement should depend on tightness of music http://code.google.com/p/lilypond/issues/detail?id=2143 I agree with Werner. That example looks awful. Unless I'm mistaken, the accurate box code deliberated prevents the sixths from being aligned (at least for flats) because it's considered bad typesetting. ___ bug-lilypond mailing list bug-lilypond@gnu.org https://lists.gnu.org/mailman/listinfo/bug-lilypond
Re: Issue 2143 in lilypond: accidental arrangement should depend on tightness of music
Comment #1 on issue 2143 by lemzw...@gmail.com: accidental arrangement should depend on tightness of music http://code.google.com/p/lilypond/issues/detail?id=2143 I strongly disagree to align two sharp signs vertically for a sixth! This looks really bad IMHO, even in the real-world examples you are providing. It might be a last-resort solution for the tighest typesetting (similar issues arise for typesetting of narrow columns), and *probably* OK in chords with more than two notes, but otherwise it should always be slightly offset (by at least the thickness of the the sharp sign's vertical stem). ___ bug-lilypond mailing list bug-lilypond@gnu.org https://lists.gnu.org/mailman/listinfo/bug-lilypond
Re: Issue 2142 in lilypond: accidental right-padding should depend on the tightness of music
Comment #1 on issue 2142 by lemzw...@gmail.com: accidental right-padding should depend on the tightness of music http://code.google.com/p/lilypond/issues/detail?id=2142 Providing squeezed glyph variants for tight typesetting is a good idea! ___ bug-lilypond mailing list bug-lilypond@gnu.org https://lists.gnu.org/mailman/listinfo/bug-lilypond
Re: Issue 2141 in lilypond: accidental spacing - some accidentals are too far from each other
Comment #2 on issue 2141 by lemzw...@gmail.com: accidental spacing - some accidentals are too far from each other http://code.google.com/p/lilypond/issues/detail?id=2141 I agree with all your suggestions except bar 75: I somehow dislike making the naturals smaller; the shape changes too much (contrary to flats and sharps). In bar 9 of the double flats: Why gets the upper shape smaller too? I see no reason for it. ___ bug-lilypond mailing list bug-lilypond@gnu.org https://lists.gnu.org/mailman/listinfo/bug-lilypond
Re: Issue 2066 in lilypond: Patch: Prevents accidentals from hanging over barlines.
Comment #12 on issue 2066 by m...@apollinemike.com: Patch: Prevents accidentals from hanging over barlines. http://code.google.com/p/lilypond/issues/detail?id=2066 As always, I think the most important thing is to check the literature. I'd look at the scores of Messiaen and Feldman to start, as they're likely to have written-out clusters with many accidentals in extreme registers. The music library is 40 minutes away from my place, so if someone has closer access to works by these composers, please peruse them! ___ bug-lilypond mailing list bug-lilypond@gnu.org https://lists.gnu.org/mailman/listinfo/bug-lilypond
Re: Issue 2094 in lilypond: spacing-measure-length.ly regtest has time sig overlaying rest
Updates: Status: Fixed Labels: -Patch-push fixed_2_15_24 Comment #7 on issue 2094 by carl.d.s...@gmail.com: spacing-measure-length.ly regtest has time sig overlaying rest http://code.google.com/p/lilypond/issues/detail?id=2094 Pushed to staging as 297e9f6..8118309 ___ bug-lilypond mailing list bug-lilypond@gnu.org https://lists.gnu.org/mailman/listinfo/bug-lilypond
Re: Issue 2066 in lilypond: Patch: Prevents accidentals from hanging over barlines.
Comment #11 on issue 2066 by janek.li...@gmail.com: Patch: Prevents
accidentals from hanging over barlines.
http://code.google.com/p/lilypond/issues/detail?id=2066
I partly agree, but what about
<<
\relative c {
c1 | c1
\repeat unfold 8 { 8 }
}
\relative c'' {
\repeat unfold 16 { c8 }
\repeat unfold 16 { c16 }
}
?
See attachment.
Attachments:
overhanging accidentals (2.15.23).pdf 182 KB
___
bug-lilypond mailing list
bug-lilypond@gnu.org
https://lists.gnu.org/mailman/listinfo/bug-lilypond
Re: Issue 2145 in lilypond: shorter versions of accidentals for use in tight situations
Updates: Labels: Type-Enhancement Needs-design Comment #1 on issue 2145 by janek.li...@gmail.com: shorter versions of accidentals for use in tight situations http://code.google.com/p/lilypond/issues/detail?id=2145 (No comment was entered for this change.) ___ bug-lilypond mailing list bug-lilypond@gnu.org https://lists.gnu.org/mailman/listinfo/bug-lilypond
Issue 2148 in lilypond: object outlines shouldn't be rectangular
Status: Accepted Owner: CC: milimet...@gmail.com Labels: Type-Ugly New issue 2148 by janek.li...@gmail.com: object outlines shouldn't be rectangular http://code.google.com/p/lilypond/issues/detail?id=2148 Currently many objects are treated as rectangles (dynamics, lyrics, lyric extender, slur, clef, hairpin, augmentation dot, etc) - i.e. the outline used for checking collisions is a rectangle. This leads to poor results in spacing, as attached examples show (lily code is attached inside pdfs). I suppose we should calculate collisions not by fiddling with boxes, but rather by implementing some sort of "metric" that would meause real distance between objects (that is, distance between certain 2-dimensional black areas). Should issue 584 be merged into this one? Attachments: barNumber-clef padding - bad outlines, 2.15.23.pdf 67.3 KB dynamics padding - bad outlines 2, 2.15.23.pdf 71.8 KB dynamics padding - bad outlines, 2.15.23.pdf 82.6 KB lyric extender padding - bad outlines, 2.15.23.pdf 80.2 KB lyrics padding - bad outlines, 2.15.23.pdf 96.3 KB dot-notehead distance should vary - 2.15.23 and suggested.png 64.1 KB ___ bug-lilypond mailing list bug-lilypond@gnu.org https://lists.gnu.org/mailman/listinfo/bug-lilypond
Re: Issue 2147 in lilypond: Patch: Fixes width of NR A.11 - List of special character
Comment #1 on issue 2147 by philehol...@gmail.com: Patch: Fixes width of NR A.11 - List of special character http://code.google.com/p/lilypond/issues/detail?id=2147 At present, the NR section A.11 has a table which flows off the side of the PDF page. This patch fixes that, with the table reduced to 4 columns rather than 5. ___ bug-lilypond mailing list bug-lilypond@gnu.org https://lists.gnu.org/mailman/listinfo/bug-lilypond
Issue 2147 in lilypond: Patch: Fixes width of NR A.11 - List of special character
Status: New Owner: Labels: Type-Patch Patch-new New issue 2147 by philehol...@gmail.com: Patch: Fixes width of NR A.11 - List of special character http://code.google.com/p/lilypond/issues/detail?id=2147 Fixes width of NR A.11 - List of special character http://codereview.appspot.com/5504091 ___ bug-lilypond mailing list bug-lilypond@gnu.org https://lists.gnu.org/mailman/listinfo/bug-lilypond
Issue 2146 in lilypond: Error: Illegal entry in bfrange block in ToUnicode CMap
Status: Accepted Owner: Labels: Type-Build New issue 2146 by philehol...@gmail.com: Error: Illegal entry in bfrange block in ToUnicode CMap http://code.google.com/p/lilypond/issues/detail?id=2146 The error in the title occurs when trying to create LilyPond documentation that contains a variety of special characters, and the characters aren't created. This is widespread throughout the documentation build, and is an error generated by pdf2texi. The set of files attached provides a fairly minimal test suite. Running pdf2texi on BFRangeTesttest.texi produces (on my Ubuntu boxes) 5 lines with the error and a PDF file (as attached) without the No and N characters, which are present in the included PDF file. This appears to be a bug with pdf2texi, but it affects LP, so raising an issue here so that anyone with experience of debugging pdf2texi can assist. Attachments: BFRangeTesttest.texi 155 bytes BFEx.texi 25 bytes BFEx.pdf 10.9 KB BFRangeTesttest.pdf 30.0 KB ___ bug-lilypond mailing list bug-lilypond@gnu.org https://lists.gnu.org/mailman/listinfo/bug-lilypond
Re: Issue 726 in lilypond: Request: accidentals in the same octave would look better not aligned (in some cases)
Comment #6 on issue 726 by janek.li...@gmail.com: Request: accidentals in the same octave would look better not aligned (in some cases) http://code.google.com/p/lilypond/issues/detail?id=726 More examples attached. Also, the behaviour mentioned in comment #1 is not fixed. Issue 2144 was opened to remember about it. Attachments: accidentals in octaves misaligned 1.png 303 KB accidentals in octaves misaligned 2.png 266 KB accidentals in octaves misaligned 3.png 272 KB ___ bug-lilypond mailing list bug-lilypond@gnu.org https://lists.gnu.org/mailman/listinfo/bug-lilypond
Re: Issue 2144 in lilypond: accidentals should be able to slide over/under suspended notes without problems
Comment #1 on issue 2144 by janek.li...@gmail.com: accidentals should be
able to slide over/under suspended notes without problems
http://code.google.com/p/lilypond/issues/detail?id=2144
Another example:
\relative {
<< {
gis'! gis! gis! gis!
} \\ {
} >>
}
output attached (with source code as attachment in pdf)
Attachments:
suspended notes and accidentals 4 - 2.15.23.pdf 65.9 KB
___
bug-lilypond mailing list
bug-lilypond@gnu.org
https://lists.gnu.org/mailman/listinfo/bug-lilypond
Re: Issue 2141 in lilypond: accidental spacing - some accidentals are too far from each other
Comment #1 on issue 2141 by janek.li...@gmail.com: accidental spacing - some accidentals are too far from each other http://code.google.com/p/lilypond/issues/detail?id=2141 More real engraving examples. Once again a list of related issues (this time with links - previously the tracker didn't recognize issues that didn't exist at that moment) issue 2142 issue 2143 issue 2144 issue 2145 Attachments: example - flats in sixth 1.png 314 KB example - flats in sixth 2.png 101 KB example - flats in sixth 3.png 29.6 KB example - flats in third.png 76.5 KB example - natural and flat in firth.png 314 KB example - natural and sharp in sixth 1.png 268 KB example - natural and sharp in sixth 2.png 85.2 KB example - natural and sharp in sixth 3.png 27.0 KB example - naturals in sixth.png 131 KB example - sharp and natural in fifth.png 83.0 KB example - sharp and natural in seventh.png 132 KB example - sharp and natural in sixth 1.png 269 KB example - sharp and natural in sixth 2.png 37.9 KB example - sharps in sixth 1.png 287 KB example - sharps in sixth 2.png 328 KB ___ bug-lilypond mailing list bug-lilypond@gnu.org https://lists.gnu.org/mailman/listinfo/bug-lilypond
Issue 2145 in lilypond: shorter versions of accidentals for use in tight situations
Status: Accepted Owner: New issue 2145 by janek.li...@gmail.com: shorter versions of accidentals for use in tight situations http://code.google.com/p/lilypond/issues/detail?id=2145 As issue 2143 and issue 2144 say, sometimes accidentals should be packed tightly. It would give good results to have special shorter accidentals for use in such situations. ___ bug-lilypond mailing list bug-lilypond@gnu.org https://lists.gnu.org/mailman/listinfo/bug-lilypond
Issue 2144 in lilypond: accidentals should be able to slide over/under suspended notes without problems
Status: Accepted Owner: New issue 2144 by janek.li...@gmail.com: accidentals should be able to slide over/under suspended notes without problems http://code.google.com/p/lilypond/issues/detail?id=2144 Currently Lily tries too hard to keep accidentals not colliding with notes. The results are accidentals spaced too widely. Examples attached. Related issues: issue 2141 issue 2142 issue 2143 issue 2145 Attachments: suspended notes and accidentals 1 - 2.13 with example.png 53.7 KB suspended notes and accidentals 2 - 2.13 with example.png 68.6 KB suspended notes and accidentals 3 - 2.14 with example.png 41.5 KB suspended notes and accidentals 1.ly 32 bytes suspended notes and accidentals 2.ly 474 bytes suspended notes and accidentals 3.ly 366 bytes ___ bug-lilypond mailing list bug-lilypond@gnu.org https://lists.gnu.org/mailman/listinfo/bug-lilypond
Issue 2143 in lilypond: accidental arrangement should depend on tightness of music
Status: Accepted Owner: CC: milimet...@gmail.com Labels: Type-Enhancement New issue 2143 by janek.li...@gmail.com: accidental arrangement should depend on tightness of music http://code.google.com/p/lilypond/issues/detail?id=2143 depending on space available, accidentals should be placed more or less "dense". For example two flats in sixth (and two sharps in sixth, too) should be aligned in one vertical line when they appear in a rapid succession of 32nds, while they shouldn't be aligned if there's plenty of whitespace before notes to which they apply. Accidentals should be also placed tightly when they affect the first note after a barline (it is preferred to have first note in a measure as close to the barline as possible, within reason). Attached "desired output.png" shows how the results might look like. Following are real engraving examples. Related issues: issue 2141 issue 2142 issue 2144 issue 2145 Attachments: desired output.png 32.1 KB example - flats and naturals 1.png 316 KB example - flats in sixth 3.png 29.6 KB example - natural and sharp in sixth 2.png 85.2 KB example - natural and sharp in sixth 3.png 27.0 KB example - naturals in sixth.png 131 KB example - sharp and natural in fifth.png 83.0 KB example - sharp and natural in seventh.png 132 KB example - sharp and natural in sixth 1.png 273 KB example - sharp and natural in sixth 2.png 37.9 KB example - sharps in sixth 1.png 287 KB example - sharps in sixth 2.png 328 KB ___ bug-lilypond mailing list bug-lilypond@gnu.org https://lists.gnu.org/mailman/listinfo/bug-lilypond
Issue 2142 in lilypond: accidental right-padding should depend on the tightness of music
Status: Accepted Owner: CC: milimet...@gmail.com Labels: Type-Enhancement New issue 2142 by janek.li...@gmail.com: accidental right-padding should depend on the tightness of music http://code.google.com/p/lilypond/issues/detail?id=2142 When notes are close togehter, accidentals should be closer to the noteheads (their padding should be smaller). See attached "flexible right-padding" examples. Accidental should always be closer to the note to which it applies than to the preceeding note (unlike in "cary, anti-example.png" taken from our website). In some occasions a narrower version of accidental should be used (see "squeezed accidentals.png"). Additional shortening of ledgers should perhaps take place. Related issues: issue 2141 issue 2143 issue 2144 issue 2145 Attachments: flexible right-padding 1.png 87.7 KB flexible right-padding 2.png 22.4 KB cary, anti-example .png 43.3 KB squeezed accidentals.png 133 KB tight music example - very small padding.png 118 KB example - g-moll ballage (mostly page 6).pdf 2.2 MB Chopin Sonate op. 35 - example.png 66.1 KB Chopin Sonate op. 35 - Lily 2.13.54.png 96.2 KB Chopin Sonate op. 35 - example.ly 890 bytes ___ bug-lilypond mailing list bug-lilypond@gnu.org https://lists.gnu.org/mailman/listinfo/bug-lilypond
Issue 2141 in lilypond: accidental spacing - some accidentals are too far from each other
Status: Accepted Owner: CC: mts...@gmail.com, milimet...@gmail.com Labels: Type-Enhancement New issue 2141 by janek.li...@gmail.com: accidental spacing - some accidentals are too far from each other http://code.google.com/p/lilypond/issues/detail?id=2141 Some combinations of accidentals are put too far apart, for example in . All possible pairs of accidentals are attached in pngs beginning with "pairs". Combinations that definately should be closer together are marked with a red dot; combinations that may look better if they were a bit closer are marked with an orange dot. A real engraving example is also attached (more detailed examples will follow). Related issues: issue 2142 issue 2143 issue 2144 issue 2145 Attachments: pairs - bad flats.png 105 KB pairs - suggested flats.png 91.5 KB pairs - bad naturals.png 104 KB pairs - suggested naturals.png 92.7 KB pairs - bad sharps.png 107 KB pairs - suggested sharps.png 106 KB pairs - bad double flats.png 106 KB pairs - suggested double flats.png 92.4 KB pairs - bad double sharps.png 101 KB pairs - suggested double sharps.png 88.2 KB pairs - accidentals too far from themselves.ly 2.4 KB tight music example - Chopin Ballade g-moll op.23 Klindworth (mostly page 6).pdf 2.2 MB ___ bug-lilypond mailing list bug-lilypond@gnu.org https://lists.gnu.org/mailman/listinfo/bug-lilypond
Re: Issue 2066 in lilypond: Patch: Prevents accidentals from hanging over barlines.
Comment #10 on issue 2066 by m...@apollinemike.com: Patch: Prevents
accidentals from hanging over barlines.
http://code.google.com/p/lilypond/issues/detail?id=2066
I would prefer the second example below over the first.
\relative c {
R1 |
\repeat unfold 12 { 4 }
}
\relative c {
R1 |
\override Staff . BarLine #'extra-spacing-height =
#pure-from-neighbor-interface::extra-spacing-height
\repeat unfold 12 { 4 }
}
___
bug-lilypond mailing list
bug-lilypond@gnu.org
https://lists.gnu.org/mailman/listinfo/bug-lilypond
Re: Issue 2066 in lilypond: Patch: Prevents accidentals from hanging over barlines.
Comment #9 on issue 2066 by janek.li...@gmail.com: Patch: Prevents accidentals from hanging over barlines. http://code.google.com/p/lilypond/issues/detail?id=2066 Guys, what are you tryng to do?! Accidentals that can overhang barlines are good for the look of the music. Don't you think that they help keeping rhythm as legible as possible? Look at attached Screenshot1 - in my opinion the gaps that appear there are unpleasant. As for engraved examples mentioned in http://code.google.com/p/lilypond/issues/detail?id=1955 , they prove nothing. Please notice that in these examples the default distance between barline and first note is so big that there cannot be any overhang at all! (see attached) Also, Breitkopf example is in my opinion badly typeset, so we shouldn't take it into account anyway. I might have missed something in the discussion, but honestly i don't see any case in which the overhang would be bad. Actually, the only applicable example is here http://code.google.com/p/lilypond/issues/detail?id=2066#c3 and it shows overhang. Attachments: Screenshot1.png 164 KB Peters.png 140 KB Breitkopf.png 46.6 KB ___ bug-lilypond mailing list bug-lilypond@gnu.org https://lists.gnu.org/mailman/listinfo/bug-lilypond
Re: Issue 1629 in lilypond: Tuplet line collides with fingering
Updates: Labels: Patch-new Comment #2 on issue 1629 by mts...@gmail.com: Tuplet line collides with fingering http://code.google.com/p/lilypond/issues/detail?id=1629#c2 Avoids TupletBracket-Fingering and TupletBracket-StringNumber collisions. http://codereview.appspot.com/5505079 ___ bug-lilypond mailing list bug-lilypond@gnu.org https://lists.gnu.org/mailman/listinfo/bug-lilypond
Re: Issue 1947 in lilypond: Stem Tremoli for double-stemmed notes are too short on the right side.
Updates: Status: Fixed Comment #5 on issue 1947 by mts...@gmail.com: Stem Tremoli for double-stemmed notes are too short on the right side. http://code.google.com/p/lilypond/issues/detail?id=1947 Pushed to staging as 297e9f6f16be3a451f2381c00e7f44ac61232154. ___ bug-lilypond mailing list bug-lilypond@gnu.org https://lists.gnu.org/mailman/listinfo/bug-lilypond
Re: Issue 2084 in lilypond: script-accidental avoidance fails for articulations
Updates: Status: Fixed Comment #9 on issue 2084 by mts...@gmail.com: script-accidental avoidance fails for articulations http://code.google.com/p/lilypond/issues/detail?id=2084 Pushed as d4d2066396729b224a3b041d37573efbb30c5303. ___ bug-lilypond mailing list bug-lilypond@gnu.org https://lists.gnu.org/mailman/listinfo/bug-lilypond
Re: Issue 1861 in lilypond: DynamicText attached to spacer rest not correctly aligned
Updates: Status: Fixed Comment #6 on issue 1861 by mts...@gmail.com: DynamicText attached to spacer rest not correctly aligned http://code.google.com/p/lilypond/issues/detail?id=1861 Pushed as 47236e0a7a5a75d5dd2be521c44102b20d8c76ce ___ bug-lilypond mailing list bug-lilypond@gnu.org https://lists.gnu.org/mailman/listinfo/bug-lilypond
Re: Issue 1361 in lilypond: Collision: TupletNumber and Script
Updates: Status: Fixed Comment #2 on issue 1361 by mts...@gmail.com: Collision: TupletNumber and Script http://code.google.com/p/lilypond/issues/detail?id=1361 Fixed with 26d40794616f7dc6d47af25bb373a5d2353633cf. ___ bug-lilypond mailing list bug-lilypond@gnu.org https://lists.gnu.org/mailman/listinfo/bug-lilypond
Re: Issue 257 in lilypond: collision accent and tuplet bracket
Updates: Status: Fixed Comment #8 on issue 257 by mts...@gmail.com: collision accent and tuplet bracket http://code.google.com/p/lilypond/issues/detail?id=257 Pushed as 26d40794616f7dc6d47af25bb373a5d2353633cf. ___ bug-lilypond mailing list bug-lilypond@gnu.org https://lists.gnu.org/mailman/listinfo/bug-lilypond
Re: Issue 695 in lilypond: slurs may take too much vertical extent
Updates: Status: Fixed Comment #13 on issue 695 by mts...@gmail.com: slurs may take too much vertical extent http://code.google.com/p/lilypond/issues/detail?id=695 Pushed to staging as 19520fd5bbd221ca1d35011d7710e233c92a44b0 ___ bug-lilypond mailing list bug-lilypond@gnu.org https://lists.gnu.org/mailman/listinfo/bug-lilypond
