MuseScore 3 does not set correct paper size in Linux

Here's how a program can determine default paper size on Linux. Alternatively, we could just default to Letter if the user's locale is set to use Imperial units (inches instead of millimetres), which is one of the many things done in this PR: https://github.com/musescore/MuseScore/pull/4456

Is this by change related to or even a duplicate of #282730: "Untitled"/"My First Score" does not respect locale page size?

FWIW I am encountering this as well. I am not currently able to debug on Linux so I can't say for sure why it's not working. The code in main() seems OK as far as I can tell, it gets a printer with default settings, then checks the page size. I'm kind of guessing isValid(0 is returning false for whatever reason. In my case, it's a PDF printer.

Guess that would be a question for/to the Qt developers?

/etc/papersize may not be reliable. I'm on Ubuntu in the UK, using UK English for language and units. For some reason my /etc/papersize is letter, but if I try to print in any program it correctly defaults to A4 size.

It seems programs ignore /etc/papersize, though I'm not sure what they use instead.

I'd like to see some solution, though, whether using /etc/papersize (presumably if it's wrong on your system, you could then fix it) or maybe providing a preference to override the system default.

Is there any reason we don't just have MuseScore check /etc/papersize on Linux?
There is no such file on e.g. openSUSE, it might be available on Debian based systems only. Therefor a solution depending on the existence of such file might not be that reliable.

Regardless of the local paper size, the user may want to commonly draft sheet music in a different paper size. It makes the most sense to me to make this a user-settable preference.

I'd vote that on first run, musescore takes its best guess as to an appropriate paper size (using /etc/papersize, defined printers, time zone / locale, language, whatever makes sense and with whatever priorities) and either just goes with that or pops up a dialog for the user to confirm the guess, if that seems acceptable.

The user can then change the default at any point later through preferences. With this arrangement, neither they nor musescore need to worry too much about it.

It certainly shouldn't default to something hardcoded if no printer is defined -- I'm in the US and have never configured a printer with lInux in my life, and every time I make a new piece of sheet music I have to remember to change the paper from A4 (correct me if wrong) which is a bummer.

I think the best solution is to ask the user to pick a default paper size as part of the first run wizard, at the same time as choosing language and keyboard layout, etc.

True, even using the same 'check default printer' then (and then only) to set a default might do

Yes, or even decide the default paper size based on chosen locale (Letter for en_US, etc.) or chosen default units (A4 with millimeters). As you say, this should just decide the default value to show in the first run dialog, not the value to use forevermore (unless the user closes the dialog without making an explicit choice).

Since the paper size depends on the music, it might be better to ask for the paper size in the new score wizard.

well, no. A4 vs Letter does not depend on the music. A4 of A3 depends on the instrumentation though
But that's what the templates are for

There's no harm in asking in the New Score Wizard, but we should still ask it on first run so that the default in the NSW is correct. People wouldn't want to have to change the dropdown each and every time they create a new score.

There’s an open bugreport about not using /etc/papersize: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=795442

Unfortunately, the way MuseScore chooses the paper size is not just “use one fix setting”, and resolving this when settings differ is going to be tricky.

I’m sure patches can be accepted if anyone has an idea. Use of libpaper could be a compile-time feature or even a run-time feature (dlopen) using it if present.

Or skip libpaper and just read /etc/papersize manually and use it if it exists and no even-more-overriding value is present. This is the approach I’d favour personally. There’s no harm in using /etc/papersize if it exists even on other distros (and even the Macintosh!).

Both /etc/papersize and libpaper seems to be Debian specific, I haven't none of them in any Linux distribution I know. It seems they don't have a "system wide" default paper size setting but a default paper size per printer (which to me makes more sense :-)).

Asking for a default paper size on the first MuseScore run seems to me the best and safest solution. And maybe present a first guess based on the local of the system.

The desired default paper format should just be asked for on first start of MuseScore and then stored as a preference. Everything else is black magic and/or non-portable and/or error prone as hell.
Just look at #316812: Use a better method than default printer default paper size to determine default page size. and #150601: MuseScore does not open when a network printer is not reachable

From what I hear, “letter” as default in the USA and the larger part of México (as they get paper from the USA), “a4” in pretty much the rest of the world.

Why not read /etc/papersize if it exists, and if so, use it instead of asking?

Because on Windows, as used by the by far largest part of the MuseScore users, there's no such thing. And even on Linux, the by far smallest group, this isn't unversally used

But using it IF it’s there does no harm to those cases you mentioned.

It requires special case coding, for no apparent benefit

For some benefit on some platforms, at no loss on others.

except for code maintainability

Now you’re getting ridiculous. There are far less maintainable places, and this is probably less than a dozen lines, just putting them into the right place is what is tricky.

A dozen lines to save 2% of the users or less a one-time question on the very first start (after intial install or factory reset)? C'mon.

🤦

I'd like to clarify something:

On Windows, this is rarely a problem, because most users have a reasonable default printer, and the scheme works on Windows. It's only a tiny percentage of users who have label printer or something else very quirky set up as their default who run into an issue,. I recall maybe 2 reports of this in the last 10 years (admittedly, both of them in the last week, but still...). So on Windows, yes, /etc/papersize will fail, but that's OK, because the fallback of using the printer is good 99.999% of the time.

As far as I know, the above is equally true of Mac.

But on Linux, the story is very different. The lookup of default printer / default page doesn't work, period - it returns A4 in all cases. So Linux users are always stuck with A4 as the default, and that's just plain wrong for anyone in the US, and maybe Mexico or Canada. In these cases, checking /etc/papersize is a pretty significant improvement. No, it won't catch all cases, because not all Linux distributions support this, but it will catch some. Then we could conceivably check locale or language some such if that file is not present, because that too is going to be more useful than checking the printer since the printer check just doesn't work. All of this could be ifdef linux.

So, with no UI changes at all, we could improve quality of life significantly for a large number of Linux users by checking /etc/papersize and then locale or language, while harming no one.

But, this doesn't help those two people with label printers as their default on Windows, or people in the US on Linux distributions that don't use /etc/papersize and whose language or locale settings don't match what what they would need to for this to work. Or people with their default printer on an unavailable network. So I definitely agree more can and should be done, for some release where UI changes are a possibility,

The idea of doing the check on first startup and asking for confirmation along with keyboard layout etc seems like an easy call to me. It should be the same check I just described - doing what we already do on Windows and macOS since it's pretty reliable (but hopefully detecting network problem and timing out sooner), using /etc/papersize, locale, and/or language on Linux since it's the best we can do. This would provide the initial value for the dialog, then the user can override, and we store that as a preference.

> But, this doesn't help those two people […] in the US on Linux distributions that don't use /etc/papersize

Oh, it does: even if the distribution doesn’t use it, if MuseScore reads it on GNU/Linux (and GNU/kFreeBSD and GNU/Hurd and the BSDs please… so basically anything other than Windows) because it’s a standard on some distributions, people on other distributions can just create the file, even if nothing else on that distro will use it MuseScore will, which can take some pain away.

Not sure a dropdown is sufficient. Maybe a width and height box and a dropdown which fills them in (and a button/toggle to swap between portrait and landscape).

The list of formats supported in /etc/papersize can be viewed in the manpage: https://manpages.debian.org/unstable/libpaper1/papersize.5.en.html

I don't think relying on the default printer is a good idea, even on platform where a default printer is always available.
Just asking the user at install time with a predefined value region based, save in a preference that can be changed later.
Next to that I find a good idea to make the size available in the new score wizard. That would avoid to multiply the templates by the number of sizes that you sometimes use.
(Keeping the possibility to preset that field from a template though).

> people on other distributions can just create the file

True, but this workaround would an extremely unlikely to ever be discovered by most people. So it helps indeed, only a tiny bit. The whole point to me is that this should become more foolproof with no workarounds required. But it is kind of mind-boggling to me that in 2021 this is still an issue. One would think it to be a completely solved problem by now and we would just be able to to use some standardized function like QtGetStandardPageSize() function, or heck even something in C++ standard locale.

Unless we put a note in the handbook: “On nōn-Windows operating systems, MuseScore also checks (link)/etc/papersize to determine the default paper size.”

The locale isn’t the right place for this, while there’s LC_PAPER that particular setting is rarely configured. I wish there was a standard function for this as well, and I think the libpaper/papersize stuff is an attempt at doing that, but, as you can see, people writing software tend to refuse to want to even support that… ;-)

The set of people who read the Handbook is even smaller than the set of users on Linux distributions that don't use /etc/papersize :-)

Chiming in that on my Arch machine, the file /etc/papersize exists, but is empty (with just a comment pointing to the man page about how to set it). So using /etc/papersize only helps for Debian and some other linux distros that properly set it, so I don't think that is common enough to worth implementing. And from reading this thread and online I'd have to conclude there isn't really a single agreed-upon good way on Linux to get a papersize config that has been reliably set properly when the distro was install.

I would also chime in that it is 2021 and more and more musicians just read music pdfs on their phones or tablets, which tend to most commonly have 16:9 or 16:10 screen sizes or higher, or 4:3 as with iPads. And turns out that A4 is better suited for reading on phones or tablets, because they have taller ratios than A4 (except for 4:3 ratio which is between Letter and A4 though maybe closer to Letter):

Letter aspect ratio = 1:1.2941
4:3 aspect ratio = 1:1.333
A4 aspect ratio = 1:1.414
10:16 aspect ratio = 1:1.6
9:16 aspect ratio = 1:1.778

So even if I my computer's configuration says the default paper size is letter, and even though my printer uses letter, I still personally want to override that and set musescore to by default use A4 for new scores considering that most of my scores are just emailed as pdfs to musicians that end up getting read on tablets more often than they get printed on letter paper.

So I'm going to second clepsydrae's proprosal from April 28, 2020 (https://musescore.org/en/node/282736#comment-995745):

> on first run, musescore takes its best guess as to an appropriate paper size (using /etc/papersize, defined printers, time zone / locale, language, whatever makes sense and with whatever priorities) and either just goes with that or pops up a dialog for the user to confirm the guess, if that seems acceptable.

> The user can then change the default at any point later through preferences. With this arrangement, neither they nor musescore need to worry too much about it.

And Chris Collins's Feb 21, 2021 proposal (https://musescore.org/en/node/282736#comment-1059874) is basically that too but in more detail:

> 1. User is asked on first run which paper size they would like to use. It could appear something like: "Please choose the default paper size for new documents: [A4]", with "[A4]" presenting a drop-down list of paper sizes when clicked.
> 2. The initial paper size shown in the dialog would be determined on Linux by checking /etc/papersize first (the vast majority of desktop Linux installations are Debian-based), followed by any other methods that work on Linux (e.g., check default printer if that ever works). This way, a good default may be chosen in case the user dismisses the initial setup question(s) without really reading it.
> 3. "Default paper size for new documents" will be an option in preferences.

I hope we can agree to implement Chris's proposal and end this minor headache. I suppose it has been 13 years since I've been using MuseScore on Linux when this has always been bugging me.