Menu
▾
▴
#5210 LyricHyphen improvements: Accept hyphen markup, fuzzy-metrics
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
-
allows to use an arbitrary markup instead of the default
rounded-box-dash that was used in lilypond for ages.
In the most simple case, if you want to use the hyphen
of the lyric font, simply set 'text to "-".
As it is impossible to shorten a markup, 'minimum-distance
is ignored if it is below the natural width of the markup
+ 2 * padding. -
implements a booloean property 'fuzzy-metrics. If set to #t,
'dash-period is only taken as a start value for calculating
the number of individual hyphens to use. That value might
be increased if the space between the borders and the first
hyphen is big, and it will be increased if the result is an
even number of hyphens. With this algorithm it is probable
that the small variations of the length of syllables in
stanzas at a given moment will not change the number of
hyphens choosen. As long as the number of hyphens used is
equal, the output is much nicer than with the old code,
A single hyphen will be centered, otherwise the distance
between the first/last hyphen and the adjacent syllable will
be ('padding + 'length) and a period that distributes the
other hyphens evenly is used. If we are at a line break,
the adjacent hyphen will be separated from the border only
by 'padding.
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:
-
A 'length below 'minimum-length will be interpreted
as'minimum-length. -
A 'dash-period below 'length will be ignored and
'length*1.5 will be used. That's ugly but much
easier to spot than a missing hyphen. At other places
a negative dash-period means "do not print", but here
this is nonsense. If you don't want a dash, you should
omit "--". -
'padding might be 0.0, but a negative 'padding is
ignored and 0.07 is used instead. -
the defaults used with robust_scm2double were changed
according to the defaults defined in define-grobs.scm.
Three example pdfs that demonstrate hyphens in multiple-stanza songs without and with fuzzy-metrics enabled.
Sample: Hugo Distler, Die Tochter der Heide, Fassung 2
PDFs with fuzzy-metrics disabled (not-fuzzy) or fuzzy-metrics enabled and dash-period of the number given behing "fuzzy".
Version ‘fuzzy-7’ looks great!
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
allows to use an arbitrary markup instead of the default
rounded-box-dash that was used in lilypond for ages.
In the most simple case, if you want to use the hyphen
of the lyric font, simply set 'text to "-".
As it is impossible to shorten a markup, 'minimum-distance
is ignored if it is below the natural width of the markup
implements a booloean property 'fuzzy-metrics. If set to #t,
'dash-period is only taken as a start value for calculating
the number of individual hyphens to use. That value might
be increased if the space between the borders and the first
hyphen is big, and it will be increased if the result is an
even number of hyphens. With this algorithm it is probable
that the small variations of the length of syllables in
stanzas at a given moment will not change the number of
hyphens choosen. As long as the number of hyphens used is
equal, the output is much nicer than with the old code,
A single hyphen will be centered, otherwise the distance
between the first/last hyphen and the adjacent syllable will
be ('padding + 'length) and a period that distributes the
other hyphens evenly is used. If we are at a line break,
the adjacent hyphen will be separated from the border only
by 'padding.
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:
A 'length below 'minimum-length will be interpreted
as'minimum-length.
A 'dash-period below 'length will be ignored and
'length*1.5 will be used. That's ugly but much
easier to spot than a missing hyphen. At other places
a negative dash-period means "do not print", but here
this is nonsense. If you don't want a dash, you should
omit "--".
'padding might be 0.0, but a negative 'padding is
ignored and 0.07 is used instead.
the defaults used with robust_scm2double were changed
according to the defaults defined in define-grobs.scm.
Signed-off-by: Knut Petersen knut_petersen@t-online.de
http://codereview.appspot.com/330920043
Passes make, make check and a full make doc.
Patch on countdown for October 8th
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!
Well, yes, I can construct a number of commits from this general overhaul of the lyrichyphen code. If you plan to cherry-pick only parts of it for 2.20 I'll do so. If not I tend to believe that in this case it is easier to review the one full version than to verify a number of different commits that change a number of places over and over again.
The problem with "We also silently correct some minor/coding problems:" is that a number of those corrections are problematic. For one thing, changing all code defaults for robustX2scm to the defaults in the grobs is not serving any purpose: the intent for robustX2scm is to avoid crashes. Providing/tracking best behavior suddenly makes for two places where defaults have to be updated, and they are only documented at the Scheme side. If a value requires fine-tuning/explanation, it should be set and documented with the grob, not hardcoded in C++.
creates a discontinuity. That's inscrutable behavior for calculated values, particularly if calculated values may end up to be numerically zero (consequently small negative values). So if there is sensible behavior for zero values but no sensible behavior for negative values, the default fallback should be 0 rather than 0.07.
Having this in a separate review makes it reasonably easy to find the culprit. Washing everything up in a single review makes it hard for the reviewer.
Then you change the behavior of dash-period with the argument
omit "--".
but
--is semantic information that may be used for other purposes (and it is being used for alignment if I remember correctly). Omitting it is an indication that one is talking about separate words which may not always be the case.So a big "fix hyphens" patch makes it hard to review things, and hard to deal with separate things as separate things when problems are reported. We have in some cases reverted patches when that was the fastest option to recover from disruptive changes, and cramming everything into one patch/commit then causes a whole lot more of a disruption.
I will split the patch into individual patches. We'll discuss the details there.