Re: stemlength II
On Apr 14, 2011, at 11:08 PM, Han-Wen Nienhuys wrote: On Thu, Apr 14, 2011 at 9:00 AM, Phil Holmes m...@philholmes.net wrote: could argue that lengthening a stem to avoid a collision that isn't a collision is a bug, but I wouldn't do so without Mike's input. Hm? A bug with an explanation and a workaround is still a bug as far as I can see. Mike's input may be needed in order to decide whether to OK. http://code.google.com/p/lilypond/issues/detail?id=1613 I am testing a fix for this; it was an oversight of mine. Graham, this issue was exposed due to a (seemingly innocuous) one-line change by Mike. Can I ask that you branch off the 2.14 branch so the release candidate does not get disturbed by other one-liners with unintended effects? If you don't branch off a stable branch, 2.14 will never get finished. I agree - I think that if we branch off 2.14 after we fix the three remaining critical issues (all of which seem to have been recently introduced) and if everyone holds off on pushing new stuff for a bit (my MultiMeasureRest work, for example, won't make it into 2.14.0), we can still sit on it for a week or two before building it with GUB. During this incubation phase, we'd only apply patches that fix critical or high priority problems. Cheers, MS ___ bug-lilypond mailing list bug-lilypond@gnu.org http://lists.gnu.org/mailman/listinfo/bug-lilypond
Re: stemlength II
On Fri, Apr 15, 2011 at 7:30 AM, m...@apollinemike.com m...@apollinemike.com wrote: OK. http://code.google.com/p/lilypond/issues/detail?id=1613 I am testing a fix for this; it was an oversight of mine. Graham, this issue was exposed due to a (seemingly innocuous) one-line change by Mike. Can I ask that you branch off the 2.14 branch so the release candidate does not get disturbed by other one-liners with unintended effects? If you don't branch off a stable branch, 2.14 will never get finished. I agree - I think that if we branch off 2.14 after we fix the three remaining critical issues (all of which seem to have been recently introduced) and if everyone holds off on pushing new stuff for a bit (my MultiMeasureRest work, for example, won't make it into 2.14.0), we can still sit on it for a week or two before building it with GUB. During this incubation phase, we'd only apply patches that fix critical or high priority problems. The beauty of branching off is that nobody needs to hold off anything. You just continue to put stuff in master (2.15.0), and cherry-pick whatever needs to go to 2.14. -- Han-Wen Nienhuys - han...@xs4all.nl - http://www.xs4all.nl/~hanwen ___ bug-lilypond mailing list bug-lilypond@gnu.org http://lists.gnu.org/mailman/listinfo/bug-lilypond
Re: stemlength II
I've just downloaded and installed 13.59 and can confirm what James has
said. Making the 3rd voice:
{
\override Voice.Beam #'collision-voice-only = ##f
s4 s8 fis'' a'' e'' gis'' b' gis'' }
Gets rid of the over-elongated beam.
James,
Are you aware of this being documented anywhere?
Phil Holmes
Bug Squad
James Lowe james.l...@datacore.com wrote in message
news:8c5412f1-675a-4c47-9dad-65caaedb0...@datacore.com...
hello,
.
On 10 Apr 2011, at 17:18, Friedrich Fischer
fried.fisc...@gmail.commailto:fried.fisc...@gmail.com wrote:
This time the stems are really much too long!
Regards FF
\version 2.13.59
\new Staff {
\time 6/8
\key a \major
\clef treble
{ d'' fis''4 d'''16 b'' e'''4. }
\\
{ d'4. e }
\\
\\
{ s4 s8 fis'' a'' e'' gis'' b' gis'' }
}
could this be tied in with
http://codereview.appspot.com/4385047/. ?
I saw a comment from Mike S on Dev that looked like something in
quote.lyhttp://quote.ly might cause elongated stems.
James
___
bug-lilypond mailing list
bug-lilypond@gnu.org
http://lists.gnu.org/mailman/listinfo/bug-lilypond
RE: stemlength II
Hello,
)-Original Message-
)From: bug-lilypond-bounces+james.lowe=datacore@gnu.org
)[mailto:bug-lilypond-bounces+james.lowe=datacore@gnu.org] On
)Behalf Of Phil Holmes
)Sent: 14 April 2011 10:15
)To: bug-lilypond@gnu.org
)Subject: Re: stemlength II
)
)I've just downloaded and installed 13.59 and can confirm what James has
)said. Making the 3rd voice:
)
) {
) \override Voice.Beam #'collision-voice-only = ##f
) s4 s8 fis'' a'' e'' gis'' b' gis'' }
)
)Gets rid of the over-elongated beam.
)
)James,
)
)Are you aware of this being documented anywhere?
)
)
No, but I'm still not sure if this is a bug (either new or existing) unless I
missed something.
Regards
James
___
bug-lilypond mailing list
bug-lilypond@gnu.org
http://lists.gnu.org/mailman/listinfo/bug-lilypond
Re: stemlength II
James Lowe james.l...@datacore.com wrote in message
news:ddfaf00dc0c80042bab7bba1b3838af9109a7...@mail-ftl1.datacoresoftware.com...
Hello,
)-Original Message-
)From: bug-lilypond-bounces+james.lowe=datacore@gnu.org
)[mailto:bug-lilypond-bounces+james.lowe=datacore@gnu.org] On
)Behalf Of Phil Holmes
)Sent: 14 April 2011 10:15
)To: bug-lilypond@gnu.org
)Subject: Re: stemlength II
)
)I've just downloaded and installed 13.59 and can confirm what James has
)said. Making the 3rd voice:
)
) {
) \override Voice.Beam #'collision-voice-only = ##f
) s4 s8 fis'' a'' e'' gis'' b' gis'' }
)
)Gets rid of the over-elongated beam.
)
)James,
)
)Are you aware of this being documented anywhere?
)
)
No, but I'm still not sure if this is a bug (either new or existing)
unless I missed something.
Regards
James
AFAICS it's not a bug. The stem is lengthened to avoid a collision with a
stem in another voice. Unfortunately it didn't collide in the first place.
To allow this to be corrected, Mike allowed the collision avoidance code to
be turned on and off with the override, and using this override with the
above code produces good output. I guess we could argue that lengthening a
stem to avoid a collision that isn't a collision is a bug, but I wouldn't do
so without Mike's input.
--
Phil Holmes
Bug Squad
___
bug-lilypond mailing list
bug-lilypond@gnu.org
http://lists.gnu.org/mailman/listinfo/bug-lilypond
Re: stemlength II
Phil Holmes m...@philholmes.net writes: AFAICS it's not a bug. The stem is lengthened to avoid a collision with a stem in another voice. Unfortunately it didn't collide in the first place. To allow this to be corrected, Mike allowed the collision avoidance code to be turned on and off with the override, and using this override with the above code produces good output. I guess we could argue that lengthening a stem to avoid a collision that isn't a collision is a bug, but I wouldn't do so without Mike's input. Hm? A bug with an explanation and a workaround is still a bug as far as I can see. Mike's input may be needed in order to decide whether to postpone a fix, due to required effort and/or upcoming changes that would address it anyway. As a consequence of such postponement, one might decide to document the workaround as a workaround in such situations. But if Lilypond does something wrong, whether or not we know perfectly well why it does that, it is an issue and should be registered as such without requiring further input. Things are different if the result is deficient, and one can prove that it is physically impossible to do better than that, given the task specified by the input. I have an automated system for typesetting nested layers of footnotes in TeX, and due to the nesting, the _order_ of lower footnote blocks depends on the page break decisions in higher blocks. For every new volume subjected to this system, I get about 10 bug reports per 1000 pages that amount to half the page is left blank! Why doesn't the system put more lines on the previous page?. And the answer is usually something if I move one more line from the main text to the previous page, this makes the layer 2 footnote in this line to the previous page as well. Now we already have a layer 2 footnote anchored in a layer 1 footnote anchored in the main text. Since this layer 2 footnote is anchored in a layer 1 footnote, it will move _behind_ the layer 1 footnote we got moved over from the next page. But since only the last footnote in one layer can be broken across pages, the layer 1 footnote we moved over from the previous page must appear completely. It takes 3 quarters of a page, and even if we split the last footnote in layer 1 (which was on this page to start with), we don't get enough free space to bring the whole of that footnote over. In short: impossible to do better, even though it looks glaringly wrong, and glaringly trivial to fix. Until you actually try doing so in detail. Not because of algorithmic deficiencies, but because the defined task is physically impossible to do better. Even in such a case (which we don't have here as far as I can see), it is a good idea to register an issue, and mark it as invalid with an explanation of the reason. Because it will come up again every month, and it makes sense to point to the invalid issue and the explanation. But if we refuse registering an existing or even an apparent issue, the information about what makes this issue invalid or postponed or whatever else is going to get lost, and needs to be rewritten every time the question appears again. -- David Kastrup ___ bug-lilypond mailing list bug-lilypond@gnu.org http://lists.gnu.org/mailman/listinfo/bug-lilypond
Re: stemlength II
On Apr 14, 2011, at 6:18 AM, James Lowe wrote:
Hello,
)-Original Message-
)From: bug-lilypond-bounces+james.lowe=datacore@gnu.org
)[mailto:bug-lilypond-bounces+james.lowe=datacore@gnu.org] On
)Behalf Of Phil Holmes
)Sent: 14 April 2011 10:15
)To: bug-lilypond@gnu.org
)Subject: Re: stemlength II
)
)I've just downloaded and installed 13.59 and can confirm what James has
)said. Making the 3rd voice:
)
) {
) \override Voice.Beam #'collision-voice-only = ##f
) s4 s8 fis'' a'' e'' gis'' b' gis'' }
)
)Gets rid of the over-elongated beam.
)
)James,
)
)Are you aware of this being documented anywhere?
)
)
No, but I'm still not sure if this is a bug (either new or existing) unless I
missed something.
Regards
James
You'd need:
\override Voice.Beam #'collision-voice-only = ##t
But to me this still seems like a bug - I'm not sure why the stem pulls down
the beam whereas the NoteHead does not.
Try:
\new Staff {
\time 6/8
\key a \major
\clef treble
{ d'' fis''4 d'''16 b'' e'''4. }
\\
{ d'4. e }
\\
\\
{ %\override Voice.Beam #'collision-voice-only = ##t
\override Voice.Beam #'collision-interfaces = #'(beam-interface
clef-interface
inline-accidental-interface
key-signature-interface
note-head-interface
;stem-interface
time-signature-interface)
s4 s8 fis'' a'' e'' gis'' b' gis'' }
}
Cheers,
MS
___
bug-lilypond mailing list
bug-lilypond@gnu.org
http://lists.gnu.org/mailman/listinfo/bug-lilypond
Re: stemlength II
David Kastrup d...@gnu.org wrote in message news:87oc493y5i@fencepost.gnu.org... Phil Holmes m...@philholmes.net writes: AFAICS it's not a bug. The stem is lengthened to avoid a collision with a stem in another voice. Unfortunately it didn't collide in the first place. To allow this to be corrected, Mike allowed the collision avoidance code to be turned on and off with the override, and using this override with the above code produces good output. I guess we could argue that lengthening a stem to avoid a collision that isn't a collision is a bug, but I wouldn't do so without Mike's input. Hm? A bug with an explanation and a workaround is still a bug as far as I can see. Mike's input may be needed in order to decide whether to postpone a fix, due to required effort and/or upcoming changes that would address it anyway. As a consequence of such postponement, one might decide to document the workaround as a workaround in such situations. But if Lilypond does something wrong, whether or not we know perfectly well why it does that, it is an issue and should be registered as such without requiring further input. Things are different if the result is deficient, and one can prove that it is physically impossible to do better than that, given the task specified by the input. I have an automated system for typesetting nested layers of footnotes in TeX, and due to the nesting, the _order_ of lower footnote blocks depends on the page break decisions in higher blocks. For every new volume subjected to this system, I get about 10 bug reports per 1000 pages that amount to half the page is left blank! Why doesn't the system put more lines on the previous page?. And the answer is usually something if I move one more line from the main text to the previous page, this makes the layer 2 footnote in this line to the previous page as well. Now we already have a layer 2 footnote anchored in a layer 1 footnote anchored in the main text. Since this layer 2 footnote is anchored in a layer 1 footnote, it will move _behind_ the layer 1 footnote we got moved over from the next page. But since only the last footnote in one layer can be broken across pages, the layer 1 footnote we moved over from the previous page must appear completely. It takes 3 quarters of a page, and even if we split the last footnote in layer 1 (which was on this page to start with), we don't get enough free space to bring the whole of that footnote over. In short: impossible to do better, even though it looks glaringly wrong, and glaringly trivial to fix. Until you actually try doing so in detail. Not because of algorithmic deficiencies, but because the defined task is physically impossible to do better. Even in such a case (which we don't have here as far as I can see), it is a good idea to register an issue, and mark it as invalid with an explanation of the reason. Because it will come up again every month, and it makes sense to point to the invalid issue and the explanation. But if we refuse registering an existing or even an apparent issue, the information about what makes this issue invalid or postponed or whatever else is going to get lost, and needs to be rewritten every time the question appears again. -- David Kastrup OK. http://code.google.com/p/lilypond/issues/detail?id=1613 -- Phil Holmes Bug Squad ___ bug-lilypond mailing list bug-lilypond@gnu.org http://lists.gnu.org/mailman/listinfo/bug-lilypond
Re: stemlength II
On Thu, Apr 14, 2011 at 9:00 AM, Phil Holmes m...@philholmes.net wrote: could argue that lengthening a stem to avoid a collision that isn't a collision is a bug, but I wouldn't do so without Mike's input. Hm? A bug with an explanation and a workaround is still a bug as far as I can see. Mike's input may be needed in order to decide whether to OK. http://code.google.com/p/lilypond/issues/detail?id=1613 I am testing a fix for this; it was an oversight of mine. Graham, this issue was exposed due to a (seemingly innocuous) one-line change by Mike. Can I ask that you branch off the 2.14 branch so the release candidate does not get disturbed by other one-liners with unintended effects? If you don't branch off a stable branch, 2.14 will never get finished. -- Han-Wen Nienhuys - han...@xs4all.nl - http://www.xs4all.nl/~hanwen ___ bug-lilypond mailing list bug-lilypond@gnu.org http://lists.gnu.org/mailman/listinfo/bug-lilypond
stemlength II
This time the stems are really much too long!
Regards FF
\version 2.13.59
\new Staff {
\time 6/8
\key a \major
\clef treble
{ d'' fis''4 d'''16 b'' e'''4. }
\\
{ d'4. e }
\\
\\
{ s4 s8 fis'' a'' e'' gis'' b' gis'' }
}
--
View this message in context:
http://old.nabble.com/stemlength-II-tp31364477p31364477.html
Sent from the Gnu - Lilypond - Bugs mailing list archive at Nabble.com.
___
bug-lilypond mailing list
bug-lilypond@gnu.org
http://lists.gnu.org/mailman/listinfo/bug-lilypond
Re: stemlength II
hello,
.
On 10 Apr 2011, at 17:18, Friedrich Fischer
fried.fisc...@gmail.commailto:fried.fisc...@gmail.com wrote:
This time the stems are really much too long!
Regards FF
\version 2.13.59
\new Staff {
\time 6/8
\key a \major
\clef treble
{ d'' fis''4 d'''16 b'' e'''4. }
\\
{ d'4. e }
\\
\\
{ s4 s8 fis'' a'' e'' gis'' b' gis'' }
}
could this be tied in with
http://codereview.appspot.com/4385047/. ?
I saw a comment from Mike S on Dev that looked like something in
quote.lyhttp://quote.ly might cause elongated stems.
James
___
bug-lilypond mailing list
bug-lilypond@gnu.org
http://lists.gnu.org/mailman/listinfo/bug-lilypond
