A layout is device independent when it appears as intended, regardless of the font typeface or size, dpi (dots per inch), display, or graphic adaptor. To understand the problem, let's first consider what would happen if a dialog box layout is based on physical pixels. The following dialog box layout looks as the designer intended when using 9 pt. Segoe UI at 96 dpi.
However, without scaling this dialog box would become small and the text difficult to read when displayed at 120 dpi:
And it becomes completely unreadable without scaling when printed on a 600 dpi printer.
And finally, the text no longer fits within the controls when displayed in Meiryo:
From these examples, we can see that device independent layout requires legible text regardless of the other display parameters, so the dialog box layout and sizing needs to stay proportional to its text. Microsoft® Windows® traditionally achieves these goals by using dialog units.
A dialog unit (DLU) is a device-independent metric where one horizontal dialog unit equals one-fourth of the average character width for the current font and one vertical dialog unit equals one-eighth of the character height for the current font. Because characters are roughly twice as high as they are wide, a horizontal DLU is roughly the same size as a vertical DLU, but it's important to realize that DLUs are not a square unit.
DLUs are used for sizing and placement in Win32 resource files. Each dialog box template in a resource file defines its font, so that font is used to determine DLUs. Consequently, using multiple fonts in a single program isn't a problem.
As previously demonstrated, physical pixels aren't a device-independent metric, but they benefit from being easy to understand and use. For device independence, newer UI technologies use relative pixels.
A relative pixel is a device-independent metric that is the same as a physical pixel at 96 dpi, but proportionately scaled in other dpis. So, for example, a relative pixel in 120 dpi is equal to 1.25 physical pixels. Of course, relative pixels are a square unit.Relative pixels are used for sizing and layout of dialog boxes in Windows Presentation Foundation (WPF) and WinForms.
While historically most Windows-based computers have used 96 dpi by default, today many laptops are using 120 dpi or higher by default. Using a higher dpi causes Windows to use higher fidelity UI elements, such as larger fonts, icons, and graphics, which take more physical pixels to draw. The result is to lower the effective resolution of a display because more pixels are required to render the UI.
To account for different dpis, screen resolutions are expressed in terms of effective resolution, which is the resolution at 96 dpi and is scaled for other dpis. The table below shows the physical resolutions for common dpi settings for the minimum Windows effective resolution of 800x600 pixels and the recommended Windows effective resolution of 1024x768 pixels.
|dpi||Minimum physical resolution (in pixels)||Recommended minimum physical resolution (in pixels)|
|96 dpi (100%)||800x600||1024x768|
|120 dpi (125%)||1024x768||1280x960|
|144 dpi (150%)||1200x900||1600x1200|
|192 dpi (200%)||1600x1200||2500x1600|
Consequently, stating that the minimum Windows effective resolution is 800x600 pixels means that minimum physical resolution required to support Windows at 120 dpi is 1024x768 pixels. Generally, the effective resolution can be calculated using the following equation:
Effective resolution = Physical resolution x (96 / current dpi setting)
Use effective resolution to refer to screen sizes, but relative pixels to refer to layout sizing and spacing. For example, you could say that the largest window size that will fit in the screen at the minimum Windows effective resolution is 800x600 relative pixelsâ€”which is true regardless of the dpi.
Developers: For more information, check Writing High-DPI Win32 Applications.
You may need to convert layouts and sizes from DLUs to relative pixels and vice versa. However, because DLUs aren't a square unit, the conversion depends upon the axis. Furthermore, because DLUs are based on the font used, the conversion is also font dependent.
Conversion for 9 pt. Segoe UI
1 horizontal DLU = 1.75 relative pixels
1 vertical DLU = 1.875 relative pixels
Dialog unitsPixels horizontalPixels vertical
12 (1.75)2 (1.875)
24 (3.5)4 (3.75)
35 (5.25)6 (5.625)
59 (8.75)9 (9.375)
610 (10.5)11 (11.25)
712 (12.25)13 (13.125)
916 (15.75)17 (16.875)
1017 (17.5)19 (18.75)
1119 (19.25)21 (20.625)
1323 (22.75)24 (24.375)
1424 (24.5)26 (26.25)
1526 (26.25)28 (28.125)
1730 (29.75)32 (31.875)
1831 (31.5)34 (33.75)
1933 (33.25)36 (35.625)
Conversion for 8 pt. Tahoma
1 horizontal DLU = 1.50 relative pixels
1 vertical DLU = 1.625 relative pixels
Dialog unitsPixels horizontalPixels vertical
11 (1.5)2 (1.625)
34 (4.5)5 (4.875)
57 (7.5)8 (8.125)
710 (10.5)11 (11.375)
913 (13.5)15 (14.625)
1116 (16.5)18 (17.875)
1319 (19.5)21 (21.125)
1522 (22.5)24 (24.375)
1725 (25.5)28 (27.625)
1928 (28.5)30 (30.875)
The numbers in parentheses are the exact conversions. Note that unlike other contexts, .5 is rounded down to 0 instead of up to 1.
Measuring controls and text
If you are measuring control sizing and spacing using a graphics program, you might become confused because the numbers might not be what you expect. For example, the standard command button size is 75 x 23 pixels, but when measured it is only 73 x 21 pixels. The discrepancy is that some controls have a one pixel invisible border, which allows the controls to be placed right next to each when laid out using DLUs. Be sure to remember invisible borders when measuring control sizing and spacing.
There is a similar problem when measuring text sizing and spacing with a graphics program. The height of a text control includes the height of the text including its ascenders, descenders, and diacritical marks, plus its spacing (called leading). Thus, the visible sizing and spacing of text may differ from its actual sizing and spacing.