Hey all,
Janek and I talked at length about GSoC and I wanted to give people a little
update about the game plan.
He plans to tackle 2451, 2452, and 2453 first via a parsing of pango strings to
find word prefixes and suffixes and do alignment from where these lie.
2454 will require spacing stubs not unlike the StemStub and SpanBarStub grobs.
He may or may not have been influenced by his mentor's design bias for this :)
Onto 2457, which will require an engraver in the score context to check the
alignment of simultaneous lyrics and override it based on certain melisma
conditions.
2459 can then be tackled by creating positioning-done callbacks for objects in
Dynamics contexts and having an intermediary spanner grob that handles vertical
positioning of these objects.
2455 and 2456 will require an implementation of second-pass spacing after line
breaking that will replace get_line_configuration in spacing-spanner.cc with a
more robust algorithm that respaces the line based on extra spacing
constraints. The idea is that if a more optimal horizontal spacing can be
achieved without resulting in ugly vertical spacing, this'll be done.
2461 can be tackled after this - it is an easy fix once 2455 and 2451-2453 have
been taken care of, as it requires subtle alignment changes on a second
horizontal-spacing pass (ergo 2455) based on the contents of pango strings
(ergo 2451-2453).
Once the second-pass spacing is in place, 2458 will require an extra step -
snap spacing. Snap spacing "snaps" horizontal spacing to certain ideal states
instead of treating it as a continuum. This will remove unwanted small gaps
from lyrics.
The opposite of snap spacing for issue 2462 is target spacing, where all paper
columns of a given length stretch un-uniformly to a given target and then
stretch uniformly after this target instead of stretching uniformly all the
time. This guarantees that short lyrics will be able to catch up to the
spacing of long lyrics on notes of the same duration before these long-lyricked
notes are given more horizontal space.
With this implemented, 2450 will be solvable, as similar-valued notes will be
able to be spaced non-uniformly. The same logic will be generalized to this -
2462 is just an easy test case that allows us to know what works and want
doesn't.
2460 is more or less impossible.
And there you have it! All comments are appreciated - even though I'm the
official mentor, you're certainly all welcome to suggest alternative approaches
to the ones outline about.
Cheers,
MS
_______________________________________________
lilypond-devel mailing list
lilypond-devel@gnu.org
https://lists.gnu.org/mailman/listinfo/lilypond-devel
