Viewing "Actual Size"

[Canned_Pug-Ng0EYk]

HI,

I've always wondered why, if I set the screen view to "Actual Size" or even 100%, that if measured against a ruler put up to the monitor, it does not correspond. Is there a view or setting that can do this without me zooming in or zooming out and measureing with a ruler every time? (I'm feeling this might be so simple I'm going to once again be embarrassed....

Thanks.

[Peter Spier]

And they're too freakin' small for us old folks already!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!

[Canned_Pug-Ng0EYk]

amen.

...from Miickii's iiPhone

[rob day]

Am I to conclude the universal use of 72 dpi comes solely from those ancient Macs?

I have 3 monitors on my desk manufactured by Apple—23", 20", and a 13.3" laptop. When they run at their native resolutions, which is the default in OSX, the actual pixels per inch for the three are 98.44, 99.05, and 113.49 respectively. I can also choose a non native res and the OS will resample the display (and blur the interface) and I get another set of displayed resolutions.

I think the interface designers could choose something other than 72 as the assumed res, but the problem wouldn't go away–98.44 wouldn't work on my laptop.

and my assumption of how easy it would be to have a preference for screen resolution

The formula for adjusting the zoom percentage needs the display's physical dimension as well as the screen's pixel resolution. A preference would have to ask the user for that dimension. Does the user know it's the diagonal? My 13" MacBook Pro actually measures 13.3" diagonally. What would the default be?

Especially when the capability to adjust resolution is acceptable (and easily implemented) in applications such as Photoshop?

Photoshop does have a View>Print Size, but suffers from the same problem. When I set the view to Print Size on my 23" screen a displayed ruler inch measures .75". If I have a 275 ppi image I can use Marijan's javascript formula and replace 72 with 275 and get 36% as the percentage, which display's the rulers accurately—the Print Size setting gives me 26.1%, which is not accurate.

[Guest]

Rob,

So what you're saying is that there can be no easy fix. Or at least a fix

that universally works. I can accept that.

Personally, I have not been that concerned with this issue, and in the past

I have wondered why people gave a shit about 100% being 100% of the size of

the printed piece. But there have been times when I did need to adjust the

display to compare a printed piece against the screen. So while it may not

be perfect, and it may not work for every computer equally, it still seems

fairly easy to implement a preference that would help people get what they

wanted to see on screen.

I take your point regarding the size of dialogue boxes. That was the one

disadvantage of going to better monitors. But that is an OS consideration

and I'm not sure that need be relevant to our discussion. Changing the

display size of Photoshop's rulers doesn't effect the size of its dialogue

boxes.

[rob day]

So while it may not be perfect, and it may not work for every computer equally, it still seems fairly easy to implement a preference that would help people get what they wanted to see on screen.

If we agree that the preference would have to ask for a physical dimension of the monitor, what would the default be? With monitors ranging from 12" to 30" any default would produce wildly inaccurate results on a high percentage of displays.

So what you're saying is that there can be no easy fix. Or at least a fix that universally works

The posted script is an easy solution

[Guest]

"any default would produce wildly inaccurate results"

Isn't that the current situation? I find it difficult to believe that

someone using InDesign wouldn't know the size of their monitor or its

effective resolution and find it fairly easy to adjust the value to get the

display result that suits them.

While the script may be fairly simply, isn't that solution something that

has to be used every time you open InDesign? That would be rubbing salt into

the wound every time you start working and make a small thing into an actual

irritant.

[Peter Spier]

So, if I tell you I have a 17" monitor, am I using a widescreen laptop or a an old CRT or early LCD?

[rob day]

Isn't that the current situation? I find it difficult to believe that someone using InDesign wouldn't know the size of their monitor or its effective resolution and find it fairly easy to adjust the value to get the display result that suits them.

If the default were 15" and I never changed it, the "Print Size" percentage on my 23" running at 1920x1200 would be 210%—that's what I meant by wildly.

Also, the JavaScript that Marijan posted doesn't work on OSX, probably because it's looking for the display res and can't get it from the OS, so it may be on OSX the preference would need to also include hres, vres and the physical dimension.

This AppleScript works with OSX:

--This works for a Apple 23" Cinema Display change as needed

--the display's horizontal and vertical resolution in pixels and monitor's diagonal view area in inches

property hres : 1920

property vres : 1200

property diagonal : 23

tell application "Adobe InDesign CS5"

activate

set printsize to round (((((hres * hres) + (vres * vres)) ^ 0.5) / diagonal) / 72) * 100

set properties of active window to {zoom percentage:printsize}

end tell

[Guest]

Rob,

Are you considering something that I haven't. How does ID choose the default

it does now? Surely it doesn't assume a 15" monitor. Why couldn't ID work

out of the box just as it does now -- and have a preference for input of

user defined screen resolution? Do you really see that as problematic?

---

And thanks for the script, but I can't get it to work. I thought all I had

to do was to save the copy as a text file with an .as or .scpt extension.

But obviously I am not understanding something. I can't even add the

extension without also having rtf.

[rob day]

How does ID choose the default it does now?

Actual Size sets the zoom to 100% and in that case 1" on the ruler equals 72 pixels—the size of those pixels varies depending on your monitor setup.

Surely it doesn't assume a 15" monitor

There's no assumption about the monitor size or screen res variables, that's why the display of 1" is variable among different configurations.

Why couldn't ID work out of the box just as it does now -- and have a preference for input of user defined screen resolution? Do you really see that as problematic?

I think it could be done but as I've said the default would be problematic for many users.

I can imagine that Adobe's engineers are reluctant to bloat the prefs file when the problem can be solved with a simple script.

I thought all I had to do was to save the copy as a text file with an .as or .scpt extension.

No you have to use the Script Editor app. Open Script Editor, paste the code into a new window, click the Compile button and save it with scpt ext into your ID Scripts folder.

[Guest]

Rob,

I hate to be a bother, but I know nothing about Apple script and I am

interested to see how your script works.

Compile gives me a syntax error: Expected end of line, etc. but found ³*².

thanks

P.S. "Surely it doesn't assume a 15" monitor" I don't know why I even said

that. I already know that ID is rendering every inch into 72 pixels and that

the width of 72 pixels is going to vary from monitor to monitor.

To be honest I don't know if the decline of print will make this feature

less sought after, or the next generation of monitors make it more sought

after. But I do know overcoming history isn't easy.

[rob day]

http://www.zenodesign.com/ftp/printpreview.zip

[Guest]

Thanks Rob, you are too kind going to this trouble.

The script works fine. Still, I'm not sure this solution will satisfy

everyone. I think having the percentages displayed by InDesign accurately

reflecting true physical dimensions is just as much a part of people's

expectations as being able to view something size as.

P.S. There must be a bit of difference between the Apple Cinema Display and

iMac screens. Even though my screen is supposed to be 23", I found I had to

change the diagonal property to 24 to match rulers.

[rob day]

Even though my screen is supposed to be 23"

Measure it?

I think having the percentages displayed by InDesign accurately reflecting true physical dimensions is just as much a part of people's expectations as being able to view something size as.

I can't find an application on my machine with a ruler interface that does that—AI, PS, ID, Word, Pages, Text Edit, Acrobat, Quark.

[Guest]

Measure it?

I've been telling people that I got a 23" iMac for at least a year now.

Again just yesterday in fact. I don't know when or why I started thinking

that, but the paperwork for my iMac does say 24".

---

You are also quite right about no other applications displaying any more

accurately. I was just commenting on the motivator behind actual size

requests.

[rob day]

Take a look at Acrobat. An inch displays accurately on my Apple screens running at or near 100 ppi, but not on my laptop running at 115ppi or my old iMac running at 86 ppi. The Acrobat UI designers chose to draw an inch as 99 pixels rather than 72 at 100%, but it still is a fixed number displaying on variable screens.

[Guest]

Rob,

Acrobat displays fairly close to 100% for me. And I think this one of my

underlying points when I first asked "what is this magic number 72?".

I didn't know that, but can see why Acrobat chose to use 99. It is closer to

real usage than is 72. Well, except for laptops, but I have almost no

experience with them. And so ignoring laptops, I don't see why more

applications shouldn't be adopting the (or a) higher number. 72 has lost its

magic.

[rob day]

Acrobat displays fairly close to 100% for me.

For you but not for everyone. There's nothing universal about 99 —the Apple 27" runs at 109, 15" MacBook Pro at 110, MacBook Pro 17" at 133, ViewSonic VX2433 24" at 92.

[Guest]

I've already said several times that I recognize their is no universal

value. I haven't even been pushing a specific number. All I have left to say

is look at your examples: they are all closer to 99 than 72.

[rob day]

While the script may be fairly simply, isn't that solution something that has to be used every time you open InDesign?

No, you assign a key command to the script so you can set the view anytime you want. You could assign Command-1 to the script rather than the default Actual Size menu item.

[John Hawkinson]

Wow, I was out all day, this thread really exploded. I think there's been fair amount of confusion and speculation to go around, and it's worth clarifying what is fact and what is speculation. I'm going to use the term DPI to talk about monitor dots (or pixels) per inch, I hope that doesn't offend anybody.

Where 72 dpi came from and why programs assume it

M Blackburn asked where 72dpi came from, and whether it came "solely" from ancient Macintoshes. Well, that's one place it started. At the time, that was the expected dpi of a monitor, and it took quite a while for the world to evolve to later values. It wasn't only the value on those Macs, of course. But OSX had it easier, since the resolution (which is set by the graphics card) and the screen size (set by the monitor) were both constant factors. In the PC world, if you had an 800x600 video card, changing from a 15" monitor to a 17" monitor would give you a different DPI. And, also, in those days, monitors were CRTs, which made they had no "native" DPI -- they were continuously variable until you hit some maximum that most people never came close to. This is not true of LCDs, which actually have pixels, rather than a magnetic cathode ray gun.

I am fully aware that the 23 is a diagonal measure, but that is a measure of monitor size and this discussion deals with resolution which has to be taken parallel to an edge.

It doesn't really. Just convert your 23" diagonal to a horizontal (or vertical) measure and use that to calculate DPI.

Are you sure of your facts and your reasoning? Why must all programs have the same idea of how big the screen is if it results in all programs displaying 100% at something other than actual size? Especially when the capability to adjust resolution is acceptable (and easily implemented) in applications such as Photoshop?

I should be more clear. Some of this is indeed philosophical and cross-platform and not written down on stone tables in the Apple Human Interface Guidelines. It comes from my background as a programmer familiar with operating systems and the APIs they provide.

Programs should have the same idea of how big a screen is because the screen is the same for all programs running on a given machine (let's ignore multiple monitors for the moment). It's the operating systems' job to tell programs what that resolutution is -- it would be silly for all programs to implement such a setting themselves, just as it would be silly for all programs to implement the filesystem themselves (NTFS, HFS+, etc.), rather than relying on the OS to do so. It's the OS's job to handle these kinds of things.

And, as has been pointed out, Windows does let you adjust it:

Why doesn't OSX? Well, I think Apple is just slow on this point. Apparently they started to give it a shot in 10.4, and they encountered some problems. Check out this section of the Apple Human Interface Guidelines: Resolution-Independent User Interface. It appears that right now the feature is intended for developers only, not for end-users to play with (read: "doesn't quite work"/"has unintended consequences").

Also, remember that InDesign is still a Carbon application, not a Cocoa app. That means it's Not Quite There with respect to being up to date with Apple's most recent APIs. Adobe has quite a bit of work to do on that front. And I think the Photoshop team has done a lot more work in this regard -- probably because having 64-bit support is important to PhotoShop (humongous image files) in a way that it is never likely to be important to InDesign.

But these generalities aside, could InDesign make an exception and gain its own setting for monitor DPI? Of course it could. Adobe developers are probably reluctant to do so because they know it's technically "wrong" and there are also better ways to fix it, like  using Apple's more recent API. I assume that under Windows InDesign respects that monitor DPI setting, but I don't really know. Also, for almost all users of InDesign, making "100%" actually be 100% doesn't really matter.

For instance, the EDID standard allows operating systems to query monitors for their size. That means, if you have a recent monitor then your operating system ought to know how big the screen is, and thus the screen's DPI. All applications should then get this information from the OS. Again, if only everything was quite that simple and the assumptions about 72-dpi were not hardcoded in many places, both in OS APIs as well as inside complicated applications that have been around for a while (like ID).

InDesign's internal measurements

Peter Spier suggested that because ID's internal measurements are in points, and there are 72 postscript points per inch, that there is a 1:1 relationship and that is why ID assumes 72 DPI. I do not believe this is correct, but I am speculating. I'm pretty sure that it's esentially coincidental that 72 DPI is the historical monitor DPI and 72 DPI is the number of PostScript points per inch. (Of course, I'm sure that when someone had to choose the DPI of the first monitor that was 72, they were aware there were 72.72 printers points in an inch, and that also the number 72 has a lot of nice properties -- it factors well: 2^3*3^2, unlike its neighbors 71 or 73, or even 75. So perhaps the 72-points-per-inch influenced the 72 DPI decision,  or perhaps not, but I don't think it is why ID assumes 72 DPI. ID does so because that's the default for applications.

I think Peter realizes his theory is not so good, because he talks about 1/4 pt lines being visible. It's just not possible to say "more phosphor dots or LCD cells or whatere than just one making up each screen pixel." In this context, a pixel is the smallest addressible screen unit. If ID had access to sub-pixel information, then they wouldn't be pixels anymore. (Again, ignoring the complexity of red/green/blue subpixel arrangements in LCD monitors).

On the other hand, ID does cheat. If you take a screenshot at 100% of a 1/4 pt line, 1/2 pt line, and 1 pt line, you'll see that they are indeed drawn as one pixel wide, but with different colors of gray. Effectively they are anti-aliased, as should any screen element be:

Anyhow, this doesn't really matter. Regardless of what ID's internal idea is, that could easily change by a multiplicative factor.

Peter writes, ""Resolution" is a print concept describing how large the [pixels] are at the size you print."

Well, not only. Resolution is ALSO used to refer to the absolute number of pixels of width and number of pixels of height. This is annoying because when people say resolution, sometimes they mean density (ppi or dpi), sometimes they mean linear length in pixels, and sometimes they mean what is traditionally meant in the optics world or in the graphics and cinematography world, which is hard to express without using functions like MTF, but is often shorthandedly referred to in "line pairs per unit length" (line pairs/inch or line pairs/cm, etc.). Oh yeah...and sometimes they're confused.

Rob Day notes that increasing the OS's idea of the monitor's DPI makes UI elements smaller. This is, of course, a function of the immaturity of the OS. As the OS gets better at dealing with these issues, there will be resolution-independent UI elements. I think this is already happening, and it is the source of some of the slowness to see this working right in applications in Apple's OSX.

Rob also says that tomaxxi's script doesn't work under OSX -- err, it seems to work for me.  It asks JavaScript for the screen resolution (linear pixel length, not density), as part of $.screens, and JavaScript answers correctly, e.g.:

>> $.screens
0:4-1920:1178

It assumes the user is going to fill in the monitor diagonal though, because JavaScript doesn't make it easy to get that.

My summary

InDesign could definitely gain support to have 100% scaled to actually be 100%, it's a Simple Matter of Programming. But doing it right means not letting the user control it (the OS should tell it), and it's not really a high-priority feature because the workaround is so trivial (just zoom in! Or use a script if you need it to be better), and ID has a lot of distance to go in order to catch up with evolving operating system APIs anyhow, so why should the ID developers give a temporary band-aid when they can take a bit longer and do it right.

It's not like people are jumping out the windows like they are for Frame Edge Highlighting :-).

[John Hawkinson]

OK, so I told you guys to read this:

Why doesn't OSX? Well, I think Apple is just slow on this point. Apparently they started to give it a shot in 10.4, and they encountered some problems. Check out this section of the Apple Human Interface Guidelines: Resolution-Independent User Interface. It appears that right now the feature is intended for developers only, not for end-users to play with (read: "doesn't quite work"/"has unintended consequences").

but I didn't actually read it myself. (More precisely, I didn't follow all the links to the subsections). This section, Overview of Resolution Independence explains how to change it in an application-specific way. Since tomaxxi's script ended up setting my zoom factor to 131%, I ran this command in the Terminal:

defaults write com.adobe.InDesign AppleDisplayScaleFactor 1.31

And SHAZAM!, restarting InDesign and hitting Cmd-1 gives me accurate rulers. Now, of course, a lot of the rest of the UI is...blurry, goofy, and off the screen. Also, BIG, which I'm sure is helpful if you have aging eyes. And I'm sure this is totally unsupported, so Your Milage May Vary, A LOT.

I assume this is using "Magnified Mode" but I don't really know.

(The shell/perl script to calculate 1.31 by reading the EDID data is left as an exercise to the reader).

All-in-all, this is probably a bad idea to do and I would not recommend it. Oh yeah, and how to undo it:

defaults delete com.adobe.InDesign AppleDisplayScaleFactor

[rob day]

All-in-all, this is probably a bad idea to do and I would not recommend it. Oh yeah, and how to undo it:

No kidding, resampling (blurring) the interface is not a solution to this minor problem.

[Jongware]

John, while on this topic: can you add somewhere that a pixel is not a valid measurement unit?

[John Hawkinson]

err, I think I'm missing the joke? You want me to edit it in to my long post? I think next time I should use <h3> instead of <h1>...

(The irony is that there are indeed contexts where a pixel might be a valid a measurement unit...; it's not a valid unit of linear distance, that's true...)