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 19:58:33 +0000

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++.

'padding might be 0.0, but a negative 'padding is ignored and 0.07 is used instead.

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

 If you don't want a dash, you should

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.


[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: Fri Oct 06, 2017 10:28 AM 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]