Originally created by: *anonymous
Originally created by: janek.li...@gmail.com
Originally owned by: mts...@gmail.com
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?
Issues: #1713
Issues: #2638
Issues: #2910
Issues: #3160
Originally posted by: x.sche...@gmail.com
Issue 650 and issue 651 could be merged into this issue, IMHO.
Janek, Mike or Werner, thoughts?
Originally posted by: m...@mikesolomon.org
For the brave of heart, I have been composing animated scores for a gig in february that have required me to use more accurate outline information. A sketch is up on http://www.youtube.com/watch?v=9j02mVRksdI (best viewed in full screen).
The code to make this is in Python, so I'd need to port it over to C++. And by I, I mean "I'd need a team of 3-4 people" - I don't have time to spearhead a rewrite of the Stencil and Skyline class. If I get 3-4 volunteers, then we can get this thing done in a few months: the good news is that it's really just these two classes that'd need overhaul - one wouldn't need to change method names, but rather create overloaded functions for more specific outlines and change the way distances are calculated under the hood.
Originally posted by: janek.li...@gmail.com
2012/1/1 Comment #2 on issue 2148 by m...@apollinemike.com: object
outlines shouldn't
Haha! That's nice! Have you considered speeding it up a bit,
however? It gets a bit repetitive, from the viewer's perspective.
You know my skills. If they are sufficient, count me in.
Łukaszu, would you join us? :)
Originally posted by: janek.li...@gmail.com
I don't think that issue 650 or issue 651 should be merged into issue
2148. Sure, fixing 2148 would improve situation in these, but the
problem is that volta brackets and broken hairpins should indeed start
a bit later. Look at second system in the example attached to issue
650: non-rectangular outlines would make situation better, but the
hairpin would still begin above key signature.
Originally posted by: m...@mikesolomon.org
It's just a proof of concept to show that the technology works - I have yet to do anything interesting creatively with it :)
As for your skill set, I have an idea more or less of where you are in C++. Can you send me an e-mail off list w/ what you do and don't know how to do? I can delegate based on that.
Originally posted by: milimet...@gmail.com
Mike, could you please explain, why your Python script will help in fixing Lilypond? As I suspect, you have written the whole code that computed all distances between notes on your own, while in Lilypond the code is already written and can't be rewritten at once, because it's too big and too complicated.
Originally posted by: m...@mikesolomon.org
The good news is that the code is not too big and complicated in LilyPond - it's well segmented, and most of what'd need to be changed is the Skyline class.
My python script is a series of functions that, amongst other things, do coordinate geometry with 2D lines and Bezier curves. It can find distances between and intersections of objects. This'd need to be ported over to the Skyline class, which currently uses boxes to approximate forms.
However, I'm not certain this would have a real impact on LilyPond - using 20ish boxes for a glyph in the Feta font seems like more than enough. These distances would only be useful once (if) LilyPond implements more sophisticated layout managers.
Originally posted by: lemzw...@googlemail.com
Relying on the outline alone is definitely *not* correct, at least for feta glyphs: Some objects need more whitespace around certain features due to aesthetical reasons.
I have suggested to add some METAFONT code to construct skylines for all glyphs some years ago; you might look into the following thread:
http://lists.gnu.org/archive/html/lilypond-devel/2006-11/msg00162.html
Adding `hsky' and `vsky' SFNT tables (or any equivalent) to the feta font is still the right thing to do IMHO.
Originally posted by: janek.li...@gmail.com
Mike found an interesting website
http://www.cgal.org/
It is a plane-geometry package that looks not-too-hard to use. Amongst other things, it allows to calculate distances between curves on a plane.
http://www.cgal.org/Manual/3.3/doc_html/cgal_manual/Arrangement_2/Chapter_main.html
Originally posted by: mts...@gmail.com
Issue 650 has been merged into this issue.
Originally posted by: mts...@gmail.com
Issue 651 has been merged into this issue.
Originally posted by: mts...@gmail.com
Issue 584 has been merged into this issue.
Originally posted by: mts...@gmail.com
Gets vertical skylines from grob stencils
http://codereview.appspot.com/5626052
Labels: Patch-new
Originally posted by: mts...@gmail.com
I've done all of this merging so that we can resort these issues based on how LilyPond code is actually written.
The vast majority of outline problems come from outside-staff-priority sorting. So, I'm going to rename this issue "vertical skylines should use integrals of stencils at all stages of their construction"
The dot issue is thus separate because it is not based on vertical skylines. Dot positioning is its own monster with its own code. It is a 20-30 line fix using elements of the present patch but should be addressed separately.
The only example given that is really really really hard to solve in lilypond is "lyrics padding." Any stencil that gets eaten up by pango is very hard to break down into smaller boxes. Thus, once this issue is closed, a new one should be opened up: "glyph-string stencil has monolithic box approximation".
Could you post the code for the slur and "lyric extender padding" stuff so I can develop the current patch against it?
Summary: vertical skylines should use stencil integrals
Originally posted by: mts...@gmail.com
Gets vertical skylines from grob stencils
http://codereview.appspot.com/5626052
Originally posted by: mts...@gmail.com
Gets vertical skylines from grob stencils
http://codereview.appspot.com/5626052
Originally posted by: dak@gnu.org
Patchy the autobot says: make check fails, will see if I can find more useful data in the log. And still 7 lines add whitespace errors.
Labels: Patch-needs_work
Originally posted by: dak@gnu.org
Failure log attached.
Originally posted by: mts...@gmail.com
Gets vertical skylines from grob stencils
http://codereview.appspot.com/5626052
Labels: -Patch-needs_work Patch-new
Originally posted by: mts...@gmail.com
Gets vertical skylines from grob stencils
http://codereview.appspot.com/5626052
Originally posted by: janek.li...@gmail.com
WOW! This is waaaaay cool!!!
Mike wrote:
"Could you post the code for the slur and "lyric extender padding" stuff so I can develop the current patch against it?"
I've discovered now that lyric extenders are actually totally fine. The ugly output in 'lyric extender padding - bad outlines' was caused by slur and lyrics outlines - see attachment; it's already better thanks to your fix for issue 695.
And what do you mean by "slur stuff"?
PS i usually attach source code to pdfs (inside-pdf-attachment).
Originally posted by: mts...@gmail.com
Gets vertical skylines from grob stencils
http://codereview.appspot.com/5626052
Originally posted by: m...@mikesolomon.org
I don't need the stuff from the examples anymore...thanks tho!
I'm gonna take care of all the stencil clean up first before expanding much on this patch.
The goal then is to give TextScripts vertical skylines via this patch, which will be possible after the stencil cleanup.
Originally posted by: mts...@gmail.com
Gets vertical skylines from grob stencils
http://codereview.appspot.com/5626052
Originally posted by: mts...@gmail.com
Gets vertical skylines from grob stencils
http://codereview.appspot.com/5626052