Image capture renders text wrong size for some users

• Dec 4, 2018 - 17:30
Reported version
3.0
Priority
P0 - Critical
Type
Functional
Frequency
Once
Severity
S3 - Major
Reproducibility
Always
Status
closed
Regression
No
Workaround
No
Project
MuseScore

When using the "camera" screen-capture tool in MS 3.0, measure numbers, should you have them enabled, are rendered to the image at egregious size. See enclosed.

Attachment Size
MS3MnoFail.png 46.39 KB

Comments

• Dec 4, 2018 - 17:47
Title 3.0 : Screen capture mis-renders measure numbers ⇒ 3.0 : Screen capture mis-renders measure numbers on MS2 import
Status active ⇒ needs info

So please share a score showing the issue.
What OS?

Reply

• Dec 4, 2018 - 18:43
Status active ⇒ needs info

I wished I could buy Windows, I'm using Linux ;-).

Maybe seems to be a Mac issue, isn't reproducible with Linux too:

MNFO.png

Reply

• Dec 4, 2018 - 18:44
Severity S4 - Minor ⇒ S3 - Major
Type Graphical (UI) ⇒ Functional
Priority ⇒ P1 - High

Happens every time for me too, not just measure numbers but also staff text, I'll guess any text. And I'm on Windows.

My theory is it relates to screen scaling for high DPI displays. I also have palettes that are displaying smaller than in 2.x, not everyone sees that. How about you?

Reply

• Dec 4, 2018 - 19:23
Title 3.0 : Screen capture mis-renders measure numbers on MS2 import ⇒ Image capture renders text wrong size for some users

Shouldn't be a new font in general, fwiw, although depending on your system configuration, you might see something different. previously we just used the default system font & size, now we give controls in Edit / Preferences, and depending on whether your system default match what we are now setting, it may or may not match what you were seeing before.

Anyhow, do you know - or can you calculate - your monitor's DPI? Is it a "retina" display? Also, can you verify the problem is all text, all scores?

Reply

• Dec 4, 2018 - 19:29

I do have a retina display, 227 px/in. It does happen for staff text, too. What other types of text would you like to hear about? I would think one repeatable, brand-new failing score would be sufficient (I have hundreds of MS2 scores).

Reply

• Dec 4, 2018 - 19:35

If it helps any, I have a score...

...made from scratch using the String Quartet template that shows this.

...made by using Save as... in a section of empty measures from a 2.3.2 score that shows this. (I don't remember if I used a template for this one).

...imported from 2.3.2 using a symphonic template and accepted reset of defaults that shows it.

I don't normally use the capture tool, so I haven't noticed this before. I tested this on 3 scores from different sources all with the same results.

Reply

• Dec 4, 2018 - 22:17

Thanks, no more scores needed :-). I am 99% sure it's not score-dependent but system-configuration-dependent. That is, those of us who see it at all will see it always, those who don't will see it never. The trick will be figuring out how fix it for everyone without breaking it for anyone.

Reply

• Dec 4, 2018 - 22:55

OK, something else to verify - and please, even people who thought they couldn't reproduce, please check - do you see different results form Ctrl+C (or "Copy" in menu) vs "Save As"? I do. The "Save As" commands (both of them) work fine, only "Copy" produces the issue.

Reply

• Dec 4, 2018 - 23:11

Sure. I can see right where the problem is, we don't do a re-calculation for MScore::pixelRatio on copy as we do for save as. The problem is there are different possible calculations here (PDF vs SVG vs PNG) and frankly it's going to be a bit of trial and error to get it the calculation right everyone on the "copy" operation, which is different still.

Reply

• Dec 4, 2018 - 23:15

Maybe it's more clear here, I copied an image via image capturing and inserted it inside the score and used again the image capturing with "save as" (So yes, I confirm):

MNFOcopied.png

Attachment Size
MNFOcopied.mscz 7.78 KB

Reply

• Dec 25, 2018 - 13:08
Status active ⇒ PR created

I can reproduce this issue on Linux, and my tests show that assigning correct pixel ratio makes the situation better but not perfect. There is also an inconsistency between DPI-related values assigned to the used QImage and to pixelRatio. I made a pull request that should resolve this (at least resolves the issue on my system), see https://github.com/musescore/MuseScore/pull/4490.

Reply

Fix version
3.0.1