lilypond-auto
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

[Lilypond-auto] [LilyIssues-auto] [testlilyissues:issues] #5210 LyricHyp


From: Auto mailings of changes to Lily Issues via Testlilyissues-auto
Subject: [Lilypond-auto] [LilyIssues-auto] [testlilyissues:issues] #5210 LyricHyphen improvements: Accept hyphen markup, fuzzy-metrics
Date: Fri, 06 Oct 2017 10:28:57 +0000

This is mixing up a number of issues into a single patch/review. That makes it impossible to

a) review them independently based on their respective merits
b) cherry-pick them to stable independently based on their respective invasiveness
c) Use git bisect for figuring out the root cause of a problem

Of course, the last point could be addressed by at least structuring the issue into separate commits. It turns out that our Rietveld-based review system is pretty bad suited for reviewing that kind of multi-commit submission. We tend to simulate a multi-commit review by sending successive patches to the same Rietveld review for stuff containing a convert-ly rule with extensive scope: in that case one wants to look at the results of the mechanical application of the convert-ly rule separately from human-performed changes.

Of course, once actual corrections are then applied, the review becomes rather murky.

So in a nutshell: please try to place independent features and fixes into independent reviews. Sometimes there are interdependent features/fixes that need to be applied in sequence or that even cannot stand on their own. In that case, most of the listed points above don't apply and one cannot do better than doing a single review and a single commit, but that single commit still might be a merge commit of several changes not working independently. Reviewing such a substructured commit is not really something that works well on Rietveld: often the commit structure is then only established by the programmer pushing in an appropriate manner.

Thanks for this work, it does look exciting!


[issues:#5210] LyricHyphen improvements: Accept hyphen markup, fuzzy-metrics

Status: Started
Created: Wed Oct 04, 2017 11:37 AM UTC by Knut Petersen
Last Updated: Thu Oct 05, 2017 04:24 PM UTC
Owner: Knut Petersen

LyricHyphen: Use markup as hyphen, introduce 'fuzzy-metrics

We use a LyricHyphen grob constructed from rounded-boxes.
That is fine with a lot of fonts, but it is ugly if you use
e.g. Minion, a font that resembles handwriting, or a font
of the Fraktur family.

If a song with multiple stanzas is engraved, the position of
hyphens is far from optimal, especially at the start and end
of lines.

This patch

As long as neither 'text nor 'fuzzy-metrics is used, the output
is identical or similar to the old style. The number of hyphens
used might change as padding is always obeyed, it might change
as we reserve enough space at the end of a line for a shortend
rounded-box hyphen. That way a hyphen never will stick out to
the right of a system.

We also silently correct some minor/coding problems:


Sent from sourceforge.net because address@hidden is subscribed to https://sourceforge.net/p/testlilyissues/issues/

To unsubscribe from further messages, a project admin can change settings at https://sourceforge.net/p/testlilyissues/admin/issues/options. Or, if this is a mailing list, you can unsubscribe from the mailing list.

------------------------------------------------------------------------------
Check out the vibrant tech community on one of the world's most
engaging tech sites, Slashdot.org! http://sdm.link/slashdot
_______________________________________________
Testlilyissues-auto mailing list
address@hidden
https://lists.sourceforge.net/lists/listinfo/testlilyissues-auto

reply via email to

[Prev in Thread] Current Thread [Next in Thread]