Dynamics with offset move right after save
S4 - Minor
1) enter dynamic marking into score
2) apply horizontal or vertical offset
3) save, close MS, and reload file
Result: dynamic marking is further to the right than before reload.
Dynamics with no initial offset seem not to be affected
Confirmed, and the Inspector also shows the discrepancy. That is, apply a horizontal offset of say 4sp to a dynamic, save, then reload. The dynamic now shows an offset of 4.67sp, and is displayed accordingly. Each successive save/reload cycle appears to add another 0.67sp. And it's not just dynamics. I see the same with lyric verse numbers.
Staff text, though, seems unaffected.
Is there any current development on this bug? I am affected for quite a long time now (probably more than half a year) and it is quite annoying with larger scores having many dynamics.
At the moment, dynamics even seem to behave differently; some are moved by 0.66, some only by 0.33.
Thanks for your reply!
I was just pushing someone to take a look a couple of days ago when suddenly all text handling broke with a bunch of changes commited yesterday (eg, dynamics are now huge, adding staff text crashes). I think this needs to be put on hold a moment until all the rest is sorted out, but it's become pretty important for me too.
Insert standard comment about it being inappropriate to use development builds for real work...
Thanks for your reply and thanks for your work, by the way.
... it's just so much more fun to use the development builds (and see all those things improve).
After some investigation, I would say that the problem seems to stem from this:
The default positioning for dynamics was fine-tuned - nicely, overall - by adding a small adjustment to the x-position to center the dynamic. However, when writing the file, the "pos" tag that is written includes this adjustment, and this gets read back in on reload as the initial position - to which the small adjustment is then added again.
I don't know enough about how pos is supposed to be used to know the "right" way to fix this. But I can see that for voltas and chordrests, the userOff is written to the file rather than pos. And when I modify the code so dynamics are handled similarly, it *does* fix the problem.
I imagine there is a good reason why pos is used rather than userOff for most element types. I believe pos uses absolute position, so text style is taken into account. Writing userOff would presumably change some aspect of behavior with respect to style. If someone knows and would like to comment, I'd love to understand all of this better.
Meanwhile, though, I would propose taking the following code in Element::writeProperties():
and replacing the test with:
as a possible fix for this issue, knowing it might well break something else.
Fixed in 97a52fc9ae
Automatically closed -- issue fixed for 2 weeks with no activity.