Units: save them by file, by score, or globally for the user
Yes, I am bringing up this topic again. Now that I am back merged with the latest 3.0 code, and I've temporarily given up on my pixels as units enhancement, I am still greatly frustrated by the fact that MuseScore always opens the page settings dialog with units set to millimeter. It saves the user setting of inches for the duration of the user session, but the next time you open MuseScore it's millimeters again, even if the page is US Letter size.
IMO, saving the units by score is the best way, but that idea has been rejected in the past. Still, I make the argument that I might have a score as US Letter, in inches, and another in A10, in millimeters. Why not?
But, if that is not feasible, then at least by user preference. It's very disorienting to come back to millimeters on a US Letter score, if you want to change the margins, for example. You might think there is an error, that the file was saved badly, etc. You might make a change thinking that it is in inches.
(-: It's a very anti-USA stance, if you ask me :-)
...I have to bookend-smiley that kind of silly sarcasm in today's political climate.
Comments
In the same way we figure out whether to use A4 or Letter (by checking the default printer's format), we could switch between millimeter and inch. globally for the user. so just tie A4 to millimeter and Letter to inch.
In reply to In the same way we figure… by Jojo-Schmitz
That is another approach that would work for preset sizes. It leaves out support for custom sizes.
In reply to That is another approach… by sideways
If a user's default paper size is A4, this is like a European, so mm is the default measurement, if it is Letter, inch is the default measurement.
A user can still switch, for the session, just like now,
In reply to If a user's default paper… by Jojo-Schmitz
I understand and agree that it's a good solution for the preset page sizes, but what about custom sizes? And you cannot combine session storage with any of these other options, they conflict in a mutually exclusive way. If I open an A10 score in millimeter, it cannot store millimeter for the session. If it does, then when I open a Letter score, it will be in millimeter. The session storage should go away, it's very non-standard UI behavior for page size units.
Note that all the major desktop publishing applications store the units with the document, as part of the page settings. All of them. I really don't see why MuseScore doesn't do the same. It makes perfect sense. That's why Adobe, Microsoft, Apache Office, and everyone else does it that way. I have never seen another application that does the session storage for units. Can anyone give me another example besides MuseScore? Can anyone name another desktop publishing application that does not store the units in the document file? I don't know of any, and I've used a bunch of them, both open source and commercial. If I'm wrong, then fine, I'll relent, but AFAIK, this particular MuseScore behavior is unnecessarily unique.
In reply to I understand and agree that… by sideways
I'm affraid it is too late to add this to the file format, too late for 3.x, unless we find a way that is fully backward and forward compatible
In reply to I'm affraid it is too latze… by Jojo-Schmitz
I created a way to make it forward and backward compatible as part of my pixels as units PR. It's easy. If there are no units in the file, then you default to the units for that preset page size, as you recommend, or if it's a custom size default to millimeters. Then store the units when you save the file. Piece of cake.
In reply to I created a way to make it… by sideways
The file doesn't have to store values in those units, all it has to do is add a single XML field for page size units. The internal storage in pseudo-points stays the same. All the units conversions stay the same. It's really no big deal when you lay out the specific details.
In reply to I created a way to make it… by sideways
what happens to a file that has these settings when opened in Alpha 2?
In reply to what happens to a file that… by Jojo-Schmitz
Alpha 2 would have to have the code to handle it. That's the enhancement itself. We're talking about 3.0 Alpha, right? I can resurrect my previous code and lay it out here, if that's desirable. It's not a lot of code to store units in the file, including the compatibility check. My previous code has other things going on too, but the units storage and retrieval part is tiny.
In reply to Alpha 2 would have to have… by sideways
We've made the promise to not alter the score format in any incompatible way anymore after Alpha 1 (and yes, I talk about MuseScore 3)
In reply to We've made the promise to… by Jojo-Schmitz
But this has no compatibility ramifications. It can be added at any time using the defaulting mechanism I described.
What Alpha is it right now? 1? or is it already 2?
In reply to But this has no… by sideways
we're at Alpha 2, Beta shortly.
Again: what happens when a file having these settings gets opened in Alpha 1 or 2?
In reply to we're at Alpha 2, Beta… by Jojo-Schmitz
Why would anyone want to open a file with Alpha 2 when there is an Alpha 3 or a Beta available? I don't understand.
In reply to Why would anyone want to… by sideways
Let me go a different direction here. What happens if there is an extra, unknown field in the XML? Doesn't it just ignore it? Or does it choke? This is an extra field, a bottom level field with no children.
In reply to Why would anyone want to… by sideways
right, brain farth on my side I guess
In reply to right, brain farth on my… by Jojo-Schmitz
I visited Germany with my parents when I was 9 years old. Fart is everywhere! Ausfart on the highway was my favorite.
In reply to I visited Germany with my… by sideways
"Ausfahrt" The largest German city, all motorway exists lead to it ;-)
In reply to But this has no… by sideways
Or am I misunderstanding the meaning of compatibility in this context? People are relying on using the Alpha 2 itself or relying on it's file format in some way? I am not sure that makes sense either, but I sense I'm missing something in terms of this compatibility promise.
In reply to Or am I misunderstanding the… by sideways
I'm not really sure about that promise either, maybe it is good enough to be compatible in one direction, at least until final, so be able to read and render properly all files created with Alpha 1 and later.
In reply to We've made the promise to… by Jojo-Schmitz
True, but until beta only in a forward-compatible manner I believed.
Beta scores don't have to be opened with Alpha's, but Alphas must work consistently in Beta.
In reply to True, but until beta only in… by jeetee
OK, sounds reasonable
In reply to Alpha 2 would have to have… by sideways
FYI - I believe I also added a units field to the struct that contains all the preset page sizes, as you are originally suggesting. I can resurrect that too. I believe I even ran it through the whole translation formatting process at one point. It has been a while, so I'd have to checkout the final branch and look around.
In reply to In the same way we figure… by Jojo-Schmitz
OK, I'm bringing the topic back to a high level thread position.
First, I think Nicolas and Werner need to weigh in, because they were the ones who originally objected to the possibility of storing units in the file. It was in a whole separate context then, and well over a year ago, so maybe the resistance is less now.
I reiterate and consolidate my strongest points in favor of storing units in the file:
1) MuseScore is alone among desktop publishing applications in this behavior. Please show me another desktop application that does NOT store the units in the document file. I have never seen one.
2) Compatibility is a snap. It's a single new bottom-level (aka leaf level or level zero) field in the XML. A defaulting mechanism, based on preset page size, handles backwards compatibility.
3) I already have code that I can resurrect and adapt to this purpose, and it's tiny.
Or are there any other solutions to this confusing UI behavior? I think this is the most mainstream change you could make, but so far that's just my opinion.
In reply to OK, I'm bringing the topic… by sideways
I agree with sideways. American paper sizes should default to inches, not millimeters. I'm the one who wanted to make sure my alpha files could be opened in the final release, so Anatoly-os froze the file format. I'm not worried about opening a final file in an alpha release, I don't even have them on my computer any more.
I have reviewed my old code on this subject. The code to write the new XML key/value is in PageFormat::write(), and is straightforward. The code to read the new XML key/value is in PageFormat::read(), as you might expect. Those are simple changes.
I also created a new enum for different units, Ms::Units, and built a small amount of infrastructure around that for handling the units text and the translations of that text. I think it's a good idea to build it that way for the day when additional units might be available. Staff space is already an additional unit that MuseScore is using internally.
Beyond that it's all about selecting the correct radio button when you open the page settings dialog, plus a few lines of code in the event handlers for page size and the units radio buttons.
Should I simply create a PR now and risk rejection of the whole concept? Now is the time to make such a change. I think it's an important enough, obvious enough change that I am willing to take time out from other projects to create the PR and test it. But I'd really like to get more feedback prior to submitting the PR...
Here are examples of additional units available in other desktop publishing applications:
Points (pt)
Picas(p)
Centimeters(cm)
Cicero(c)
And I would still like to add Pixels (px) at some point.
I do now see that Apache Office Writer makes the units a user preference. In MS Word too. So it's the more advance apps like Scribus and Illustrator that save the units with the file. My case is not quite as strong as I thought, but I still think it's a good idea. Or it should become a user preference as with OpenOffice and MS Office. The current state is very user-unfriendly for anyone that deals with anything but millimeters.
OK, another summary:
The current UI for page size units is clumsy and abnormal. There are two "standard" options for handling page size units:
1) 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.
The more advanced apps, like Illustrator and Scribus, use the #2 method. The more basic apps, like MS Word and Open Office Writer, use the #1 method.
There are pros and cons to both methods, but both #1 and #2 are a big improvement over MuseScore's unusual current user interface. How can I push to get a decision made so that this can get into the beta? Even if it's #1 that's the solution, I'm fine with coding it because it alleviates a regular pain in my neck.
I have created a new issue for this, and it ties into existing bugs in v2 and v3 of MuseScore. The page settings treatment of page size units needs serious change in order to resolve issues I raised 2.5 years ago that never got resolved (partly because my PR to solve them was too broad and got rejected). See these issues:
https://musescore.org/en/node/278887
https://musescore.org/en/node/278889
https://musescore.org/en/node/108196
That last link references various other related bugs that have yet to be addressed, but are all tied into the dysfunctional treatment of page size units. Incorrect margins, spatium, SVG matrix transforms, and more result from this simple but serious problem.
I am now digging into this issue further, and wanted to report back within the context of this discussion. Since I last reviewed this code 2 years ago, it has changed in a way that already supports the feature of linking units to the preset page sizes. The code now does this in pagesettings.cpp:
https://github.com/musescore/MuseScore/blob/ba21d03c758f1bf0abbd12e1611…
All the items in the drop-down list of preset pages are now instance of QPageSize, which has a feature called
definitionUnitshttp://doc.qt.io/qt-5/qpagesize.html#definitionUnits
So MuseScore is primed for that enhancement.