| Date: | July 14, 2004 / year-entry #279 |
| Tags: | code |
| Orig Link: | https://blogs.msdn.microsoft.com/oldnewthing/20040714-00/?p=38443 |
| Comments: | 58 |
| Summary: | It's the system DPI setting. |
When people ask, "How do I detect Large Fonts", they aren't really asking how to detect Large Fonts specifically. Rather, Large Fonts is just the most common manifestation of "unusual DPI". Windows uses a nominal DPI of 96 pixels per inch. In other words, if Windows wants to draw a line that is one inch long, it draws 96 pixels. Of course, the physical length of this line depends on your screen resolution and the size of your monitor. The value of 96 is merely nominal. You can change this DPI setting from the Display control panel, either by choosing Large Fonts, or by choosing a custom font size. Standard size is 96DPI. Large is 120DPI. Custom is, well, custom. DPI higher than 96 will become more and more prevalent as LCD technology improves. Programs can query the DPI setting by asking GetDeviceCaps for the LOGPIXELSX of the screen DC.
int GetScreenDPI()
{
HDC hdcScreen = GetDC(NULL);
int iDPI = -1; // assume failure
if (hdcScreen) {
iDPI = GetDeviceCaps(hdcScreen, LOGPIXELSX);
ReleaseDC(NULL, hdcScreen);
}
return iDPI;
}
The code above assumes that pixels are square, which is true of most modern devices. (You can choose an odd screen resolution and get non-square pixels, but most people avoid such resolutions.) Back in the old days, there were many devices with non-square pixels. For example, the EGA video adapter had pixels which were 1.33 times as tall as they were wide. For nonsquare-pixel devices, the values of the LOGPIXELSX and LOGPIXELSY metrics will be different. On an EGA, if the value of the LOGPIXELSX metric were 96, then the LOGPIXELSY metric would be 72, since there are only 72 vertical pixels per inch. Similarly, the ASPECTX, ASPECTY and ASPECTXY values for nonsquare-pixel devices will be somewhat interesting as well, as this diagram demonstrates: The ASPECTX is 27 and the ASPECTY is 36, representing the 4:3 ratio of vertical to horizontal, and the ASPECTXY is 45, representing the hypotenuse. |
Comments (58)
Comments are closed. |
I really wish more applications would work correctly with e.g. 120 dpi. I’m quite tired of not being able to access the bottom right edges of dialogs, where the ok and cancel buttons are commonly placed among other things.
Will Longhorn have better support for high DPI devices? At the moment, people with high DPI monitors have to decide between applications looking odd or everything displaying far too small. In an ideal world there would be no link at all between DPI and the size of items on the screen (DPI should only affect display quality).
Perhaps Microsoft should buy all of their developers 300 DPI screens to encourage them to improve this area.
Certain visual development tools such as Delphi make it very easy to design UI based on pixels, and when the tester sets Large fonts, chaos ensues.
I guess dialog units were supposed to solve this problem. On the other hand, CreateWindow[Ex] seems to accept pixels for x/y/cx/cy. Oh well.
CreateWindow(Ex) isn’t psychic. It doesn’t know which dialog box you wanted your DLUs to be relative to. MapDialogRect, on the other hand, specifies a dialog box relative to which you want the DLUs converted to pixels.
Delphi allows one to design UI based on pixels, but it also allows one to scale the UI based on the DPI.
If Delphi is so bad, why would Microsoft hire Anders? Precisely because Microsoft lust after the technology that Anders has created while under Borland’s employment.
In case anyone doesn’t know, Anders was the chief architect of Turbo Pascal, Delphi 1-3(or 2?). Now he’s the chief architect of C#, and CLR.
Every time I tell people I use a 1600×1200 resolution, they ask things like "how can you read things in such a high resolution" or "isn’t the text too small" and I always say "I use 132DPI, the font size is the same" (Mozilla is the only oddball which configures default font sizes in pixels, forcing me to do the calculations by hand; however its UI respects the DPI settings).
This because people use low resolutions because they want larger fonts (and most people who tries to use Large Fonts or other nonstandard DPI settings knows it doesn’t work. It works here only because I’m using X11, not Windows. Of course Windows itself would display fine, but other programs would display all broken.)
Worse than that is people who specify font sizes in pixels on webpages, which almost always is way too small (I had to set the minimum font size to 7pt on Mozilla to make pages like that at least readable).
I’ve already found a Windows program that detects when you are using a "nonstandard" DPI, and shows a dialog box warning it won’t work correctly and asking me to change it back. It was made in Delphi, of course, and there was no way to avoid using it (it’s the Brazilian income tax report program, IRPF). At least next year the Java version will be ready (and I really hope it doesn’t get confused by exotic DPI settings).
I second the proposal to autodetect the DPI on Longhorn; this will make it common for developers to have odd DPI settings (thus forcing them to design things properly). If you don’t want to break things, you can fake a fixed 96DPI to older apps (another appcompat thing?). I believe X11 toolkits don’t have this problem exactly because both 75DPI and 100DPI were common in the past (nowadays it’s more common to autodetect).
I also think the font size and the DPI should be separated; you should be able to change the default UI font size without changing the DPI (so Bitstream Vera Sans 12 is the right size even if I want to reduce the default font size to get more free screen area).
The big compatibility hit with secretly changing the DPI setting is with existing users. You install Longhorn and "Hey, all my screen elements are the wrong size! Stupid Longhorn screwed up my settings. Microsoft programmers are morons."
Not saying it can’t be done. Just that it may cause more problems than it solves.
"making DPI-agnostic coding easy and evangelizing it to the masses". Already done. It’s call WinFX. But people complain anyway.
Note that non-square-pixel modes will becomme more popular, with widescreen laptops. They seem to do something silly, though, because if you put them in a mode which has an aspect ratio that doesn’t match the physical aspect ratio of the screen, even the icons don’t look right, meaning that the video driver doesn’t agree with the monitor at a pretty basic level, AFAICS.
The only solution is the "Big Stick": all development environments should change their DPI settings every hour. All new programs will be written correctly (because their failures will be obvious very quickly), and over time everything will turn out OK.
Randomly switching to different date and digit formats would work a treat, too, as would switching between 32 and 64 bit pointers.
Peter
Is there any way to detect large fonts from inside IE?
That’s one of the biggest problems I have. (then again, I’ve been in the web dev world for many years now) Users complain about text "disappearing" when really it’s just off the screen… or clipped by an absolute size [iframe] where the silly developers hardcoded pixels.
I’m actually quite surprised to hear that Windows has separate values for horizontal and vertical resolution, since I had assumed the settings available to software would affect the settings available to the user.
Windows only lets me set horizontal DPI (using the on-screen ruler) and assumes square pixels. How do I tell Windows that I have non-square pixels?
Auto-detecting optimal screen dimensions and resolution is easy for a plug-and-play TFT monitor, but how do you work it out for a CRT monitor? The little buttons on my CRT monitor allow me to distort the picture in all sorts of fun ways, and by default it was a little smaller than the visible screen area, probably just to be safe because they knew users wouldn’t like it if they had to reconfigure it to get part of the display onscreen if it shifts a little. I have it configured to fill the screen, but by default there would be a higher DPI setting because there are less physical inches in the displayed picture.
Displaying GUIs legibly at high resolution is such a problem that Apple brags about the low pixel density of its LCD displays as a "feature"!
Raymond, that’s why I said you should do it only for new applications. Let the old broken ones stay with 96DPI, and use the real dpi setting for the new ones (since you said WinFX will work fine, make it use the correct DPI by default).
It would be nice if you could set the H/V DPI settings individually. On occasion I connect my PC up to my widescreen TV, and everything goes all short and fat as the pixels are nothing like square any more…
Does the widescreen TV really have non-square pixels, or it just has different aspect ratio? I think if you set your mode to something like 1600×900 you’ll get the correct image with the same H and V DPI.
What is the recommended way to handle high DPI regarding visual elements? For example, should the 3D (or 2D) borders for controls be twice as wide on 192DPI? What about window splitters, toolbar grippers, etc?
Will the user be able to switch the DPI without rebooting in Longhorn? in XP and 2000 it requires reboot, so I can do all my DPI calculations on startup.
I’ve also had a similar problem to Mat Hall before. The problem is that the graphics hardware only did output to TV as an afterthought so it only supported (at least, from the stock drivers) the standard 4:3-ratio resolutions, so I just set the PC res as high as it would go and told the TV to pan and scan, giving the illusion of widescreen, albeit at slightly lower quality, as long as you can persuade your media player software to invert the scaling performed by the TV.
I’d argue that using different fonts for the different DPI settings was a bad idea in the first place. I think they only did it because MS Sans Serif was a bitmap font and thus couldn’t be scaled. Now the default font is Tahoma, which is scalable, it should be easier.
As for what Raymond said, I can’t help but think that it can’t be too hard to, when performing the upgrade from a previous version to Longhorn, use the new DPI setting that is autodetected along with the previously-configured DPI setting to calculate a new resulting font size which will appear the same as in the beforetime, give or take a few negligible units. Just a bit of arithmetic.
Btw, one of the worst offenders in this category is web browsers (both IE and mozilla fwiw).
My wife runs her machine at 1024×768, but she uses large fonts. Many windows apps don’t work right (dialog box clipping, etc), but there are very few web pages that work right, because they can’t deal with the larger than normal fonts.
"If there’s any sort of "Changes" introduction…"
Everybody who ran the Windows XP Tour raise your hand.
Nuff said.
LCD’s usually do have square pixels. 17-inch LCD’s are usually 5:4 aspect ratio and have a resolution of 1280×1024. (Similar to 1280×960 on a 4:3 CRT.) There are 16:9 LCD’s that use 1920×1080.
You can’t really have the dialogs scale proportionately with DPI because everything is in integers. Feng Yuan’s book talks about different ways to get scalable fonts and how GDI loses precision if you do things in a certain order. GDI+ took a different route, as described in http://support.microsoft.com/default.aspx?scid=kb;en-us;307208
Don’t depend on GDI to give you accurate values for anything at all. VERTRES, VERTSIZE, and LOGPIXELSY are totally wrong. VERTSIZE is supposed to be equivalent to LOGPIXELSY when you do the unit conversion because it’s the same measurement but in different units, but it’s not. LOGPIXELSY seems to be the DPI setting you use and VERTSIZE seems to be some value based on a formula for VGA sizes. I think it’s made this way for app compatibility (I mean look how many apps mess up when you change any of the display settings) and for multiple monitors that can vary a lot.
<sorry of my bad english>
Hi all. I lately found mr Cheng weblog.
It looks that you are really a great developer of one of team
that stands behind win32 api, a great api looking
from gui point and sytem stuff. You are cool, man.
lots of code examples, also, nice to see there are
people doing ocassionally asm coding with windows api.
i mean, we live in 2004, the era of vmm’ed apis, langs, classes (net, java, perl is preliminary
expected to become register-based vmm, current trend things are jit’s compilers and
portable code).
And still there are alive people thinking, what will become burned
if i port code from ia32 to other hardware architecture, or
just recompile on 64bits.
A lot of respect to you, mr Cheng. Nice to see you. Your’s guidelines
always welcome.
</sorry of my bad english>
7/14/2004 11:20 AM Raymond Chen
> Right and one of those new applications is
> Explorer. "I upgraded to Longhorn and the
> fonts changed size in all of my folders.[…]
> Why does Windows always forget my settings?"
But that would be only once per Windows version grade, would it not? Why does Windows Explorer already forget settings after a few hours or days? This happens without grading to a new Windows version and the frequency is irritating. Fortunately not destructive, merely frequently irritating.
But let’s try imagining if Microsoft would decide to do something right even though it breaks broken compatibility. Then developers who want to do something right will not be forced to break what they did in order to obtain compatibility. Developers who do something wrong would be exposed, some might fix their stuff (since they’d only have to fix it once) though some wouldn’t. Sure there would be some people blaming Microsoft, but for a change they might have a reason to learn to blame applications instead.
And corporations whose line-of-business progams are broken will be unable to conduct business.
Right and one of those new applications is Explorer. "I upgraded to Longhorn and the fonts changed size in all of my folders. I went to a lot of effort to get them exactly the way I want them and now I have to go fix them *again*. Why does Windows always forget my settings?"
> "I upgraded to Longhorn and the fonts changed
> size in all of my folders. I went to a lot of
> effort to get them exactly the way I want them
> and now I have to go fix them *again*.
The upgrade process could examine current font and DPI settings, and automatically select a default "base" font size for the new configuration that approximates the look of their old environment while using a proper DPI setting.
If Joe User is currently using Windows with standard defaults, with an assumed DPI of 96, and uses Tahoma at 10pt for his dialog text, and then moves to Longhorn, which detects that he actually has a 120dpi setup, the setup process (preference import) might adjust his 10pt font size down to 8 or 9pt to make it look about the same.
Or perhaps approach it a different way: for upgrading users, use a "Custom" DPI of whatever they’re currently using today (96dpi?). For everyone else, do the "Auto-Detect" thing, since they have no preferences to preserve.
If there’s any sort of "Changes" introduction, something that tries to describe the ways Longhorn differs from its predecessors, maybe include a screen or a blurb about DPIs, and give the user the option at that time to live on the edge and auto-detect.
The general problem that UI designers face when trying to use fonts properly and gracefully handle devices with different DPI settings is that very few applications (nowadays) consist of simple controls and text that can all scale.
No, web pages, and even the simplest XP dialog incorporates many bitmaps. And theres just no way – without a lot of coding overhead – to convince bitmaps to scale to different font sizes.
Ideally, if the user selected the "big fonts" 120 dpi mode, then web pages that rendered using the correspondingly larger fonts would also scale up all the grapic elements by 25%.
Of course, once you start down that slippery slope changing the DPI of a device is pointless at best, and damaging to the image quality at worst as, with all the bitmap stretching going on you would achieve the same (or better) results by simply dropping to a 25% lower resolution.
XP makes the problem worse with its highly graphical look. Apps that want to look XP need to incorporate many graphical elements in their UI, amking it very hard to design a UI that can deal with anything other than a single DPI setting.
I see now why many Web pages do not work correctly on large high-res displays. They want to be "smart" (gee, I hate dumb software that tries to be smart). They probably detect high DPI value and decide that I should have large fonts active. Then they render text *smaller*. Since I don’t have large fonts, I now can’t see anything :-) Or the other way around: script sees high resolution and thinks ‘well, this guy won’t be able to tell anything if I render 8pt, let me try 24pt instead…"
Don’t forget about printers as well. I’ve had endless hours of fun trying to sort out which way round paper is. Many printers have different dpi horizontally and vertically.
Worse still Win 9x & WinNT families do this differently if you swap the printer in and out of landscape mode when it’s set to portrait then on the 9x family the dpi swaps, on WinNT it doesn’t.
Don’t get all this stuff about Delphi. My app (>100 dialogs) is written in Delphi and the dialogs scale fine with font scaling. There are really rather few programs that can say this. It’s not about the dev env but rather more about the developer and their attitude to such matters. If you want your app to work with custom font scaling then you will code accordingly and do lots of testing.
""making DPI-agnostic coding easy and evangelizing it to the masses". Already done. It’s call WinFX. But people complain anyway."
Right – I forgot we’re supposed to stop everything and wait for WinFx…
"And corporations whose line-of-business progams are broken will be unable to conduct business. "
So provide shims to allow selective reverting to old, broken, behaviour.
The core OS shouldn’t try to work around broken apps. That job should be left to appcompat-style shims.
It may be that some applications need a pretty big shim (because they do /lots/ of GDI stuff wrong), but that’s their own stupid fault.
This way, new programs will do the right thing, correct old programs will do the right thing, and broken old programs will be fixable, as reversion to the old, broken behaviour will be possible on a case-by-case basis.
I think you’re underestimating how much work it would be to write a shim that completely virtualizes USER and GDI.
Shims are good for very specific fixes like "This program forgets to pass the XYZ flag to that function."
They aren’t good for things like "This program has a fundamentally flawed view of the universe."
I’m surprised noone has mentioned the new Windows Mobile 2003 Second Edition OS.. Microsoft apparently spent many resources getting real DPI scaling to work on (CE’s slimmed-down) GDI engine. Why haven’t they done this yet for the desktop?
http://msdn.microsoft.com/library/default.asp?url=/library/en-us/dnwm2k3/html/developing_orientation_and_resolution_aware_apps.asp
Essentially all EXE’s tagged with a resource tell the GDI linker startup code that it is "DPI-aware" (granted, the only two DPI’s in CE are 96 and 192, everything is usually a 2x scaling, but MS’s compatibility modes handle any DPI). Anything without this resource are assumed to be designed for 96 DPI, and GDI scales each and every windowing and GDI call. It even scales down things (say, if a 96DPI application performs a screen grab). Very impressive, and you would think they could have done this on the desktop sooner than Longhorn, without relying on WinFX’s vector engine.
Raymond,
Core OS change or not – what’s interesting here is that, in theory, this shim/change could be accomplished in Linux’s WINE project and would not be possible in WinXP – unless Longhorn is really shipping in 2008, in which case I’d recommend MS to look at patching this into XP SP3 :)
Great question though:
Since the EXE has already bound to the GDI linker, the DLL gets ’96’ returned as the device’s DPI, and things progress smoothly. The main drawback is if a DLL wants to show a more detailed bitmap for 192-DPI devices, it would show its 96-DPI, lower-resolution cousin (same goes for icons, etc).
The reverse question is actually more difficult: a good example would be Pocket PC’s "Today" plugins — basically the shell EXE does the resource-checking itself (looking to see if a given plugin is DPI-ready) and if it’s not, it doesn’t load it — it loads the DLL under a different EXE file (mstli.exe instead of shell32.exe) which is designed to not be DPI-aware, which then loads the DLL.
Raymond,
That’s what is strange – each and every call that deals with pixels is scaled when the "compatibility mode" kicks in. GetSystemMetrics, CreateWindow, MoveWindow, GetDeviceCaps and SetWindowPos calls are all scaled too. It all works out. If the 96-DPI DLL checks some other window’s size, it gets cut in half. Same with GetSystemMetrics.
The only weird things that could happen are if a window sends another window a message, asking for some pixel value (like its dimensions or placement of a control). There you definitely will run into problems.
Unfortunately that’s not a "weird thing" – it happens if you say embed an Excel spreadsheet inside a Word document.
Excellent point. On CE, there’s no object embedding (or rather, very little). It sounds like it would be the responsibility of the main EXE program to do a Today-like shim, which would definitely be asking too much on the desktop side.
The diagrem doesn’t work in Non-IE browsers.
All my diagrams are written in VML. If you have a browser that supports VML and the diagram doesn’t work, let me know and I’ll try to fix it.
Non-square pixels are still common in many printers. Futhermore, many printer drivers forget to flip the x and y resolutions when you go into landscape mode.
I’m not saying that it *can’t* be done. Just that it would be an awful lot of work to virtualize everything via a shim. (Notice that the CE version is a core OS change, not a shim.)
Also what do you do if a non-DPI aware program uses a DLL that *is* DPI-aware?
"The DLL gets 96 returned as the device’s DPI and things progress smoothly." Well until that DLL say tries to mess with windows from other processes which are not DPI-scaled. You could scale the entire window rectangle, but then the DLL would see another window whose caption height is *not* equal to GetSystemMetrics(SM_CYCAPTION) because it has been scaled by the shim. Maybe that’s okay, maybe it isn’t. Depends on what the app does.
And Win32 apps are known for doing the strangest thing. More than once I have said, "This is a safe change. Nobody would ever be so crazy as to rely on that," and been proved wrong.
"They aren’t good for things like "This program has a fundamentally flawed view of the universe." "
But the flaw is a very specific one–that there are 96 dots per inch and hence its font-size selections and dialogue element positions work properly.
And unfortunately it seems that even for not passing flags (and so on) that Windows fails to use shims. There’s a few dozen appcompat shims, but (judging by the leaked source code) a hell of a lot more hacks to fix buggy apps contaminating the normal code paths.
"But the flaw is a very specific one" – yes which requires that nearly every single GDI and USER function be hooked so that the lie can be maintained.
It’s not like you can just patch LOGPIXELSX to return 96. These apps never call GetDeviceCaps; that’s why they aren’t DPI-aware in the first place.
Program calls GetWindowRect – you need to tweak the return value. Program calls SetWindowRect – you need to edit the parameters that are passed. Program calls SetWindowRgn – you have to edit the region. Program calls GetWorldTransform – you have to remove the scaling transform so the app won’t barf on it. If it were just returning 96 from a call to GetDeviceCaps that would be easy.
That leaked code was very old. It predated shims.
DPI awareness should be handled by the OS, and application level developers shouldn’t have to deal with it for the most part. Period.
Bill Gates has stated that 200-dpi displays will be commonplace. What the heck will you do then?
A friend of mine does all UI in MM_TEXT. He obtains size and rezolution of a DC, but draws only in pixel mode. He tell me, that no mapping mode can produce as accurate results, as drawing by pixel. One pixel error is very well noticeable, and he is a perfectionist.
My brother just received a new dell d600 laptop. Since the native resolution of the latop is 1400×1050, Dell has elected to enable Large Fonts by default. Even WindowsUpdate has some trouble with it.
It really is a problem that will need to be addressed soon.
I also have a new laptop where large fonts/"non-standard" DPI was enabled by default. IE seemed to try to "upsize" images and they ended up looking very blocky. The standard control panel dialogs also looked very bad. The only thing that really looked good was the start menu/desktop/explorer icons because of the larger icons.
After a couple of hours I switched to the small fonts/96 DPI and suffer with the small fonts and small icons.
I write tax preparation software with Delphi we support 95 at 640×480 through XP on high res multi monitor systems. Our screens are supposed to look like the tax forms and we scale to fit our window. Every pixel counts, we check the DPI and set the font size in points, but that is not enough. The older versions of Windows, with Large Fonts, report 96 DPI and give you a 12 point font when you ask for a 10. XP will work correctly but more than half my users are on 98se or earlier. Every year I google for a way to detect the Large Font setting for these older machines. I was pleased to find this discussion, but sad that I have still not found what I need. I know that Windows95 to 2000 holds a setting when the user has selected Large Fonts, but there still seems to be no way to get that information in my program. I need to know when to ask for an 8 point font when I really want a 10 point font.