Am 25. Januar 2015 21:19:26 MEZ, schrieb Keith OHara <k-ohara5...@oco.net>: >Kieren MacMillan <kieren_macmillan <at> sympatico.ca> writes: > >> The linked issue (https://code.google.com/p/lilypond/issues/detail? >id=1228) currently has a >> status of “abandoned” — well, at least the associated patch does, if >not >the whole issue. >> >> Is there a technical reason why the most up-to-date engraver (e.g., >> https://github.com/openlilylib/openlilylib/blob/ >c53380f5ca460d244a017389dc4bcb79a3f04d14/editorial-tools/merge-rests- >engraver/definition.ily) >> has not been (or cannot be) rolled into the main Lilypond codebase? >Or is >it technically sound, and now it's >> only a matter of somebody making an appropriate/official patch and >submitting it? >> > >The latest code looks reasonable. It needs testing and somebody >willing >to potentially modify it to cooperate with the rest of the code. >It sets merged rests to staff-position 0, so it might interfere in >mysterious ways people setting their rests by hand... the automated >testing reveals things like this. > >It is a layer over the existing rest_collision_engraver, so either we >check that each layer has a distinct-enough job that they won't confuse >each other, or integrate the two rest-collision engravers into one. > >I never looked at this patch because from the issue title >"\override RestCollision #'positioning-done = >#merge-rests-on-positioning" >I didn't recognize what problem it was trying to solve, even though I >am >often annoyed by that problem. >I'll try to change the title and add an example of what we want it to >do.
That would be great. It would be a goid thing if LilyPond would do the right thing here without the awkward workarounds. >_______________________________________________ >lilypond-user mailing list >lilypond-user@gnu.org >https://lists.gnu.org/mailman/listinfo/lilypond-user _______________________________________________ lilypond-user mailing list lilypond-user@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-user
