print: Remove color mode override

[juli27]

Resolves: #30515

I was in this area of the code somewhat recently (while experimenting with a Windows print provider¹), so I immediately had an idea which line could be causing the behavior mentioned in the issue. However, I couldn't verify the fix because none of my printers support the system color setting.

The call to QPrinter::setColorMode seems unnecessary (it stems from the initial commit²)

• I signed the CLA
• The title of the PR describes the problem it addresses
• Each commit's message describes its purpose and effects, and references the issue it resolves
• If changes are extensive, there is a sequence of easily reviewable commits
• The code in the PR follows the coding rules
• There are no unnecessary changes
• The code compiles and runs on my machine, preferably after each commit individually
• I created a unit test or vtest to verify the changes I made (if applicable)

Footnotes

1. https://github.com/juli27/MuseScore/tree/modernizePrintingWindows ↩

2. https://github.com/musescore/MuseScore/blame/v3.6.2/mscore/file.cpp#L1831 ↩

[cbjeukendrup]

@DmitryArefiev It was reported here that this indeed fixes the linked issue, but it would be good to do a quick regression check (check that scores are not unexpectedly printed in black and white instead of in colour)
It seems highly unlikely to me that there are regressions, but let's check it anyway, so that we can add it to 4.6.3 (it's a Hal Leonard requirement)

[Jojo-Schmitz]

Maybe it should even default to GrayScale?
Or get set to GrayScale if the score doesn't use any colors (expect black and maybe shades of gray)? Would certainly save precious ink.

[juli27]

I don't think defaulting to greyscale is a good idea. A user who is used to their default settings might be surprised by the lack of color (which is much more noticeable than printing a grayscale score with color) and might result in them needing to print again with corrected settings.
If there were a method to quickly check that no colors are used in the score, then yes, that would be nice. But I don't think there's a way to easily check that.

[Jojo-Schmitz]

True, this should be done for b/w scores only

[cbjeukendrup]

If I understand correctly how cymk works, I think it would make more sense to ensure that rgb(0, 0, 0) is always converted to cymk(0%, 0%, 0%, 100%) rather than cymk(100%, 100%, 100%, 100%), regardless of whether the score also contains elements that are not black.
(But needles to say, that's for a different PR)

[Jojo-Schmitz]

Ah, yes, that should sort the ink waste

[DmitryArefiev]

It was reported #30515 (comment) that this indeed fixes the linked issue, but it would be good to do a quick regression check (check that scores are not unexpectedly printed in black and white instead of in colour)

@cbjeukendrup Printed on physical printer or virtual printer?
On all OSs?

[cbjeukendrup]

If we want to be really sure, we should perhaps check physical and virtual printer on each OS...

But maybe it's enough to check just physical printer on Windows & Mac.

[DmitryArefiev]

I have only black and white printer..

Checked on built-in virtual printer on Win10, Mac13.7.8, LinuxUbuntu24.04.3. All fine