Page Settings: switching to inches distorts staff space

• May 13, 2018 - 03:21

Tested in version 2.1 and 3.0. Steps to reproduce:
1) create a new score of any kind
2) go to Layout/Page Settings... and verify that the Staff space (sp) value is 1.764
3) switch Units from mm to in
4) click OK
5) open the Layout/Page Settings dialog again
6) switch the Unit to mm, and now the Staff space value is 1.753

It may seem like a small difference, but it makes a big difference. Clearly it is what happened in this issue:
https://musescore.org/en/node/16630

I imagine this is a rounding error of some kind. It also rings a bell, like I submitted this same bug a few years ago. I can't remember how it was resolved.
edit - Yes, definitely a rounding error when rounding the staff space value to 3 decimal places for inches. I just did the math. You can round the display for inches, but you cannot round the internal number or it will modify the staff space value inadvertently. You have to keep it all at 4 decimal places, at least 4 decimal places.
edit - I just changed my branch to use 5 decimals, but the mm value starts at 1.76400. It is being rounded elsewhere from 1.76388889. This is funky! Rounding really screws this up. Maybe there is no solution for this, and there was no solution a few years ago when this came up. That's probably one of the reasons why I tried to make Points/Pixels an available unit in this dialog, so that the spatium could be kept at exactly 25.000.

If this is not fixable, then I will submit an issue to increase the page width max to be greater than its current value of 2,000. If maintaining a clean spatium value requires using mm units, then I and others need pages wider then 2,000mm in order to do piano-roll-style horizontally scrolling scores. I have set my branch's max to 20,000 in the Width spinbox on the pagesettings.ui. That seems like a reasonable max at this time, though it could definitely go as high as 99,999, keeping it at 5 digits. I don't think 9,999 is enough, though it will probably suffice for now if you want to limit it to 4 digits to the left of the decimal.


Comments

This comment applies to version 3.0 only.
A further problem: once you have switched units to inches, you can never get the spatium value back to exactly 25.000. Resetting units to millimeter and setting the staff space manually back to 1.764 creates a small rounding error too: 25.002
I am about to recreate an entire score via copy/paste because of this. There's no other way.

Actually, any time you click the Apply or OK buttons, you create this rounding error. The code sets the spatium to the rounded spinbox value * a conversion factor. So even adjusting margins, even pressing OK instead of Cancel causes this:
https://github.com/musescore/MuseScore/blob/396687ce6ad95b9461154b1ee56…

Before the DPI_F = 5 change, this is 5x less of an issue, and if the spatium itself is being rounded to 3 decimals you get exactly 5.000. That's why I say this is not a problem in version 2, though if there's no rounding on the spatium, then it is an issue, just 5x smaller. I don't feel like setting up a version 2 debug build to actually see the spatium value, so I can't be sure.

I am looking at the resulting issues in SVG exports. The clearest example I have is staff lines spacing unevenly. I create a Treble Clef template-based new score, copy in a couple of pages worth of a single staff, then SVG Export it. All the staff lines are evenly spaced. Then I switch to inches and back to millimeters, adjust the staff space back to 1.764 and SVG Export again. Voilà, some of the staff lines are unevenly spaced. The farther down the page you go, the more uneven they get. SVG Export does some rounding on coordinates too, because it reduces file size and load time, and 2 or 3 decimals is the most you'll ever need. Rounding is useful! But it's best when only applied to final results, not a multiplier.

If you need a clean spatium value, you must never change the units or the staff space value in Page Settings. Just leave the default. Maybe I'm in the minority, in terms of people who care about this level of precision, but it seems that there ought to be a way to resolve this without too much work, and I'm certainly willing to chip in.

Do you still have an unanswered question? Please log in first to post your question.