Text of wavy glissando collides with line
1. Open attached score (produced in 1.3).
Result: The text of the wavy glissando collides with the line.
Note: Consider the icon in the palette.
Using MuseScore 2.0 Nightly Build (92852b7) - Mac 10.7.5.
Attachment | Size |
---|---|
Text of wavy glissando collides with line.mscz | 1.51 KB |
Text of wavy glissando collides with line.png | 55.78 KB |
Comments
Pull request posted on github ( https://github.com/musescore/MuseScore/pull/365 ).
I have fixed a couple of other small details in wavy glissando formatting.
M.
Is your pull request also a fix of this?: #20970: Glissando collides with elements before note
No, I only dealt with the wavy type, not with spacing issues, as I assumed Soerboe is working on them.
M.
Fixed in e22cc5262a
Hi Miwarre
It's nearly fixed I think, but can you try moving the notes up and down? It still collides a little.
Using MuseScore 2.0 Nightly Build (cd7698d) - Mac 10.7.5.
I asked because in the pull request, you wrote: "The wavy line occasionally collided with final note and was not always centred within the two notes."
The issue I linked to applies to both glissando :).
The wavy case is special because the 'line' is made by a sequence of discrete elements. Occasionally, there was an element too much (no. of elements rounded up). Also the extra space deriving from the elements not filling all the available space was only at the end of the 'line'. These are the wavy-specific details I fixed.
(Your other issue refers to calculating the available space according to the context and applies to both, as you noted. As it seems that Soerboe is working on it, I didn't want to mess it up.)
I didn't notice cases of collision between the text and the wavy line; for me it is fixed. Can you provide an example?
M.
Here's a screencast .
Using MuseScore 2.0 Nightly Build (64783f9) - Mac 10.7.5.
Occasionally the bottom of the 'g' and the top of the 'wave' touch; is it this? Do you always want to see some blank between them?
M.
Yes, that's it.
I'm not sure. What do you think?
Increasing the distance by an additional 'hairy' space is possible for sure. I suspect it will have very little an impact on usual resolutions (ca. 90dpi for screens and 300 dpi for printers), but it is not a reason to do things only partially.
However, I just realized the proper way is probably more complex: currently -- even with the additional space -- it would be enough to increase (or decrease) the glissando text style font size to break the relationship between text and line (and this applies to both the straight and wavy types).
Then, the real solution would be to tie the position of the text to its physical size.
I'll have a look: if it is just a matter of a few arithmetic operations, it would be worth. If this requires more rendering operations, it may have an impact on peformance and I would welcome the advice of some of the core devs if the case is common enough and the improvement in quality would be worth the cost in performance.
M.
Pull request posted on git hub: https://github.com/musescore/MuseScore/pull/367
It was simple and quick (all costly operations were already done for other purposes), so I thought it very worth.
This patch should also fix this other issue related with glissando: #20970: Glissando collides with elements before note, at least for the part about ledger lines. Please report there if the fix is not complete.
M.
Fixed in ceb8bdf256
It still collides.
Using MuseScore 2.0 Nightly Build (aa8f987) - Mac 10.7.5.
Well, there is 'plenty' of room, here:
NOT FOUND: 1
What shall we do?
Here's a screencast .
Using MuseScore 2.0 Nightly Build (f1d4613) - Mac 10.7.5.
There may have been a recent regression with the straight glissando.
Use the first example here to see it.
Using MuseScore 2.0 Nightly Build (0eae1ff) - Mac 10.7.5.
Can you explain where we should look for this regression?
Sorry, the text is now colliding with the line.
Compare the image linked above with the one in the first post here to see how it looked before.
Fixed in e22cc5262a
Fixed in 551fb14ba9
Automatically closed -- issue fixed for 2 weeks with no activity.