How do you detect "Large Fonts"?

oldnewthing

14 Jul 2004 7:00 AM

Comments 58

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:

36 27 45

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.

Code

Comments

Johan Johansson

14 Jul 2004 7:12 AM

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.
Jonathan Payne

14 Jul 2004 7:15 AM

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.
Centaur

14 Jul 2004 8:50 AM

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.
Raymond Chen

14 Jul 2004 8:59 AM

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 Developers' Asia

14 Jul 2004 9:09 AM

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.
Cesar Eduardo Barros

14 Jul 2004 9:39 AM

Every time I tell people I use a 1600x1200 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).
Raymond Chen

14 Jul 2004 9:47 AM

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.
Vlad

14 Jul 2004 9:49 AM

>> If Delphi is so bad
It's not a Delphi so bad - it's just a programmers dont care about DPI.
Cooney

14 Jul 2004 10:03 AM

> Stupid Longhorn screwed up my settings. Microsoft programmers are morons.

Way to personalize everything. The users will bitch no matter what, so do what is _correct_. This means stuff like making DPI-agnostic coding easy and evangelizing it to the masses.
Chris Becke

14 Jul 2004 10:12 AM

>>The problem with DPI on Windows is that it is introduced incorrectly. There should be no Small Fonts and Large Fonts setting because DPI has nothing to do with fonts. In fact, if DPI is set correctly, there should be no difference in apparent size of a font between 640x480 and 1600x1200 because a point (the measuring unit for fonts) is relative to an inch.

Well actually thats the whole point of the trick. The obvious mapping is, there are 72 points in an (virtual) inch, and the display device has some number of dots per virtual inch.

By changing the dots per inch setting, without chaning the physical resolution, the points per dot ratio changes.

In this way, the "Big Fonts" setting is actually entirely correct in its (intended) behaviour as it applies a zoom factor to the entire UI (the entire UI that bothers to MapDialogRect that is).
Raymond Chen

14 Jul 2004 10:27 AM

"making DPI-agnostic coding easy and evangelizing it to the masses". Already done. It's call WinFX. But people complain anyway.
James Mastros

14 Jul 2004 10:50 AM

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.
Peter Smith

14 Jul 2004 10:52 AM

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
Merle

14 Jul 2004 10:56 AM

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.
Phil Weekes

14 Jul 2004 10:57 AM

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.