Kieren MacMillan <kieren_macmil...@sympatico.ca> writes: > Hi Abraham, > >> Which issues specifically? > > If you look at <http://sourceforge.net/p/testlilyissues/issues/2450/>, > you’ll see a list of other related issues. > > There have been more added since then. > > And I have a few new ones. (At least, I think they’re new… I’d better > look through all 255 [!] issues that come up for a search on ‘lyrics’, > to see what’s what.) > >> What kind of sponsorship we talking about? > > Depends on the precise issue/feature. I spent 8 hours [with the > edition-engraver] tweaking one measure of my current engraving (see > <http://lists.gnu.org/archive/html/lilypond-user/2015-11/msg00477.html>). That > one feature would be worth hundreds of dollars to me, since that one > bar cost me a whole day’s work, and that kind of measure will happen > again and again at the same scale, not to mention hundreds of times at > a smaller scale (e.g., 10 minutes tweaking here, 30 minutes there, 5 > minutes there, etc.). > > I’m sure I can find $1,000 over the course of three years to get my > pet peeves taken care of. > > But I also want to make sure that the larger picture is being > considered at all times. I don’t want to pay $100 for Feature A, then > pay another $100 for Feature B, only to find out that the fix for > Feature B ruins the old fix for Feature A, or they both could have > been handled (possibly for less) if they had been tackled together.
The problem with a bounty-driven approach is that it only works for low-hanging fruit. You cannot pay every passersby interested in a bounty to first start constructing his personal ladder. The majority of the alignment problems (the recent semiquaver/quaver problem is pretty much purely through strict alignment while having to accommodate accidentals) would be approachable by making the respective alignments and distances not strict but rather controlled by springs. Doing that requires a better subdivision of the pure/impure business as well as making springs itself (better?) accessible so that the line-breaking continues working smoothly and integrating such springs. LilyPond's architecture is improving rather gradually and some stuff gets lower-hanging over time. For individual priorities, that may happen too slowly. In this case, there may be a point in paying for local workarounds done within the existing framework, workarounds that don't easily generalize to other areas but can be done in narrower time frames and with less overall work than changing the whole framework would be, even if that means that eventually they might get replaced with simpler solutions. There may be some resistance against such workarounds and I'm probably responsible for a considerable amount of that. At the same time waiting it out until everything in LilyPond has been "done properly" is not much of an option for many people. LilyPond does not fare all that bad in comparison of automated typesetters, but part of the reason is just that others suck even worse and are much more a collection of workarounds. Rearchitecturing LilyPond, particularly its backend responsible for most of the aesthetic work, is slow. Particularly if one tries doing it in a sustainable manner. In some respect, Daniel Spreadbury having the "option" of rewritting a typesetter from scratch at Steinberg after having worked on an existing code base previously is an opportunity. I do suspect that the results will again depend more on local hacks rather than global optimization and positioning frameworks, but at least the hacks will have been provided for from the start and not added after the fact. That may carry further before reaching the equilibrium where every improvement creates an equivalent detriment elsewhere and bits rot as fast as they are added. -- David Kastrup _______________________________________________ lilypond-user mailing list lilypond-user@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-user
