Re: Issue 1335 in lilypond: bad shapes of scripts.varsegno, accordion.push, and noteheads.s0re
Comment #3 on issue 1335 by lemzwerg: bad shapes of scripts.varsegno, accordion.push, and noteheads.s0re http://code.google.com/p/lilypond/issues/detail?id=1335 My comment regarding mf/README was mainly directed to author of the first two glyphs... Regarding the standards, it's partially my fault of introducing some sloppiness since I was too busy to check the patches in detail at the time they have been discussed. ___ bug-lilypond mailing list bug-lilypond@gnu.org http://lists.gnu.org/mailman/listinfo/bug-lilypond
Re: Issue 503 in lilypond: schleifer articulation requested
On Mon, Oct 18, 2010 at 11:37 PM, David Kastrup wrote: > I have some problems reconciling "Fixed" with "workaround". > > "workaround" corresponds to categories "Wontfix" or "Postponed" or a > priority "Low". But "Fixed" and "workaround" seem like an odd match. I agree that there's kind of a leap here. Since I highly doubt that we'll implement this feature, and since the workaround (kinda) gets the job done, me marking this as Fixed only means that I'm suggesting that my fellow bug-squad colleagues close the issue. Since I'm not sure that it is the way to go, I wouldn't close the issue by myself; besides, the snippet may need to be included in the docs or whatever -- depending on how frequently this articulation may be needed, which I certainly am in no place to appreciate. Valentin ___ bug-lilypond mailing list bug-lilypond@gnu.org http://lists.gnu.org/mailman/listinfo/bug-lilypond
Re: Issue 1335 in lilypond: bad shapes of scripts.varsegno, accordion.push, and noteheads.s0re
Updates: Owner: Carl.D.Sorensen Comment #2 on issue 1335 by Carl.D.Sorensen: bad shapes of scripts.varsegno, accordion.push, and noteheads.s0re http://code.google.com/p/lilypond/issues/detail?id=1335 I can't speak for the varsegno, but for the walker, funk, and thin shape notes I'm responsible. I *did* read mf/README, but I guess I didn't understand it all. In modifying the shape note code, I followed the examples of the existing shape note code, which didn't follow the standards. Thanks for the explanations. I'll fix things up. ___ bug-lilypond mailing list bug-lilypond@gnu.org http://lists.gnu.org/mailman/listinfo/bug-lilypond
Re: Issue 503 in lilypond: schleifer articulation requested
lilyp...@googlecode.com writes: > Updates: > Status: Fixed > Owner: v.villenave > > Comment #1 on issue 503 by v.villenave: schleifer articulation requested > http://code.google.com/p/lilypond/issues/detail?id=503 > > A workaround has been suggested on the LSR: > http://lsr.dsi.unimi.it/LSR/Item?id=720 I have some problems reconciling "Fixed" with "workaround". "workaround" corresponds to categories "Wontfix" or "Postponed" or a priority "Low". But "Fixed" and "workaround" seem like an odd match. -- David Kastrup ___ bug-lilypond mailing list bug-lilypond@gnu.org http://lists.gnu.org/mailman/listinfo/bug-lilypond
Re: Voicename not recognised in music function
Marten Visser writes:
>> I'm not top posting.
>
> A voicename not is recognised in a music function.
>
> In the example below, I'd expect to get two documents with the same
> content. However, in the "error" document, no lyrics are typeset, and
> an error is sent into the logfile. Why?
> \score {
> <<
> \new Voice = "melody" { \relative c'' { d cis b a } }
> \new Lyrics \lyricsto "melody" \lyricmode { An ex
> -- am -- ple. }
> >>
> }
vs.
> MusFunc = #(define-music-function (parser location) ()
> #{
> \new Voice = "melody" { \relative c'' { d cis b a } }
> \new Lyrics \lyricsto "melody" \lyricmode { An ex -- am --
> ple. }
> #} )
>
> \book {
> \bookOutputSuffix "Error"
> \score {
> <<
> \MusFunc
> >>
> }
Music functions return sequential music by default, not a sequence of
partial music expressions folded into an upper syntactical construct.
So the lower is the equivalent of
\score {
<< {
\new Voice = "melody" { \relative c'' { d cis b a } }
\new Lyrics \lyricsto "melody" \lyricmode { An ex
-- am -- ple. }
} >>
}
if I am not mistaken.
It is likely that you can return a parallel music expression explicitly
using Scheme.
Perhaps it would be nice to allow #<< instead of #{ as a shortcut for
creating a music expression returning parallel music.
--
David Kastrup
___
bug-lilypond mailing list
bug-lilypond@gnu.org
http://lists.gnu.org/mailman/listinfo/bug-lilypond
Re: Issue 1335 in lilypond: bad shapes of scripts.varsegno, accordion.push, and noteheads.s0re
Updates: Labels: Priority-High Comment #1 on issue 1335 by percival.music.ca: bad shapes of scripts.varsegno, accordion.push, and noteheads.s0re http://code.google.com/p/lilypond/issues/detail?id=1335 (No comment was entered for this change.) ___ bug-lilypond mailing list bug-lilypond@gnu.org http://lists.gnu.org/mailman/listinfo/bug-lilypond
Issue 1335 in lilypond: bad shapes of scripts.varsegno, accordion.push, and noteheads.s0re
Status: Accepted Owner: Labels: Type-Defect New issue 1335 by lemzwerg: bad shapes of scripts.varsegno, accordion.push, and noteheads.s0re http://code.google.com/p/lilypond/issues/detail?id=1335 It seems that people who are working on the lilypond fonts haven't read the file mf/README. Please do so! I've attached fontforge images of three broken glyphs; this is what you get if you say FONTFORGE=foo mf2pt1 --rounding=0.0001 feta13 (by pointing the environment variable FONTFORGE to something nonexistent you prevent postprocessing). The first glyph, scripts.varsegno, contains grazing intersections, which is VERY bad. The solution is to force the direction of the curved pieces to be the same as the straight ones. The second one, accordion.push, has been defined using the the `draw' command with a polygonal pen. Again, this is VERY bad. The fix is to describe the outline explicitly as a path which gets filled then. The third one, noteheads.s0re, has a self-intersecting contour; note that probably other shaped note heads needs corrections also to make them render fine with all possible design sizes. Finally, please follow the whitespace and formatting conventions already present in the MF files. In particular, please say foo := a -- b .. c and not foo := a -- b .. c Attachments: scripts.varsegno.png 101 KB accordion.push.png 41.2 KB noteheads.s0re.png 43.1 KB ___ bug-lilypond mailing list bug-lilypond@gnu.org http://lists.gnu.org/mailman/listinfo/bug-lilypond
Re: Issue 1332 in lilypond: missing libgnugetops; GUB uncompilable
Updates: Status: Fixed Labels: fixed_2_13_36 Comment #5 on issue 1332 by percival.music.ca: missing libgnugetops; GUB uncompilable http://code.google.com/p/lilypond/issues/detail?id=1332 It compiles, and a libgnugetopt-1.3.tar.bz2 is now hosted on lilypond.org. ___ bug-lilypond mailing list bug-lilypond@gnu.org http://lists.gnu.org/mailman/listinfo/bug-lilypond
Issue 1334 in lilypond: Enhancement: a \score-lines markup command for multi-lines embedded scores
Status: Accepted Owner: Labels: Type-Enhancement Priority-Low markup New issue 1334 by v.villenave: Enhancement: a \score-lines markup command for multi-lines embedded scores http://code.google.com/p/lilypond/issues/detail?id=1334 Neil had this idea, a while back: http://lists.gnu.org/archive/html/lilypond-user/2010-07/msg00083.html It would be nice if a markup could include a \score block made of several lines, that could be used somehow like a markup-lines command. Among others, it could make it easier to specify different line-lengths (and it may even help address issue 677). As far as I know, important modifications have been made to markup-embedded scores (judging by this mail: http://lists.gnu.org/archive/html/lilypond-devel/2010-05/msg00053.html ) so this feature request might be easier to implement now. (Or perhaps even irrelevant?) ___ bug-lilypond mailing list bug-lilypond@gnu.org http://lists.gnu.org/mailman/listinfo/bug-lilypond
Issue 1333 in lilypond: Enhancement: beamed acciaccaturas should be printed with a slash
Status: Accepted
Owner:
Labels: Type-Enhancement Priority-Low Bounty grace
New issue 1333 by v.villenave: Enhancement: beamed acciaccaturas should be
printed with a slash
http://code.google.com/p/lilypond/issues/detail?id=1333
Quoting NR 1.2.6.1:
"A multi-note beamed acciaccatura is printed without a slash, and looks
exactly the same as a multi-note beamed appoggiatura." Here's an example:
\version 2.13.36
\new Staff \relative c'' {
a8 b a c
\acciaccatura {
g16[ a b c ] }
d2
}
Of course, workarounds exist (see
http://lsr.dsi.unimi.it/LSR/Snippet?id=721 ). But apart from internal
limitations, there is no purely musical reason why we shouldn't support
this in the future.
Related feature request:
http://lists.gnu.org/archive/html/lilypond-user/2007-04/msg00278.html
(possibly with a bounty, which I'll personally cover even if the original
authors were no longer interested)
Attachments:
toto.png 1.6 KB
___
bug-lilypond mailing list
bug-lilypond@gnu.org
http://lists.gnu.org/mailman/listinfo/bug-lilypond
Re: Issue 1323 in lilypond: "Back to documentation index" tocframe link is broken in online dev manuals
Updates: Status: Fixed Labels: fixed_2_13_36 Comment #7 on issue 1323 by john.mandereau: "Back to documentation index" tocframe link is broken in online dev manuals http://code.google.com/p/lilypond/issues/detail?id=1323 Fixed in 4e1c6143411ffed26d21c066a5eb4569ad54e18b ___ bug-lilypond mailing list bug-lilypond@gnu.org http://lists.gnu.org/mailman/listinfo/bug-lilypond
