Page Size Units

• Nov 27, 2018 - 13:51
Reported version
3.0
Priority
P2 - Medium
Type
Functional
Frequency
Once
Severity
S3 - Major
Reproducibility
Always
Status
PR created
Regression
No
Workaround
No
Project
MuseScore

I started this as a Feature Request, but not enough people responded, and I believe that this is very important and belongs in the beta. The current UI for page size units is both clumsy and abnormal. MuseScore always defaults to millimeters when you open the program, and then if you change to inches, it keeps the units at inches for the duration of the application session only. This is not normal, and it's very clumsy for those of us who do not use millimeters.

I will define the "standard" UI conventions based on a small review of popular desktop publishing apps. There are two standard UI paradigms for page size units:

1) As a global user preference. Units text appears in various places, but you can only change the units in the user preferences, not in the page settings dialog.
2) As a document property. The units are stored in the file as a single new field in the XML.

MS Office and Apache Open Office use #1. Illustrator and Scribus, the more advanced publishing apps, use #2. My preference is #2, as I like the more advanced approach because I use different units for different scores.

I would like to get consensus on which UI paradigm to use, and then I am willing to code it. Neither one is much coding work. I have already coded the #2 paradigm for a previous PR, so that is easy for me. The user preference is a simple task, if that's the consensus choice.

As I said, I believe this is an important yet neglected feature. It's also very easy to fix. I'm interested in getting some kind of feedback & approval for this task prior to beginning any work. Thanks.

Comments

• Nov 27, 2018 - 16:47

It now occurs to me that there is a third alternative:
3) Both #1 and #2 combined. Add 3 new widgets to the General tab of the Preferences dialog (under a new heading Page Size Units):
a/b) two radio buttons: "Set units globally" versus "Set units by score"
c) a drop-down list of units or a pair of radio buttons similar to the current page settings dialog

It would default to set units globally, using millimeters. Normally the default is determined by the users locale settings. I see that Qt has a QLocale class.
prefs.png

The scope of this #3 implementation is slightly larger than the sum of its two parts, #1 + #2. But it's still relatively small:
- prefsdialog.ui and prefsdialog.cpp changes - new widgets, new setup and event code
- page.cpp changes for #2
- pagesettings.cpp changes to show/hide units based on global radio button settings (#3a/b).
- review/modify the defaulting process for opening files that do not have units specified in them. The #3 defaulting scheme is: If user has "set units by score", default to preset page size's units, or if custom size default to millimeters. If user has "set units globally", then do nothing, rely on the global setting.
- changes to fix the spatium rounding issue. I need to review my previous code on that further. This is a bummer of an issue and requires restructuring the way units are handled. These changes should also fix the related margins issue. It's not a lot of code, but it has downstream implications that must be tested.
- review of the units text everywhere to ensure that it's conforming and translated properly. I remember that being an issue previously. If the user selects "set units by score", then I can resurrect the changes that connect units to each preset page size. It's a nice feature discussed elsewhere, in the Forum posts related to this issue.
- review and testing of any downstream impacts that might be unknown at this time

That's not a big project, and I a volunteering to do it asap.

Attachment Size
prefs.png 48.73 KB

Reply

• Nov 29, 2018 - 17:51

I'm taking a risk by starting to code without any support or approval, but I have some momentum investigating/coding this, and I feel a sense of the urgency due to the upcoming beta. I'm also hoping that continued activity on this issue will garner it some attention. Here are some further notes about how I am proceeding with an implementation of #3, as described in my previous comment. I am choosing #3 because it gives everyone what they might want, which is generally a good thing, and probably easier to get approved. Here is the initial commit for that branch. I have not even compiled the branch yet, so don't expect much:
https://github.com/musescore/MuseScore/compare/master...sidewayss:FIX%2…

First, I have modified mscore/prefsdialog.ui as the previous screenshot illustrates. I have now followed the instructions in preferences.h for adding a new preference: I have modified the _allPreferences map to add two items, both of which have the second argument set to false - I hope that's correct. I have made the radio button a boolean preference, since it is only two radios and bools are the simplest. I set the default to true. For the units value preference I am creating an enum to manage units, along with a map or struct to manage the string display values. The second preference I added, PREF_APP_PAGE_UNITS_VALUE, is an int to align with the new enum here:
https://github.com/sidewayss/MuseScore/blob/8031fc69467d49aadf9e80ebd6a…
It is designed to be a extended ripoff of QPageSize::Unit (see here: http://doc.qt.io/qt-5/qpagesize.html#Unit-enum)
The extensions are for Staff Spaces, which is MuseScore's main internal unit; Pixels, which I desire for SVG/HTML; and Centimeters, which is included in the document properties in the open source app Scribus.

Internally, MuseScore is operating at 5 x 72dpi = 360dpi. QPageSize::Point is at 72dpi, according to the docs. I don't know if we need another unit for points at 360dpi, or if we can simply treat points as being at 360dpi with no negative consequences. Also note that MuseScore uses points for font sizes, but I believe that is in line with the 360dpi setup - I am not certain at this time.
MuseScore has another unit that it uses for XML storage, at least it used to: points @144dpi. I haven't verified if that has changed or not since the 5x multiplier was added and MuseScore started using 360dpi internally.
If you want to really get into HTML/CSS/SVG, you could add Em Space units, which are based on the current font size (HTML defaults to font-size:16px).

QPageSize has the Unit enumeration, and it provides locale-specific preset page size names as strings, but it does not provide any string values for the Unit enum, AFAICT from the docs. So that is something that must be handled inside MuseScore. I have some previous code I can adapt for that, with an array called unitSuffixes:
https://github.com/sidewayss/MuseScore/blob/38cc771932b839a082f6dc7ddac…
Or I can add these units to styleTypes[] in style.cpp here:
https://github.com/sidewayss/MuseScore/blob/8031fc69467d49aadf9e80ebd6a…

I have named the elements of this enum in all caps based on the way things were named 2 years ago. If there is an alternate naming convention now, or if you want to emulate or even truly extend QPageSize::Unit, then let's discuss that. I am going for a simple and reliable solution, but I want this code to be compliant, and I'm not up-to-date on all the conventions.

Reply