MuseScore 3 does not set correct paper size in Linux

• Jan 25, 2019 - 16:37
Reported version
3.0
Type
Functional
Frequency
Many
Severity
S3 - Major
Reproducibility
Always
Status
active
Regression
Yes
Workaround
No
Project

MuseScore 3 is supposed to get the page size for new scores from the default printer, but new scores always default to "A4" paper size despite all of my printers being set to "Letter" page size. This bug occurs for me on multiple Linux installs using either AppImage or Flatpak versions of MuseScore, but does not happen in Windows.

Here are all of my Linux installs where I've been able to verify the bug (all 64-bit):

  • Desktop: KDE neon User Edition 5.14 (Bionic base)
  • Laptop: KDE neon User Edition 5.14 (Bionic base)
  • VirtualBox: Kubuntu 18.04
  • VirtualBox: Xubuntu 18.04

This bug does not occur with MuseScore 2.

MuseScore version (64-bit): 3.0.2.20546, revision: f494c48


Comments

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.

/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.

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).

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.

If a good paper size is set per-region (e.g., "Letter" in US, "A4" in Europe), then as long as an option to set default paper size exists in preferences, I don't see a need to ask the user about it. Pretty much everyone in the US is going to have letter-size paper in their home printers, and the vast majority of music printed from MuseScore will be sent to a home printer. Those who wish to have their music professionally printed can customize the score and/or default with a different page size if so desired.

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

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.

In reply to by Marc Sabatella

> 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.

I think the thing most people care about is at least having a preference for new documents. If that is done, the details of autoconfiguration become far less important. As it stands currently, in order to have Letter paper size for new documents, I must make a custom style document and set that in "Default Files" in preferences to load with each new project. Not only is this a not-at-all-obvious solution to the problem, but the style sheets must later be manually updated to take advantage of changes in MuseScore's default style, as I recently had to do with the upgrade to 3.6.

Also, regarding auto configuration / asking on first run, how about the following?:
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.

In reply to by mirabilos

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… ;-)