Re: sponsorship offer: Lyric fixes (GSoC, etc.)

[David Kastrup]

Kieren MacMillan <address@hidden> 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