Improving lyric positioning
With this fixed, I'm hoping this topic will elicit discussion and filed issues.
I'm looking at pages 439-40 of 'Behind Bars', particularly the 'Single note for syllable' paragraph.
I would like to draw attention to a post by David Bolton - the first bar of the attached example (produced in 2.0 Beta - 'Hide Empty Staves' to match image) illustrates this.
Using MuseScore 2.0 Nightly Build e2a6fbd - Mac 10.7.5.
| Attachment | Size |
|---|---|
| Improving lyric positioning.mscz | 4.83 KB |
| Improving lyric positioning (Potential result).jpg | 971.09 KB |
| Improving lyric positioning (Actual result).png | 190.62 KB |
Comments
Who else thinks the font of the PNG looks fuzzy?
There are definitely scaling artifacts in the PNG viewed in my browser with my current screen resolution and current browser zoom settings. Then it changes if I zoom in. That's pretty much par for the course with images of text I find. Hard to say what's actually possible / reasonable to expect.
Anyhow, the current layout algorithm is almost completely one note at a time. There is no way for a lyric to sit under two notes without a pretty significant rewrite. We'll probably need to live with this for the foreseeable future.
In reply to There are definitely scaling by Marc Sabatella
So I totally forgot that there *does* exist code to handle this for "regular" (non-hyphenated) melisma, just by adapting the code I wrote to detect & left-align hyphenated melismas. So it might be solvable after all. Could you file this as an issue?
In reply to So I totally forgot that by Marc Sabatella
Done: #33246: Hyphenated melisma requires too much space
Would it address what David said about lyrics not respacing the notes when possible?
Remaining issue: The spacing between lyrics is too close in some examples: "-glewings". What should we do?
In reply to Done: #33246: Hyphenated by chen lung
It's going to be an all or nothing thing here - either syllables with melisma space notes (meaning the *next* note) or they don't (leading to potential collision with the eventual next syllable). I think on average we're better off not spacing and resolving handful of collisions that might result manually, but I guess we'd need to run a bunch of real world scores through to know for sure.
As for spacing between words, that's completely unrelated. Currently I guess some very small amount of padding (perhaps even 0) must be allocated, and we could up that. I suspect this wouldn't be an issue "often" as most measures receive some automatic "stretch", unless they just happen to exactly fill a system. Increasing the padding would probably have an unfortunate ripple effect, as it would increase space unnecessarily in cases where the measure was being stretched already. So again, it would be useful to get a sense for how often this is an issue in real world scores.
In reply to It's going to be an all or by Marc Sabatella
I appreciate the work you've both done to improve notation in MuseScore 2.0!