On Jul 1, 2011, at 7:45 PM, Graham Percival wrote: > On Fri, Jul 01, 2011 at 07:17:08PM +0200, m...@apollinemike.com wrote: >> I'm responding to your e-mail backwards, with answers to the technical >> parts first followed by answers to the broader questions you raise. > > I'll briefly comment on those broader questions. > >> * Have an engraver (by preference written in Scheme) that hooks up the >> glissandi with the stems. > > This might be an ideal way forward -- not necessarily with this > specific issue, but as a general means of extending lilypond. I > think it could be really helpful if we had a few more examples of > how to write + include such scheme engravers. >
I completely agree - I use custom engravers all the time to hook stuff up. Either that or I write stuff in Python that auto-generates LilyPond syntax. >> This was what I originally did, but the crucial issue that arises is that >> of stem direction. Left to its own devices, Lily will pick the direction >> of whatever original arbitrary pitch was chosen, which may be nowhere near >> where the glissando actually falls. > > If we want to push the ideal of custom scheme engravers (and I > don't want to assume that we _do_ want to encourage this approach, > although at the moment I can't think of any problems with it), > then perhaps we need more hooks to pass information around, to > allow "programmer" users to avoid such problems with their custom > scheme engravers. I think information is already very well passed around - a custom engraver can listen to anything, acknowledge anything, create any grob, etc.. As you say above, we just need more examples. The issue in this particular case is subtle. Deep in the optical spacing code (far removed from anything a user could reasonably override or do without), there are decisions made based on a stem's direction, but the direction of a glissando stem cannot be known until the line breaking is done and the full length of the glissando is known. This is also the issue with pure properties, as Joe pointed out a little while ago. Even if this issue has ceased to show itself because of good safeguarding, it is still present. I am a proponent of using mixed integer linear programming to solve these issues. I believe that 100% of LilyPond's spacing could be rewritten as constraints in a linear program, in which case the vertical and horizontal spacing would all happen at the same time, and contingencies like this could be built into the linear program. That'd take a lot of time, but if people were interested, I would love to work on this. It would also make LilyPond more modular because cyclical dependencies could be simply sorted out in the linear program instead of avoid through the nightmare to which Han-Wen alludes when he correctly warns against source code fraught with exceptions. Cheers, MS _______________________________________________ lilypond-devel mailing list lilypond-devel@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-devel
