[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: [Lilypond-auto] Issue 3831 in lilypond: Patch: Improve positioning o
From: |
lilypond |
Subject: |
Re: [Lilypond-auto] Issue 3831 in lilypond: Patch: Improve positioning of tuplet numbers for kneed beams. |
Date: |
Thu, 30 Jan 2014 14:37:58 +0000 |
Comment #4 on issue 3831 by address@hidden: Patch: Improve
positioning of tuplet numbers for kneed beams.
http://code.google.com/p/lilypond/issues/detail?id=3831
I've provided a regtest to show the changes in operation, but I'm attaching
an extensive test file to show in detail what the patch does.
This produces workable results, though I've reached a stage with this that
I'm unsure how to proceed. There is a rudimentary collision detection
system in place here, though it is limited by the fact that X-offset and
Y-offset are considered separately.
Ideally, to detect a collision, both X and Y position are needed. Right
now, I consider collisions with note columns as an approximation of
stem/ledger lines/noteheads, because I don't have the number's Y when I
calculate the horizontal shift. This can move the number in cases where
there's a possibility it might tuck under a notehead.
How do I resolve this? I do query the X-position of the number when
calculating Y-offset, but to also ask for the number's Y-coordinate when
calculating X-offsets (for collision detection) seems like a recipe for
disaster, at least overly optimistic. Ought X- and Y- offset be calculated
together? Is there precedent/need for this?
I have not completely split the positioning of "unbracketed" tuplet numbers
from the bracket-based method. Possibly that is something that needs doing
at some point. The system which uses the bracket (whether visible or not)
produces good results in ordinary single-staff tuplets, and to get
positioning along the beam in cross-staff non-kneed beams, you just need to
override TupletBracket.direction. (Now THAT'S confusing to anyone who
doesn't know that there's always a bracket, invisible or no.)
Possibly there would need to be a split even here if tuplet number quanting
is ever going to be implemented.
Attachments:
kneed-tuplets-test.ly 12.5 KB
--
You received this message because this project is configured to send all
issue notifications to this address.
You may adjust your notification preferences at:
https://code.google.com/hosting/settings
- [Lilypond-auto] Issue 3831 in lilypond: Patch: Improve positioning of tuplet numbers for kneed beams., lilypond, 2014/01/30
- Re: [Lilypond-auto] Issue 3831 in lilypond: Patch: Improve positioning of tuplet numbers for kneed beams., lilypond, 2014/01/30
- Re: [Lilypond-auto] Issue 3831 in lilypond: Patch: Improve positioning of tuplet numbers for kneed beams., lilypond, 2014/01/30
- Re: [Lilypond-auto] Issue 3831 in lilypond: Patch: Improve positioning of tuplet numbers for kneed beams., lilypond, 2014/01/30
- Re: [Lilypond-auto] Issue 3831 in lilypond: Patch: Improve positioning of tuplet numbers for kneed beams.,
lilypond <=
- Re: [Lilypond-auto] Issue 3831 in lilypond: Patch: Improve positioning of tuplet numbers for kneed beams., lilypond, 2014/01/30
- Re: [Lilypond-auto] Issue 3831 in lilypond: Patch: Improve positioning of tuplet numbers for kneed beams., lilypond, 2014/01/30
- Re: [Lilypond-auto] Issue 3831 in lilypond: Patch: Improve positioning of tuplet numbers for kneed beams., lilypond, 2014/01/30
- Re: [Lilypond-auto] Issue 3831 in lilypond: Patch: Improve positioning of tuplet numbers for kneed beams., lilypond, 2014/01/30