Turns the previously hard-coded max. distance between multiple dashes
into a user configurable score style.
__References__:
- Issue: https://musescore.org/en/node/88171
- Original request with discussion and screen-shots:
https://musescore.org/en/node/87841
Shamelessly stolen from PR #2294, which needed a non-trivial rebase
This commit removes some -Wempty-body, -Wmaybe-uninitialized, -Wunused-variable, and -Wstrict-overflow compiler warnings that arise on my x86-64 and ARM arch linux machines when compiling release.
These compiler warnings don't seem to cause any bugs, but since they pollute the build output, they make it harder to spot potentially important warnings that might arise, so I'm making these small changes to keep the build output clean.
The "empty-body" warnings occur because the Q_ASSERT statements are removed for release compiles, causing the else blocks to be empty. Surrounding the Q_ASSERT with brackets will let the compiler know we aren't unintentionally having an empty else body.
The "maybe-uninitialized" warnings are handled by assigning the variables to 0 either at initialization or in a switch default block.
The "unused-variable" warning is due to PeriodItem updatePeriods[] in preferences.cpp being defined but never used, so I've removed PeriodItem. Also a recent commit has an unused "int staves", which I've removed.
The "strict-overflow" warning is due to compiler wanting to perform an optimization which would cause signed overflow during a comparison operation. I've made the compiler happy by casting the barIndex'es into unsigned ints, so it doesn't have to worry.
This patch gives better control on lyrics dash management and it is intended to supersede https://github.com/musescore/MuseScore/pull/2213 which did not suit the taste of several forum users; for a discussion, see https://musescore.org/en/node/76021 .
Adds 3 new score style parameters:
- `lyricsDashMinLength` to control the minimum dash length (default: 0.4sp)
- `lyricsDashMaxLength` to control the maximum dash length (default: 0.8sp)
- `lyricsDashForce`: if set to __true__, a dash is always generated between two syllables of a word and, if there is not enough space for the min dash length, more space is added between the syllables to accommodate it; if set to __false__, no extra space is added and the two syllables are joined together (default: true)
The effect of the last parameter is exemplified by the following screen-shots:
Current situation (before this patch); if there is no room for the min dash length, the dash is skipped and some blank is left between syllables:
Patch with `lyricsDashForce = true`; chords are further spaced and a min-length dash is inserted:
Patch with `lyricsDashForce = false`: the second syllable is moved (slightly) to the left to reclaim the blank:
__Background__: When between two lyrics with a dash there is no room for at least a minimal length dash, no dash is drawn at all and a small blank is potentially left between the syllables.
__Fix__: In such a case, this fix shifts the second lyrics left to avoid the blank.
__Notes__:
- This alters slightly the alignment of the lyrics with the note head, the worst case being 0.45sp (0.25 of minimum dash length + 0.1 of padding at either end); however, the greatly improved readability minimizes the impact of this (usually minimal) misalignment.
- kerning between the previous syllable last character and the first character of the next syllable is ignored.
- No provision is made for languages in which hyphenated spelling is different from continuous spelling (examples?)
**Deleting measures** When measures are deleted, spans of lyrics melismas and dashes involved (`LyricsLine`s) were not correctly adjusted.
Also fixes the general case of removing or adding some time span intersecting `LyricsLine` spans.
**Rewriting measures** while rewriting measures (as for time changes), existing `LyricsLine`s were left over and then re-added. Now they are deleted while removing measures (`InsertRemoveMeasures::removeMeasures()`).
When a syll. dash is too short to fit between two syllables, it is skipped. This looks badly at system end, where room for a short dash is usually available within the note-to-barline distance + barline width.
With this patch, a syll. dash at the end of a system is always drawn with at least the shortest acceptable length (or more, if more room is available), even if under normal conditions it would not fit. In a position where the in-word status of a syllable is not easy to guess, the occasional dash (very) slightly extending beyond the bar line seems more acceptable that no dash at all.
This patch also limits the `LyricsLine`-specific correction in `SLine::linePos()` to melisma only, using common processing for syllabic dash lines.
While entering a melisma, the first underscore has no specific visual effect.
This patch displays a short melisma after the first underscore, by setting a conventional non-0 lyrics `_ticks` value.
Note: If no second underscore is entered (edit mode is exited or a new syllable is entered in the following chord), the short melisma is left behind as a left-over. It may be the case to reset to 0 the melisma ticks (= no melisma at all) for instance when the score is saved, or read back.
The melisma line had an undershooting length correction; with the latest change, it is now too short.
Correction changed to overshoot the chord by `minNoteDistance`, as it is definitely less massive than the chord itself.
Also removed a useless test in `line.cpp`.
Implements melisma and dash lines for lyrics spanning several systems.
The melisma and dash line is based on the `SLine` class and its segments on the `LineSegment` class. Both the whole line and its segments are not selectable, marked as generated and not saved in the score file, which is not changed in any way.
For very wide dash segments, several dashes are drawn; the distance between the dashes is not configurable.
Lyrics layout code in `Measure` class and in `layout.cpp` file has been commented out as the lyrics line layout is all contained in the lyrics.cpp file
The line is registered with the `Score` (to have its layout delayed until all elements are positioned) with a mechanism similar to other `Spanner`'s, but in a different container (`_unmanagedSpanner`), as the owning `Lyrics` should decide when create, register, unregister and delete its line.
The line segments are registered with the `System` they belong to (to have them drawn), in the same way as other `Spanner`'s.
There is code for using the dash metrics of the lyrics font, but it is turned off via a conditional directive, as there does not seem to be a reliable way to determine the dash metrics; conventional values (determined by trials and errors and based on my taste!) are used when the conditional directive is off.
