Incorrect size of objects on the Mac Retina 5K screen

[lepr]

9 minutes ago, R C-R said:

Maybe, but it seems to me that the only logical way for this to work would be that "Actual Size" in every context always means display at physical print size, since printed output is the only thing that has any invariant tangible physical dimensions.

Actual Size zoom already does mean display at physical size in every context!!!

It is 100% zoom that has two meanings which depend on context.

[R C-R]

27 minutes ago, walt.farrell said:

What does the Affinity Help on Mac have to say about that?

Basically, it says that when a document is created choosing pixels as the document units will display its exact pixel size when viewed at 100% & for physical document units, it will display the exact print size at 100%.

But it does not do that on my Mac when I choose physical document units -- it is about 97% of true print size.

[lepr]

1 minute ago, R C-R said:

Basically, it says that when a document is created choosing pixels as the document units will display its exact pixel size when viewed at 100% & for physical document units, it will display the exact print size at 100%.

But it does not do that on my Mac when I choose physical document units -- it is about 97% of true print size.

97% of true print size is due to an error (probably in macOS rather than Affinity), but the intent is to be 100% of print size.

[R C-R]

5 minutes ago, anon2 said:

Actual Size zoom already does mean display at physical size in every context!!!

At the physical size of what? At least on my iMac "Actual Size" as displayed for a document I create using inches as the document units is not the same size as the printed version.

[R C-R]

2 minutes ago, anon2 said:

97% of true print size is due to an error (probably in macOS rather than Affinity), but the intent is to be 100% of print size.

If the error is in the macOS, why doesn't Preview app have the same error?

[Gear maker]

My mac is non-retinal, and I use separated mode.  No matter what size window I have Designer running in, zooming to 100% will almost fill the window, regardless of screen size.  Changing my window size changes the 100% image size.  If I use actual size regardless of window size the 5" square is always very close to 5". 

To me that's the difference between 100% and actual size.  100% tries to place whatever size canvas in whatever sized window is being used.  Actual size uses the dimensions of the features to size the display.

[R C-R]

4 minutes ago, Gear maker said:

My mac is non-retinal, and I use separated mode.  No matter what size window I have Designer running in, zooming to 100% will almost fill the window, regardless of screen size. 

It does not work that way for me, either in separated or non-separated mode. What does is "Zoom to Fit" (keyboard shortcut CMD + zero), which I typically use hundreds of times a day.

[Gear maker]

R C-R you are right I was using zoom to fit not 100%.  Sorry.  I get no difference in feature size toggling between cmd 1 and cmd 8.  I guess I've never used cmd 1 before.

[lepr]

 

12 minutes ago, R C-R said:

If the error is in the macOS, why doesn't Preview app have the same error?

Let me get back to you after I've consulted the source code for the Affinity apps and Preview app.

In case the sarcasm eluded you, let me put it another way: how the heck am I going to know which macOS API calls are being made by closed source software?

[lepr]

24 minutes ago, R C-R said:

At the physical size of what?

The physical size of something specified in physical units. A red square that's specified to be 5 inches by 5 inches in a document, for example.

29 minutes ago, R C-R said:

At least on my iMac "Actual Size" as displayed for a document I create using inches as the document units is not the same size as the printed version.

That's an error in a result, not an indication that Actual Size zoom is actually intended to not be actual size.

I'm sure I'm not the only person to suspect that you pretend to be a fool as a means of harassing me.

 

[R C-R]

25 minutes ago, anon2 said:

In case the sarcasm eluded you, let me put it another way: how the heck am I going to know which macOS API calls are being made by closed source software?

Isn't it reasonable to assume that if Preview app can get it right, then the Affinity apps should be able to use the same calls to do the same?

16 minutes ago, anon2 said:

The physical size of something specified in physical units. A red square that's specified to be 5 inches by 5 inches in a document, for example.

I am currently too tired to take this much farther but for me it boils down to this: it does not work for print output the way the help topic says it should on Macs. Apparently it does on Windows. I would like it to work the same way everywhere, such that a 5 inch red square at "Actual Size" is exactly 5 inches square on my Mac's display instead of being slightly smaller than the actual printed output. 

Anything else does not, at least to me, conform to any reasonable interpretation of the meaning of "actual size."

[lepr]

18 hours ago, R C-R said:

Isn't it reasonable to assume that if Preview app can get it right, then the Affinity apps should be able to use the same calls to do the same?

Let's get one thing straight: I suggested that Affinity's Actual Size zoom resulting in only 97% of actual size on the screen of some (if not all) 27 inch iMacs,  was probably the result of a macOS error, not definitely a macOS error.

It is reasonable to expect Actual Size zoom to be correct in every app, but you asked me to explain why the results can differ between Affinity and Preview if the error in Affinity is a result of a macOS error. It's impossible for me to factually explain (rather than guess) why there is a difference because I do not have access to the source code for your apps.

[deleted]

Having very thoroughly rechecked, Affinity does not differ from Preview on my iMac Retina screen. Both apps displaying at actual/print size result in the image on screen being 98.8% of expected size.

[R C-R]

6 hours ago, anon2 said:

Preview's Actual Size is supposed to be 100% pixel size when displaying an image file, but it results in approximately 197% pixel size on my Retina screen.

FWIW, on my non-retina iMac, with 100% scale set as below, the display size is exactly the same as on printouts, or at least so close to it that I can't see any measurable differences, even with a magnifier.

The other scale option also seems to work as indicated, at least to the extent my eyesight assisted by a high power loupe can accurately count individual screen pixels.

One thing I did notice is that changing the preference does not update the display -- I have to zoom in or out & then back to "Actual Size" to force a screen update. 

[thomaso]

10 hours ago, R C-R said:

The "Mac OS thing" is yet another head scratcher for me. For images files, the Mac Preview app offers 2 alternatives for 100% scale, "1 image pixel equals 1 screen pixel" & "Size on screen equals size on printout." The latter option does not reduce the display size

The Preview.app does change the zoom level value simultaneously when I alter this preference, while the displayed dimensions are maintained. So this way the app behaves correctly. Furthermore when I move a document window from the internal Retina screen to the external with different pixel dimensions then the zoom level value becomes updated in Preview.

10 hours ago, R C-R said:

This implies to me that the OS is fully capable of calculating screen pixel density so there must be something wrong with how the Affinity apps use it.

Agree. Not only that Affinity shows a different zoom level value if the unit gets changed – even with a pixel image in Photo. It also seems to not know about the monitor resolution and therefore shows the same "Actual" zoom level value for my different monitors, while the 100% are wrong on both screens. (different to the mac Preview.app).

"The staff have tried to explain this from time to time, (...)" – if you remember or accidentally discover such a spot I'd appreciate to get a link.

[lepr]

10 hours ago, R C-R said:

FWIW, on my non-retina iMac, with 100% scale set as below, the display size is exactly the same as on printouts, or at least so close to it that I can't see any measurable differences, even with a magnifier.

The other scale option also seems to work as indicated, at least to the extent my eyesight assisted by a high power loupe can accurately count individual screen pixels.

One thing I did notice is that changing the preference does not update the display -- I have to zoom in or out & then back to "Actual Size" to force a screen update. 

Thanks for that screenshot, I should have been more careful in checking the Preview preferences. The sizes on my Retina screen for Preview:

PDF and image,  "size on screen equals size on printout"  => 98.8% of expected size

And for Affinity, having checked very thoroughly, I get exactly the same error.

 

Edited May 10, 2020 by anon2

[lepr]

7 hours ago, thomaso said:

Agree. Not only that Affinity shows a different zoom level value if the unit gets changed – even with a pixel image in Photo. It also seems to not know about the monitor resolution and therefore shows the same "Actual" zoom level value for my different monitors, while the 100% are wrong on both screens. (different to the mac Preview.app).

I've thoroughly rechecked my measurements. Affinity and Preview display equally wrongly on my iMac Retina display at actual/print size. They both display a 254 mm document/image distance as 251 mm on the screen. That's 98.8% of expected size, using both apps. Seems likely that the error is due to macOS rather than the individual apps.

[lepr]

19 hours ago, R C-R said:

If the error is in the macOS, why doesn't Preview app have the same error?

On my machine, exactly the same magnitude of error happens in Affinity and Preview.

[MikeV]

Found this thread while looking for an answer to another 'view/zoom' issue I'm having.

Experiencing this issue as well – command 1 or command 8 bringing up the same size document, but that document  being larger on the screen than the finished print size (custom 155 by 218 mm pages vertical, facing) on my 5K iMac, but not on the companion 4K Dell monitor (older iMac that can only take a 4K second monitor). Followed R C-R's lead. Reset Preview preferences to 'Size on screen equals size on printout', restarted Publisher and now the iMac is also displaying the document at the correct print size when I use either command 1 or command 8 – seems to be no difference between the two. I'm running Mojave 10.14.6 – just about to finally dump InDesign and update to 10.15, Yah!

 

[lepr]

3 hours ago, MikeV said:

the iMac is also displaying the document at the correct print size when I use either command 1 or command 8 – seems to be no difference between the two

cmd+1 (zoom 100%) in Publisher and Designer behaves in two ways : it zooms to 100% of physical size when the document units is physical (such as mm or inch), and zooms to 100% of pixel size when document units is pixel.

cmd+1 (zoom 100%) in Photo always zooms to 100% of pixel size, regardless of document units.

Note that when Metal is specified for the display in the app's performance preferences, cmd+9 (zoom pixel size) wrongly zooms to 200% of pixel size on a Retina display, but when openGL is specified, the view correctly zooms to 100% of pixel size.

[Thomas K.]

On 5/8/2020 at 6:57 PM, GRAFKOM said:

As I wrote earlier.
on this screen, the 23-inch project open in Publisher MAC version is displayed as too large, while when you open this project in Publisher windows version in Parallels Desktop, the project is displayed correctly. (actual size).
Before publishing this question on the forum, I did probably a thousand attempts at various screen settings, and unfortunately I could not do what I wanted.

I have the same problem. When using Affinity with a laptop on an external screen, it seems that the 100% are always related to the laptop screen size and not the external display size. Seems like a bug to me. The "actual size" should always consider the size of the monitor the app window is shown on.  

[Fixx]

IMHO, expecting Actual size to display physical dimension "right" on screen is nothing but wishful thinking. Software has no reliable way to know display dpi to calculate exact display size and it is generally just an approximation.

[Thomas K.]

1 hour ago, Fixx said:

IMHO, expecting Actual size to display physical dimension "right" on screen is nothing but wishful thinking. Software has no reliable way to know display dpi to calculate exact display size and it is generally just an approximation.

That's only a claim that "software has no reliable way to know display dpi". What makes you believe so?. I mean its not VGA times anymore and modern displays probably have a way to communicate PPI to the operating system. macOS knows about available resolutions, brand name, rough size and others. Why shouldn't that work for PPI?

 Also your claim falsified by the reality. On the native display it works correct and precise at least to the sub millimeter level. Just test it with a standard sheet of paper.

But I have to correct my last post. I retested the situation with a DIN A4 paper sheet and when I start Designer on the external display and then zoom to real size (cmd+8) the size fits with an accuracy of less than a millimeter. I tested it with an Apple 27" Cinema Display and MacBook Pro with recent versions of the Affinity apps and macOS.

[Fixx]

1 hour ago, Thomas K. said:

That's only a claim that "software has no reliable way to know display dpi". What makes you believe so?

100 x 100 mm design is ~85 X 85 mm in my MBP display when set to actual size. It is not wise to expect size to be right.

[thomaso]

1 hour ago, Thomas K. said:

I mean its not VGA times anymore (...) macOS knows about available resolutions, brand name, rough size and others. Why shouldn't that work for PPI?

This is probably the reason. It is related to the range of various pixel densities nowadays. Different to ancient times, where monitors had 72 or 96 ppi, meanwhile the size of the hardware pixel can vary quite a lot (up to ~500 ppi). To run a monitor the OS must know its number of pixels (> 'resolution') but its pixel size (> 'pixel pitch' > density > ppi) isn't relevant for the system or an app. – Compare light 'bulbs': neither brightness nor energy consumption is related at all to their physical size or diameter. A bulb with 1 mm Ø can be brighter than one with 10 cm Ø, but need less energy. So the size appears to be not related to the electrical aspects but rather a matter of design, taste or comfort. Like with monitors. – I actually don't know either but assume if a monitor doesn't deliver the info about its pixel size then even macOS has no chance to know it and pass it over to Affinity. Another comparison: you can set your monitors brightness very low but if you make a screenshot then this file doesn't show the reduced brightness. "Why doesn't macOS know my brightness setting?" (rhetorical question). You even can switch off your external monitor and make a screenshot of its screen. "How can macOS see what's on my screen if I have it switched off?"

1 hour ago, Thomas K. said:

But I have to correct my last post.

You are lucky if it works with your macbook + a 27". To me the external screen shows the correct size in Affinity at 85 %, unfortunately Affinity doesn't let me set a shortcut for this (the "views" of Navigation Panel would be able to work if Serif would not have it fixed/limited to one specific page or document detail.)

How comes you got two different results? (while the first made you post here) What setup was different at first?

[lacerto]

(...)