Re: automatic accidental style voice: too many written accidentals
Since the \key command still works at the Staff level (both technically in LilyPond and musically, since there's no notation available to specify separate key signatures for separate voices within a stave), I clearly see it as a bug if the Staff key isn't seen by each Voice. What if, at the point a voice is instanciated, we automatically set its key signature to that of its parent staff context. That would solve this issue. Where can I find the code where voices are instanciated? Frédéric ___ bug-lilypond mailing list bug-lilypond@gnu.org http://lists.gnu.org/mailman/listinfo/bug-lilypond
Re: Regression: spacing single full-bar notes with ragged-right=##f
On Fri, Aug 28, 2009 at 11:41 PM, Trevor Daniels t.dani...@treda.co.uk wrote: Greetings Trevor and Neil, sorry for bumping this so late: The default value for 'full-measure-spacing-width appears to be just the default value for the distance property of a Spring object, which is 1, so setting 'full-measure-extra-space to -1 effectively sets the space added to all but the first bar to 0. This looks like it might be a solution to Werner's original problem, and it also gives a means for reducing the extra space when bars are seriously stretched. I'll explore it a little more. Have you had another look at this issue? The output is still meh with 2.13.6 :-) Regards, Valentin ___ bug-lilypond mailing list bug-lilypond@gnu.org http://lists.gnu.org/mailman/listinfo/bug-lilypond
Re: Spacing bug: text exceeding page footer
On Sun, Sep 13, 2009 at 6:30 PM, Nicolas Sceaux nicolas.sce...@free.fr wrote: %%% in the first page, text spread on the page footer (and beyond) %%% before breaking to the next one. Hi Nicolas, it took me a while, but it's finally been added as http://code.google.com/p/lilypond/issues/detail?id=876 Sorry for the delay :) Valentin ___ bug-lilypond mailing list bug-lilypond@gnu.org http://lists.gnu.org/mailman/listinfo/bug-lilypond
Re: Rehearsal mark positionning
On Sun, Sep 13, 2009 at 7:38 PM, Neil Puttock n.putt...@gmail.com wrote: No, I'm sure you're right here, which means there's a problem with disabling the after-line-breaking callback, especially in the case of tall Score objects. Greetings, I'm not sure how to write a bug report for this: I can't understand the link between Nicolas' initial mark-on-top-staff problem and the fact that RehearsalMarks aren't taken into account when computing the page layout. Does this need two separate reports? Thanks for your help (and sorry for the delay), Valentin ___ bug-lilypond mailing list bug-lilypond@gnu.org http://lists.gnu.org/mailman/listinfo/bug-lilypond
Re: automatic accidental style voice: too many written accidentals
Frédéric Bron frederic.b...@m4x.org writes:
Since the \key command still works at the Staff level (both
technically in LilyPond and musically, since there's no notation
available to specify separate key signatures for separate voices
within a stave), I clearly see it as a bug if the Staff key isn't
seen by each Voice.
What if, at the point a voice is instanciated, we automatically set
its key signature to that of its parent staff context. That would
solve this issue.
In general, that is a mistake: accidentals are typeset per staff. Now
this is about an accidental-style 'voice for which we have
As a result, accidentals from one voice do not get canceled in
other voices, which is often an unwanted result: in the following
example, it is hard to determine whether the second `a' should be
played natural or sharp. The `voice' option should therefore be
used only if the voices are to be read solely by individual
musicians. If the staff is to be used by one musician (e.g., a
conductor or in a piano score) then `modern' or
`modern-cautionary' should be used instead.
Under this premise, I think it makes sense to inherit the key signature.
Now if we have _within_ a voice { xxx } \\ { yyy } , what does this
mean? Since the purpose of voice accidental style is to write stuff
that several different people read, this corresponds to splitting a
tenor voice (for example). This means that the split voices should not
just inherit the key signature, but also already preexisting accidentals
of the father voice since obviously the same persons are singing tenor
1 and tenor 2 that have been singing tenor previously. Also, any
accidental changes within xxx and yyy need to be consolidated into the
following rejoined voice: if there are different accidentals in xxx and
yyy for a note, a recurrence of the note after the split needs a
cautionary accidental.
--
David Kastrup
___
bug-lilypond mailing list
bug-lilypond@gnu.org
http://lists.gnu.org/mailman/listinfo/bug-lilypond
Issue 877 in lilypond: Ottava clefs may not look good
Status: Accepted
Owner: v.villenave
Labels: Type-Defect Priority-Medium Engraving-nitpick
New issue 877 by v.villenave: Ottava clefs may not look good
http://code.google.com/p/lilypond/issues/detail?id=877
% Clef-ottavas may be printed too far from the clef: in the F^8
% example below, one can't say whether it belongs to the top
% or the bottom staff.
\version 2.10 % and 2.12.2 % and 2.13.6
\score {
\override Score.Clef #'stencil = #(make-stencil-boxer 0 0
ly:clef::print)
\new Staff { \clef G^8 g''1 }
\new Staff { \clef F^8 c'1 }
\new Staff { \clef C^8 c''1 }
\new Staff { \clef G_8 g1 }
\new Staff { \clef F_8 c,1 }
\new Staff { \clef C_8 c1 }
\layout{ragged-right = ##t }
}
The bounding box, however, is correct.
Another related nitpick from Reinhold:
Another thing about the octavation is the horizontal alignment of the
number: For the treble_8 and the bass^8, the 8 is too far to the right
for my taste (it is centered, which does not look good with the clef
shape!).
Attachments:
clef.png 2.0 KB
--
You received this message because you are listed in the owner
or CC fields of this issue, or because you starred this issue.
You may adjust your issue notification preferences at:
http://code.google.com/hosting/settings
___
bug-lilypond mailing list
bug-lilypond@gnu.org
http://lists.gnu.org/mailman/listinfo/bug-lilypond
Re: Ottava too far from clef in \clef F^8
On Fri, Sep 18, 2009 at 3:21 PM, Reinhold Kainhofer reinh...@kainhofer.com wrote: This looks very weird for a mid-line \clef soprano^8, since the (smaller) clef on the lowest staff line will not even touch the middle staff line, but the 8 is printed above the top staff line... Hi Peter, Mats and Reinhold, sorry for the delay. I've added this as http://code.google.com/p/lilypond/issues/detail?id=877 Looks very odd indeed. Regards, Valentin ___ bug-lilypond mailing list bug-lilypond@gnu.org http://lists.gnu.org/mailman/listinfo/bug-lilypond
Re: automatic accidental style voice: too many written accidentals
Under this premise, I think it makes sense to inherit the key signature.
Now if we have _within_ a voice { xxx } \\ { yyy } , what does this
mean? Since the purpose of voice accidental style is to write stuff
that several different people read, this corresponds to splitting a
tenor voice (for example). This means that the split voices should not
just inherit the key signature, but also already preexisting accidentals
of the father voice since obviously the same persons are singing tenor
1 and tenor 2 that have been singing tenor previously. Also, any
accidental changes within xxx and yyy need to be consolidated into the
following rejoined voice: if there are different accidentals in xxx and
yyy for a note, a recurrence of the note after the split needs a
cautionary accidental.
Good point.
So this would not be the case for voice style (apart from heriting the
key signature) but for modern-voice it would be OK as the cancellation
is at Staff context.
Frédéric
___
bug-lilypond mailing list
bug-lilypond@gnu.org
http://lists.gnu.org/mailman/listinfo/bug-lilypond
Issue 878 in lilypond: Bowing indications need higher priority than fingerings
Status: Accepted Owner: v.villenave Labels: Type-Defect Priority-Medium Engraving-nitpick New issue 878 by v.villenave: Bowing indications need higher priority than fingerings http://code.google.com/p/lilypond/issues/detail?id=878 Please read the discussion on http://lists.gnu.org/archive/html/lilypond-user/2009-09/msg00233.html Currently (as of \version 2.13.6), bowing indications have no special script-priority. As a result, such things as d''4-2\upbow will print the fingering *outside* the bowing indication, which is wrong, as Jan demonstrated with the two attached scans of Baerenreiter's solo cello suite. This is easily fixed by updating upbow and downbow definitions in script.scm. Attachments: beer1.png 101 KB beer2-small.png 14.9 KB -- You received this message because you are listed in the owner or CC fields of this issue, or because you starred this issue. You may adjust your issue notification preferences at: http://code.google.com/hosting/settings ___ bug-lilypond mailing list bug-lilypond@gnu.org http://lists.gnu.org/mailman/listinfo/bug-lilypond
Re: New user question - relative bowing and fingering marks
On Tue, Sep 8, 2009 at 12:26 PM, Valentin Villenave v.villen...@gmail.com wrote: thanks, but did this work? I don't see any bug-lilypond ... Thanks for noticing :-) And now added as http://code.google.com/p/lilypond/issues/detail?id=878 Since this is easy to fix, it could be a nice task for a Frog. BTW, I didn't see any script-stacking demo regtest, do we need one? Cheers, Valentin ___ bug-lilypond mailing list bug-lilypond@gnu.org http://lists.gnu.org/mailman/listinfo/bug-lilypond
Issue 876 in lilypond: Spacing bug: text exceeding page footer
Comment #1 on issue 876 by paconet.org: Spacing bug: text exceeding page footer http://code.google.com/p/lilypond/issues/detail?id=876 This is a dupe of #850 and was fixed by Joe b51279cfe1a -- You received this message because you are listed in the owner or CC fields of this issue, or because you starred this issue. You may adjust your issue notification preferences at: http://code.google.com/hosting/settings ___ bug-lilypond mailing list bug-lilypond@gnu.org http://lists.gnu.org/mailman/listinfo/bug-lilypond
Re: \RemoveEmptyStaffContext and cross-staff beams
On Wed, Sep 23, 2009 at 9:54 PM, Neil Puttock n.putt...@gmail.com wrote: There's a message in the deleted bug snippet harakiri-autoknee.ly which suggests there used to be a problem: Autoknee-ing triggers hara-kiri too early. OK, since I can't decide whether to remove it or not, I've just added it to the tracker for now (with some delay though): http://code.google.com/p/lilypond/issues/detail?id=879 Regards, Valentin ___ bug-lilypond mailing list bug-lilypond@gnu.org http://lists.gnu.org/mailman/listinfo/bug-lilypond
Issue 879 in lilypond: RemoveEmptyStaffContext doesn't need to disable auto-knee-gap
Status: Accepted Owner: v.villenave Labels: Type-Defect Priority-Medium New issue 879 by v.villenave: RemoveEmptyStaffContext doesn't need to disable auto-knee-gap http://code.google.com/p/lilypond/issues/detail?id=879 As of version 2.13.6, RemoveEmptyStaff still unsets auto-knee-gap, which seems not to be needed any longer, as mentioned in http://lists.gnu.org/archive/html/lilypond-user/2009-09/msg00537.html This is a simple fix, but we'd also need a regtest about that. -- You received this message because you are listed in the owner or CC fields of this issue, or because you starred this issue. You may adjust your issue notification preferences at: http://code.google.com/hosting/settings ___ bug-lilypond mailing list bug-lilypond@gnu.org http://lists.gnu.org/mailman/listinfo/bug-lilypond
Re: SystemStartBrace doesn't stretch vertically
On Tue, Sep 29, 2009 at 3:35 AM, Jonathan Wilkes jancs...@yahoo.com wrote: Greetings Jonathan, The brace for a PianoStaff should be stretched vertically for larger staves, not simply resized as it currently seems to do. I'm not sure it's the appropriate engraving tradition (vertically-stretched braces could look quite awful IMHO). Could you find some example in a printed score, and send us the scan? Thanks (and sorry for the delay), Valentin ___ bug-lilypond mailing list bug-lilypond@gnu.org http://lists.gnu.org/mailman/listinfo/bug-lilypond
Issue 880 in lilypond: Arpeggios collide with notes when connectArpeggios is set
Status: Accepted
Owner: v.villenave
Labels: Type-Collision Priority-Medium
New issue 880 by v.villenave: Arpeggios collide with notes when
connectArpeggios is set
http://code.google.com/p/lilypond/issues/detail?id=880
% From Robin Bannister:
% When the connectArpeggios mode includes an arpeggio on a single note,
% the resultant span arpeggio may collide with a previous note.
\version 2.13.6
d = { d'16 d'16 d'16 d'16 d'4 \arpeggio } % single note
sdf = { s4 d' f'4 \arpeggio } % chord
\score {
\transpose c c'{ \d \sdf } \\ { \sdf \d }
\layout {
line-width = #66
\context {
\Staff
\consists Span_arpeggio_engraver
connectArpeggios = ##t
}
}
}
In span-arpeggio-engraver.cc it says:
we can't kill the children, since we don't want
the previous note to bump into the span arpeggio
When arpeggio.cc prints a squiggly arpeggio on a single note, it warns
no heads for arpeggio found?
and kills the arpeggio.
There is another demo and a proposed workaround on the user list at
http://lists.gnu.org/archive/html/lilypond-user/2009-09/msg00735.html
There are many unresolved collisions with arpeggios: see for instance issue
601 and issue 821.
Attachments:
collision.png 2.5 KB
--
You received this message because you are listed in the owner
or CC fields of this issue, or because you starred this issue.
You may adjust your issue notification preferences at:
http://code.google.com/hosting/settings
___
bug-lilypond mailing list
bug-lilypond@gnu.org
http://lists.gnu.org/mailman/listinfo/bug-lilypond
Re: wrong beaming of dotted 8th followed by 8ths
On Sat, Oct 3, 2009 at 12:41 AM, luis jure l...@internet.com.uy wrote: I'm not top posting. Hi Luis, sorry for the delay, % this shows the default beaming and how it should be beamed r16 c8. c8 c r16 c8. c8[ c] | I'm not sure what to do. The first half of the measure does look ugly indeed (see attached), but I can't decide whether it's a bug or not. Trevor, what would you do? (I'm asking you because beaming is kind of your speciality now, isn't it? ;-) Regards, Valentin attachment: beaming.png___ bug-lilypond mailing list bug-lilypond@gnu.org http://lists.gnu.org/mailman/listinfo/bug-lilypond
Issue 882 in lilypond: Markup columns collisions
Status: Accepted
Owner: v.villenave
Labels: Type-Collision Priority-Regression
New issue 882 by v.villenave: Markup columns collisions
http://code.google.com/p/lilypond/issues/detail?id=882
In the following example, only the very last part (a column followed with a
regular word) doesn't produce a collision. The other parts (a regular word
followed with a column, or a column followed with another column) produce
awful collisions.
\version 2.13.6
\markup \line {
blah
\center-column { blahblah blah }
\center-column { blahblah blah }
blah
}
IIRC it used to work with 2.10.
Attachments:
collision.png 1.5 KB
--
You received this message because you are listed in the owner
or CC fields of this issue, or because you starred this issue.
You may adjust your issue notification preferences at:
http://code.google.com/hosting/settings
___
bug-lilypond mailing list
bug-lilypond@gnu.org
http://lists.gnu.org/mailman/listinfo/bug-lilypond
Re: Bad dimensions for \bracket
On Sun, Oct 18, 2009 at 2:34 PM, David Kastrup d...@gnu.org wrote: % \bracket appears to correctly bracket an entire construct, but % calculate its overall dimension just from its last part Thanks, but the actual bug doesn't even need to involve brackets: http://code.google.com/p/lilypond/issues/detail?id=882 (not even sure it's a bug, actually) Regards, Valentin ___ bug-lilypond mailing list bug-lilypond@gnu.org http://lists.gnu.org/mailman/listinfo/bug-lilypond
Re: span arpeggio and single notes
On Wed, Oct 21, 2009 at 2:53 PM, Robin Bannister r...@dataway.ch wrote: While waiting for acknowledgement, I have come across several online examples of this. Yes, I suspect these issues have the same underlying cause (though I opened multiple issues since I'm not sure what that cause might be). Regards, Valentin ___ bug-lilypond mailing list bug-lilypond@gnu.org http://lists.gnu.org/mailman/listinfo/bug-lilypond
Re: collision between laisserVibrer semi-tie and arpeggio
On Sat, Oct 17, 2009 at 3:05 PM, Robin Bannister r...@dataway.ch wrote: f'\laissezVibrer g f' \arpeggio \mark always Thanks, added as http://code.google.com/p/lilypond/issues/detail?id=881 Cheers, Valentin ___ bug-lilypond mailing list bug-lilypond@gnu.org http://lists.gnu.org/mailman/listinfo/bug-lilypond
Issue 881 in lilypond: Arpeggios may collide with laissezVibrer ties
Status: Accepted
Owner: v.villenave
Labels: Type-Collision Priority-Regression
New issue 881 by v.villenave: Arpeggios may collide with laissezVibrer ties
http://code.google.com/p/lilypond/issues/detail?id=881
% From Robin:
% As shown in the attached example, the collision is only reproduced
% under certain conditions. Unlike issue 880, this one seems to be
% a regression:
\version 2.12.1 % regression: 2.10.33 and 2.8.8 are ok
{
f'\laissezVibrer f a' \arpeggio
f'\laissezVibrer g a' \arpeggio \mark never
f'\laissezVibrer a a' \arpeggio
f'\laissezVibrer b a' \arpeggio
\bar ||
f'\laissezVibrer f g' \arpeggio
f'\laissezVibrer g g' \arpeggio \mark sometimes
f'\laissezVibrer a g' \arpeggio
f'\laissezVibrer b g' \arpeggio
\bar ||
f'\laissezVibrer f f' \arpeggio
f'\laissezVibrer g f' \arpeggio \mark always
f'\laissezVibrer a f' \arpeggio
f'\laissezVibrer b f' \arpeggio
}
Attachments:
collision.png 6.9 KB
--
You received this message because you are listed in the owner
or CC fields of this issue, or because you starred this issue.
You may adjust your issue notification preferences at:
http://code.google.com/hosting/settings
___
bug-lilypond mailing list
bug-lilypond@gnu.org
http://lists.gnu.org/mailman/listinfo/bug-lilypond
Issue 883 in lilypond: stems may collide with noteheads in tightly-spaced music
Status: Accepted
Owner: v.villenave
Labels: Type-Collision Priority-Regression
New issue 883 by v.villenave: stems may collide with noteheads in
tightly-spaced music
http://code.google.com/p/lilypond/issues/detail?id=883
In the following example, some notes collide with the chord's stem while
others are ok.
\version 2.12.1 % regression: 2.10.33 and 2.8.8 are ok
\layout {
line-width = 120
}
dense = #(define-music-function (parser location mus) (ly:music?)
#{ s2 $mus $mus $mus $mus d' g'' 4 \noBreak #})
{
\dense e''16
\dense d''16
\dense c''16 % collision
\dense b' 16 % collision
\stemDown
\dense a' 16 % collision
\dense g' 16
\dense f' 16
}
Attachments:
collision.png 4.7 KB
--
You received this message because you are listed in the owner
or CC fields of this issue, or because you starred this issue.
You may adjust your issue notification preferences at:
http://code.google.com/hosting/settings
___
bug-lilypond mailing list
bug-lilypond@gnu.org
http://lists.gnu.org/mailman/listinfo/bug-lilypond
Re: stemDown notehead colliding with sparse stemDown chord
On Wed, Oct 21, 2009 at 6:45 PM, Francisco Vila paconet@gmail.com wrote: d, g' 4 c'16 c c c % collision Thanks, added as http://code.google.com/p/lilypond/issues/detail?id=883 I'm not sure it's a bug, though, since the noBreaks and the line-width are a bit extreme. Regards, Valenitn ___ bug-lilypond mailing list bug-lilypond@gnu.org http://lists.gnu.org/mailman/listinfo/bug-lilypond
Issue 884 in lilypond: pageBreak resets page-count property
Status: Accepted
Owner: v.villenave
CC: nicolas.sceaux, joeneeman
Labels: Type-Defect Priority-Medium
New issue 884 by v.villenave: pageBreak resets page-count property
http://code.google.com/p/lilypond/issues/detail?id=884
From Chris Snyder:
According to LNR 4.1.2, the page-count setting sets The number of pages
to be used for a score. The presence of a \pageBreak command in the score,
however, causes the score to be split into multiple chunks, each having
page-count number of pages. Effectively, the final page count of the score
is page-count*(number of \pageBreak commands present + 1) rather than just
page-count.
For instance, the following snippet produces a four-pages PDF though
page-count is set to 2:
\version 2.13.6
\paper {
page-count = 2
}
\score {
\new Staff {
\repeat unfold 50 { c'1 }
\pageBreak
\repeat unfold 50 { c'1 }
}
}
Of course, an easy solution would be to change the documentation of
page-count.
--
You received this message because you are listed in the owner
or CC fields of this issue, or because you starred this issue.
You may adjust your issue notification preferences at:
http://code.google.com/hosting/settings
___
bug-lilypond mailing list
bug-lilypond@gnu.org
http://lists.gnu.org/mailman/listinfo/bug-lilypond
Issue 885 in lilypond: Uninstallation issues
Status: Accepted Owner: v.villenave Labels: Type-Defect Priority-Low New issue 885 by v.villenave: Uninstallation issues http://code.google.com/p/lilypond/issues/detail?id=885 I'm opening this issue to gather all problems we may encounter when uninstalling LilyPond. For instance, Patrick has recently noticed that on *nix systems a few symlinks are left after uninstallation in ~/bin: abc2ly convert-ly etf2ly lilypond-book lilypond-invoke-editor midi2ly mup2ly musicxml2ly -- You received this message because you are listed in the owner or CC fields of this issue, or because you starred this issue. You may adjust your issue notification preferences at: http://code.google.com/hosting/settings ___ bug-lilypond mailing list bug-lilypond@gnu.org http://lists.gnu.org/mailman/listinfo/bug-lilypond
Re: transposing baroque noteheads modernizes them
On Tue, Oct 6, 2009 at 5:20 PM, Laura Conrad lcon...@laymusic.org wrote:
The attached lilypond file, which I would expect to produce baroque
noteheads (i.e., square notes for the breves) produces whole notes
with bars around them for breves.
Greetings Laura (sorry for the delay),
Hm. I can't understand exactly what's happening here, but I suspect
your syntax with multiple constructs is responsible. Could you
investigate it further?
I can't reproduce the bug with a minimal example such as
\version 2.12.0
{
\transpose c' g' {
\override NoteHead #'style = #'baroque
\clef bass
\time 4/2
d\breve c g a
}
}
I'm reporting this to bugs; I think it's a regression. I'm pretty
sure the transpose script I have worked on 2.10.
Interesting. Likewise, it would be great to test it with a minimal
example that does reproduce the bug.
I'm willing to call it an idiosyncrasy if someone can come up with a
good reason for this behavior, or a reason why a user could possibly
want it.
If \transpose did revert the NoteHear style, it would certainly be a
bug. But as you can see, that doesn't happen with my example above.
Regards,
Valentin
___
bug-lilypond mailing list
bug-lilypond@gnu.org
http://lists.gnu.org/mailman/listinfo/bug-lilypond
Issue 886 in lilypond: ChordNames horizontal extent may affect note spacing
Status: Accepted
Owner: v.villenave
Labels: Type-Defect Priority-Medium
New issue 886 by v.villenave: ChordNames horizontal extent may affect note
spacing
http://code.google.com/p/lilypond/issues/detail?id=886
From Jean-Alexis Montignies:
In the following example (reproduced with both 2.12 and 2.13.5), the chord
names affect causes the highest notes to be weirdly spaced.
\score {
\new ChordNames {
\chordmode { d1:7.9-.11- d:7.9-.11- }
}
\relative c'' {
d'16 d r4. r2
d,16 d r4. r2
}
}
Attachments:
weird_space.png 3.5 KB
--
You received this message because you are listed in the owner
or CC fields of this issue, or because you starred this issue.
You may adjust your issue notification preferences at:
http://code.google.com/hosting/settings
___
bug-lilypond mailing list
bug-lilypond@gnu.org
http://lists.gnu.org/mailman/listinfo/bug-lilypond
Re: layout problem with chords
On Fri, Oct 23, 2009 at 12:31 PM, Jean-Alexis Montignies j...@montignies.info wrote: %% the space between the two notes should not be so wide %% the problem is reproducible with 2.12 versions Thanks, added as http://code.google.com/p/lilypond/issues/detail?id=886 As you can see, this only affects high notes. Regards, Valentin ___ bug-lilypond mailing list bug-lilypond@gnu.org http://lists.gnu.org/mailman/listinfo/bug-lilypond
Issue 887 in lilypond: PDF point-and-click URI links with special chars wrongly encoded depending on the OS
Status: Accepted Owner: v.villenave Labels: Type-Defect Priority-Medium OpSys-Linux OpSys-OSX New issue 887 by v.villenave: PDF point-and-click URI links with special chars wrongly encoded depending on the OS http://code.google.com/p/lilypond/issues/detail?id=887 New report from Dénes: http://lists.gnu.org/archive/html/bug-lilypond/2009-09/msg00090.html Point-and-click links in Lily-generated PDF files do not work if they link to a file with a non-ASCII filename or path. The PDF spec says that the URIs should be encoded as 7-bit ASCII, instead they are encoded in the system's default encoding (Cp1250 on Windows, UTF-8 on Unixes) and then escaped with backslash-codes. Here's a not-for-the-faint-hearted example: Links to a file named árvíztűrő tükörfúrógép.ly look like this: - On Windows: C:\Documents and Settings\Harmath Denes\workspace-classic\.runtime\árvíztűrő tükörfúrógép\árvíztűrő tükörfúrógép.ly - textedit://C:/Documents%20and%20Settings/Harmath%20Denes/workspace-classic/.runtime/\341rv\355zt\373r\365%20t\374k\374rf\372r\363g\351p/\341rv\355zt\373r\365%20t\374k\366rf\372r\363g\351p.ly This is correct, the system finds the file. - But on OS X...: /Users/thsoft/Development/.runtime/árvíztűrő tükörfúrógép/árvíztűrő tükörfúrógép.ly - textedit:///Users/thsoft/Development/.runtime/a\314\201rvi\314\201ztu\314\213ro\314\213%20tu\314\210ko\314\210rfu\314\201ro\314\201ge\314\201p/\303\241rv\303\255zt\305\261r\305\221%20t\303\274k\303\266rf\303\272r\303\263g\303\251p.ly - and on GNU/Linux: textedit:///home/valentin/\303\241rv\303\255zt\305\261r\305\221%20t\303\274k\303\266rf\303\272r\303\263g\303\251p/\303\241rv\303\255zt\305\261r\305\221%20t\303\274k\303\266rf\303\272r\303\263g\303\251p.ly Notice that in this case, accented characters in the path (e.g. á - a\314\201) are encoded differently (!) than accented characters in the filename (á - \303\241)... Seems like that the latter is correct, but only with Latin-2 characters; further experiments showed that: a\á.ly is correct a\ő.ly is incorrect (ő is not in the Latin-2 charset) á\*.ly are always incorrect -- You received this message because you are listed in the owner or CC fields of this issue, or because you starred this issue. You may adjust your issue notification preferences at: http://code.google.com/hosting/settings ___ bug-lilypond mailing list bug-lilypond@gnu.org http://lists.gnu.org/mailman/listinfo/bug-lilypond
Re: Incorrect URIs of files with non-ASCII filenames for point-and-click links in PDF
2009/10/29 Harmath Dénes harmathde...@gmail.com: I hope this clarifies the problem and helps to debug the source of it. Well, all I know is that it allows me to add it to the tracker: http://code.google.com/p/lilypond/issues/detail?id=887 I also have added the generated link on GNU/Linux. Thanks, Valentin ___ bug-lilypond mailing list bug-lilypond@gnu.org http://lists.gnu.org/mailman/listinfo/bug-lilypond
Issue 887 in lilypond: PDF point-and-click URI links with special chars wrongly encoded depending on the OS
Comment #1 on issue 887 by harmathdenes: PDF point-and-click URI links with special chars wrongly encoded depending on the OS http://code.google.com/p/lilypond/issues/detail?id=887 As it can be seen, the difference between the encoding of directory and file names refers only to the OS X behaviour. (The non-Latin-2 issue occurs on both OS X and Linux.) So on Linux, á\á.ly is correct, but á\ő.ly is again not. -- You received this message because you are listed in the owner or CC fields of this issue, or because you starred this issue. You may adjust your issue notification preferences at: http://code.google.com/hosting/settings ___ bug-lilypond mailing list bug-lilypond@gnu.org http://lists.gnu.org/mailman/listinfo/bug-lilypond
Re: Enhancement request: scheme function to scale a stencil
On Wed, Oct 28, 2009 at 12:25 PM, Robin Bannister r...@dataway.ch wrote: I feel that these two should be complemented by a third transformation along the lines of the postscript operator: x y scale. Nice idea! Added as http://code.google.com/p/lilypond/issues/detail?id=888 Cheers, Valentin ___ bug-lilypond mailing list bug-lilypond@gnu.org http://lists.gnu.org/mailman/listinfo/bug-lilypond
Re: Incorrect point-and-click URIs of files with non-ASCII content on Windows
2009/10/27 Patrick McCarty pnor...@gmail.com: Valentin, can you add this to the tracker? The subject of this thread is okay for an issue summary. Does http://code.google.com/p/lilypond/issues/detail?id=887 cover it? I haven't mentioned the weird position oddity. Cheers, Valentin ___ bug-lilypond mailing list bug-lilypond@gnu.org http://lists.gnu.org/mailman/listinfo/bug-lilypond
Issue 888 in lilypond: Enhancement: ly:stencil-scale
Status: Accepted Owner: v.villenave Labels: Type-Enhancement Priority-Medium New issue 888 by v.villenave: Enhancement: ly:stencil-scale http://code.google.com/p/lilypond/issues/detail?id=888 New request from Robin: We currently have two basic transformations: ly:stencil-translate and ly:stencil-rotate. These could be complemented by a ly:stencil-scale transformation along the lines of the postscript operator: x y scale. This could of course be used for zooming, but would also allow to change the aspect ratio, flip/stretch objects etc. -- You received this message because you are listed in the owner or CC fields of this issue, or because you starred this issue. You may adjust your issue notification preferences at: http://code.google.com/hosting/settings ___ bug-lilypond mailing list bug-lilypond@gnu.org http://lists.gnu.org/mailman/listinfo/bug-lilypond
Issue 889 in lilypond: SystemStartBrace's variable vertical extent should not affect their weight
Status: Accepted
Owner: v.villenave
Labels: Type-Defect Priority-Medium Engraving-nitpick
New issue 889 by v.villenave: SystemStartBrace's variable vertical extent
should not affect their weight
http://code.google.com/p/lilypond/issues/detail?id=889
New report from Jonathan Wilkes:
In the following example, the weight of the braces don't match.
If you uncomment staves 4 and 5 you'll see how distracting such a huge,
thick brace would be in an orchestral setting (grouping the strings
together, for example).
\score {
\new PianoStaff {
\new Staff { c }
\new Staff { c }
}
\new PianoStaff {
\new Staff = one { c }
\new Staff = two { c }
\new Staff = three { c }
% \new Staff = four { c }
% \new Staff = five { c }
}
}
A solution would be to vertically stretch braces (instead of scaling them,
which is the current behavior).
An example of a vertically stretched brace may be found on
http://imslp.info/files/imglnks/usimg/d/dd/IMSLP00510-Debussy_-_Preludes__Book_2.pdf
(though French publishers are hardly a good example when it comes to music
scores).
Attachments:
different_weights.png 5.1 KB
--
You received this message because you are listed in the owner
or CC fields of this issue, or because you starred this issue.
You may adjust your issue notification preferences at:
http://code.google.com/hosting/settings
___
bug-lilypond mailing list
bug-lilypond@gnu.org
http://lists.gnu.org/mailman/listinfo/bug-lilypond
Re: Incorrect point-and-click URIs of files with non-ASCII content on Windows
2009/10/29 Harmath Dénes harmathde...@gmail.com: No, the two are very different. In http://code.google.com/p/lilypond/issues/detail?id=887, the _filename_ part of the URIs is wrong because of non-ASCII _filenames_. In this bug (http://article.gmane.org/gmane.comp.gnu.lilypond.bugs/16097), the _column position_ part of the URIs is wrong because of non-ASCII _content_. Interesting. Patrick, doesn't it look a lot like David's report on http://lists.gnu.org/archive/html/bug-lilypond/2009-10/msg00049.html ? Anyway, as mentioned, the latter is more general, and is related to not the PDF generation, but the position calculation, since it occurs in command-line compiler errors too. Yes, which is why I'd like to know if Patrick's recent work on David's report could have affected this one as well. Cheers, Valentin ___ bug-lilypond mailing list bug-lilypond@gnu.org http://lists.gnu.org/mailman/listinfo/bug-lilypond
Issue 889 in lilypond: SystemStartBrace's variable vertical extent should not affect their weight
Comment #1 on issue 889 by v.villenave: SystemStartBrace's variable vertical extent should not affect their weight http://code.google.com/p/lilypond/issues/detail?id=889 I'm not sure if this is a good idea, but it could be interesting to have an alternative font for braces rather than blindly stretching them (see issue 870). -- You received this message because you are listed in the owner or CC fields of this issue, or because you starred this issue. You may adjust your issue notification preferences at: http://code.google.com/hosting/settings ___ bug-lilypond mailing list bug-lilypond@gnu.org http://lists.gnu.org/mailman/listinfo/bug-lilypond
Re: SystemStartBrace doesn't stretch vertically
On Thu, Oct 29, 2009 at 11:16 AM, Valentin Villenave v.villen...@gmail.com wrote: I'm not sure it's the appropriate engraving tradition (vertically-stretched braces could look quite awful IMHO). Could you find some example in a printed score, and send us the scan? Oops, I just found your Debussy link. Never mind -- though I do think that this example looks awful, but you do have a point nevertheless :-) Added as http://code.google.com/p/lilypond/issues/detail?id=889 Cheers, Valentin ___ bug-lilypond mailing list bug-lilypond@gnu.org http://lists.gnu.org/mailman/listinfo/bug-lilypond
Re: Bad dimensions for \bracket
Valentin Villenave v.villen...@gmail.com writes: On Sun, Oct 18, 2009 at 2:34 PM, David Kastrup d...@gnu.org wrote: % \bracket appears to correctly bracket an entire construct, but % calculate its overall dimension just from its last part Thanks, but the actual bug doesn't even need to involve brackets: http://code.google.com/p/lilypond/issues/detail?id=882 (not even sure it's a bug, actually) In the case of the brackets, it clearly is. The brackets form a new total object, and the resulting object dimensions do not correspond to what the brackets have encased. This is a discrepancy. Which of the discrepancy parts you call a non-bug is up to you. Bug 882 may or may not be related, and may or may not be a bug, but this discrepancy in the context of brackets _is_ a bug. -- David Kastrup ___ bug-lilypond mailing list bug-lilypond@gnu.org http://lists.gnu.org/mailman/listinfo/bug-lilypond
Issue 889 in lilypond: SystemStartBrace's variable vertical extent should not affect their weight
Comment #2 on issue 889 by Carl.D.Sorensen: SystemStartBrace's variable vertical extent should not affect their weight http://code.google.com/p/lilypond/issues/detail?id=889 Perhaps this could be resolved by changing the way the brace scales with size in the font sources. -- You received this message because you are listed in the owner or CC fields of this issue, or because you starred this issue. You may adjust your issue notification preferences at: http://code.google.com/hosting/settings ___ bug-lilypond mailing list bug-lilypond@gnu.org http://lists.gnu.org/mailman/listinfo/bug-lilypond
Re: span arpeggio and single notes
Valentin Villenave wrote: While waiting for acknowledgement, I have come across several online examples of this. Yes, I suspect these issues have the same underlying cause (though I opened multiple issues since I'm not sure what that cause might be). Well, that was my point in that follow-up. I was _addressing_ the underlying cause. All of these examples benefit from the constrain-hidden-positions workaround, which disguises the single notes. I therefore conclude that (in these 4 cases) the single note is the trigger. This single note aspect didn't make it into the title of issue 880. But it is this distinguishing characteristic which can help disentangle the multiple issues, as my followup did with 601c2 and 821. Cheers, Robin ___ bug-lilypond mailing list bug-lilypond@gnu.org http://lists.gnu.org/mailman/listinfo/bug-lilypond
Re: SystemStartBrace doesn't stretch vertically
--- On Thu, 10/29/09, Valentin Villenave v.villen...@gmail.com wrote: From: Valentin Villenave v.villen...@gmail.com Subject: Re: SystemStartBrace doesn't stretch vertically To: Jonathan Wilkes jancs...@yahoo.com Cc: bug-lilypond@gnu.org Date: Thursday, October 29, 2009, 1:07 PM On Thu, Oct 29, 2009 at 11:16 AM, Valentin Villenave v.villen...@gmail.com wrote: I'm not sure it's the appropriate engraving tradition (vertically-stretched braces could look quite awful IMHO). Could you find some example in a printed score, and send us the scan? Oops, I just found your Debussy link. Never mind -- though I do think that this example looks awful, but you do have a point nevertheless :-) Yes, definitely not an example to use as a model, but it gets the point across. I have a Henle edition somewhere around and when I find it I'll examine their brackets more closely. -Jonathan Added as http://code.google.com/p/lilypond/issues/detail?id=889 Cheers, Valentin ___ bug-lilypond mailing list bug-lilypond@gnu.org http://lists.gnu.org/mailman/listinfo/bug-lilypond
Re: Spacing bug: text exceeding page footer
Le 29 oct. 09 à 10:32, Valentin Villenave a écrit : On Sun, Sep 13, 2009 at 6:30 PM, Nicolas Sceaux nicolas.sce...@free.fr wrote: %%% in the first page, text spread on the page footer (and beyond) %%% before breaking to the next one. Hi Nicolas, it took me a while, but it's finally been added as http://code.google.com/p/lilypond/issues/detail?id=876 Sorry for the delay :) Valentin Actually, I added it myself some time ago, and Joe have already fixed it. ___ bug-lilypond mailing list bug-lilypond@gnu.org http://lists.gnu.org/mailman/listinfo/bug-lilypond
Re: Incorrect point-and-click URIs of files with non-ASCII content on Windows
2009/10/29 Valentin Villenave v.villen...@gmail.com: 2009/10/29 Harmath Dénes harmathde...@gmail.com: No, the two are very different. In http://code.google.com/p/lilypond/issues/detail?id=887, the _filename_ part of the URIs is wrong because of non-ASCII _filenames_. In this bug (http://article.gmane.org/gmane.comp.gnu.lilypond.bugs/16097), the _column position_ part of the URIs is wrong because of non-ASCII _content_. Interesting. Patrick, doesn't it look a lot like David's report on http://lists.gnu.org/archive/html/bug-lilypond/2009-10/msg00049.html ? It is very similar, and the problem probably stems from the same function, namely Source_file::get_counts(). Anyway, as mentioned, the latter is more general, and is related to not the PDF generation, but the position calculation, since it occurs in command-line compiler errors too. Yes, which is why I'd like to know if Patrick's recent work on David's report could have affected this one as well. It *should* have an effect. But if I'm thinking about this correctly, there will still be an off-by-one error in the character/column counts, because my commit only affects the value of the character count when non-ASCII characters are found. -Patrick ___ bug-lilypond mailing list bug-lilypond@gnu.org http://lists.gnu.org/mailman/listinfo/bug-lilypond
Re: Issue 882 in lilypond: Markup columns collisions
Comment #1 on issue 882 by n.puttock: Markup columns collisions http://code.google.com/p/lilypond/issues/detail?id=882 Duplicate of #732. -- You received this message because you are listed in the owner or CC fields of this issue, or because you starred this issue. You may adjust your issue notification preferences at: http://code.google.com/hosting/settings ___ bug-lilypond mailing list bug-lilypond@gnu.org http://lists.gnu.org/mailman/listinfo/bug-lilypond
Re: Bad dimensions for \bracket
2009/10/29 David Kastrup d...@gnu.org: Bug 882 may or may not be related, and may or may not be a bug, but this discrepancy in the context of brackets _is_ a bug. This bug looks like #807, which has a patch pending. Regards, Neil ___ bug-lilypond mailing list bug-lilypond@gnu.org http://lists.gnu.org/mailman/listinfo/bug-lilypond
Re: wrong beaming of dotted 8th followed by 8ths
Valentin Villenave wrote Thursday, October 29, 2009 10:32 AM On Sat, Oct 3, 2009 at 12:41 AM, luis jure l...@internet.com.uy wrote: Hi Luis, sorry for the delay, % this shows the default beaming and how it should be beamed r16 c8. c8 c r16 c8. c8[ c] | I'm not sure what to do. The first half of the measure does look ugly indeed (see attached), but I can't decide whether it's a bug or not. Trevor, what would you do? (I'm asking you because beaming is kind of your speciality now, isn't it? ;-) Not really; Carl developed all the new beaming code. But if you really want my opinion I believe this should be classed as an enhancement, namely to take rests into account when determining the shortest note in the beaming interval. It should be a switchable option to preserve the current behaviour and to accommodate both preferences, as I don't believe there is a generally accepted rule here. Bug 638 is related, as solutions to that and this require a different approach to beaming - one which assesses the duration of notes (and rests) within a whole bar before selecting the most appropriate beaming for that bar. Valentin Trevor ___ bug-lilypond mailing list bug-lilypond@gnu.org http://lists.gnu.org/mailman/listinfo/bug-lilypond
Re: Bad dimensions for \bracket
On Thu, Oct 29, 2009 at 11:08 PM, Neil Puttock n.putt...@gmail.com wrote: This bug looks like #807, which has a patch pending. Indeed. But what about #882 then? Cheers, Valentin ___ bug-lilypond mailing list bug-lilypond@gnu.org http://lists.gnu.org/mailman/listinfo/bug-lilypond
Re: Issue 850 in lilypond: Vertical spacing: text lines exceeding page bottom
Comment #3 on issue 850 by v.villenave: Vertical spacing: text lines exceeding page bottom http://code.google.com/p/lilypond/issues/detail?id=850 Issue 876 has been merged into this issue. -- You received this message because you are listed in the owner or CC fields of this issue, or because you starred this issue. You may adjust your issue notification preferences at: http://code.google.com/hosting/settings ___ bug-lilypond mailing list bug-lilypond@gnu.org http://lists.gnu.org/mailman/listinfo/bug-lilypond
Re: Issue 876 in lilypond: Spacing bug: text exceeding page footer
Updates: Status: Duplicate Mergedinto: 850 Comment #2 on issue 876 by v.villenave: Spacing bug: text exceeding page footer http://code.google.com/p/lilypond/issues/detail?id=876 Indeed. Sorry for the noise. -- You received this message because you are listed in the owner or CC fields of this issue, or because you starred this issue. You may adjust your issue notification preferences at: http://code.google.com/hosting/settings ___ bug-lilypond mailing list bug-lilypond@gnu.org http://lists.gnu.org/mailman/listinfo/bug-lilypond
Re: Issue 882 in lilypond: Markup columns collisions
Updates: Status: Duplicate Mergedinto: 732 Comment #2 on issue 882 by v.villenave: Markup columns collisions http://code.google.com/p/lilypond/issues/detail?id=882 Indeed. I did find 732, but it's described in a more complex way and I didn't make the connection. -- You received this message because you are listed in the owner or CC fields of this issue, or because you starred this issue. You may adjust your issue notification preferences at: http://code.google.com/hosting/settings ___ bug-lilypond mailing list bug-lilypond@gnu.org http://lists.gnu.org/mailman/listinfo/bug-lilypond
Re: Issue 732 in lilypond: Alignment problems when vertically stacking horizontally centered stencils.
Comment #1 on issue 732 by v.villenave: Alignment problems when vertically stacking horizontally centered stencils. http://code.google.com/p/lilypond/issues/detail?id=732 Issue 882 has been merged into this issue. -- You received this message because you are listed in the owner or CC fields of this issue, or because you starred this issue. You may adjust your issue notification preferences at: http://code.google.com/hosting/settings ___ bug-lilypond mailing list bug-lilypond@gnu.org http://lists.gnu.org/mailman/listinfo/bug-lilypond
Re: Incorrect point-and-click URIs of files with non-ASCII content on Windows
On 2009-10-29, Harmath Dénes wrote: On 2009.10.29., at 22:12, Patrick McCarty wrote: It *should* have an effect. But if I'm thinking about this correctly, there will still be an off-by-one error in the character/column counts, because my commit only affects the value of the character count when non-ASCII characters are found. I don't understand this completely, but it doesn't matter, if the column number in the error messages and at least one of the column numbers in the point-and-click hyperlinks will be right. I see the reason for confusion now. Let me outline the various cases: 1) All ASCII characters. In this case, the character and column will always be the same, as in 3:10:10. 2) Tab characters. When tabs are used, the column number is typically greater than the character number (unless you use a tab that is one character wide). An example might be 1:1:8. 3) UTF-8 characters. In UTF-8 locales, terminals need to know about the byte offset, so I am using the character count to specify this offset. An example would be 3:11:10. The third case is arguably misleading, so maybe it should be changed to use the 3:10:10 instead. I am okay with either format. If we want to use 3:10:10 instead, then an additional parameter would be needed to calculate the byte offset. -Patrick ___ bug-lilypond mailing list bug-lilypond@gnu.org http://lists.gnu.org/mailman/listinfo/bug-lilypond
