Current Issue

Fonts, Image, Interface Layout Solution under High Resolution - 18 January 2006


by Steven Liu

Read the original Chinese version (translated by Jacky Chan, copy edited by Eleanor Lisney)

For an application to work well under a high resolution display environment, there are four major elements to consider, Text, Fonts, Image (Picture, Icon and Mouse Cursors), Layout Setting and Owner-draw etc.

Preface

Would all the applications work fine under high resolution environment? The answer surely would be negative. Up to now, most of the computer monitor already support 96 dpi resolution, and more and more application programs are required to be run under this resolution too, but there continues the risk caused by increasing of the resolution to be confronted daily. We can now easily buy a notebook computer with 133-dpi LCD monitor, even 170-dpi, it might go up possibly to 200-dpi made available everywhere in several years time. DisplaySearch, a famous industrial magazine predicts at the end of 2k2, up to 40% of laptop computer monitor would have a display with of 100-dpi resolution, and the percentage will keep increasing.

Preview of Common Font Styles under Different Common Resolutions

Figure 1. Preview of Common Font Styles under Different Common Resolutions

Currently, most of the application programs depend highly on the appropriate resolution in order for the perfect display performance of the program output, some application indeed requires high resolution to produce its optimum display performance. In fact, this would deeply be reduced its usability, and it would also cause a number of users to use very large font. Unfortunately, it is not a positive proportion in the case of changing from 130-dpi to 200-dpi, but more seriously, the same application doesn’t work at 96dpi, sometime the size of the fonts or the controls in these kinds of application all together would become smaller, But in most of the cases: a part of the user interface components is display in a correct size. (i.e. application uses default font, so those would be larger from the one in contrast to the original one), but some are incorrect, please refer to the following figure:

Influence Caused by Changing the Resolution

Figure 2. Influence Caused by Changing the Resolution

Therefore, to enhance and improve our application in order to support high resolution display would be an IMPERATIVE task, here the most important standard to bear in mind should be: Image looks better, and the text should also look clearer. For example, a text field which is displayed very clearly on a monitor just like it is printed from a laser printer at 200-dpi (since a computer monitor has more color pixels and more gray level scaling support than the printer, a 200-dpi monitor display quality equals a 600-dpi printer), so that PDA and Smartphone manufactures will take a more important consideration on high resolution display than the one of print.

To develop an application that can work well under multi-resolution is not an easy job, especially to those systems and applications that are already in place; although it may cause a variable end result, we cannot fuss about the quality of the scalability of bitmap and bitmap-font under different resolutions. And since the development of supporting the multi- resolution application would more or less be boring, but if the objective of the developed program is for a special group of people (such as visual impaired, has a long period of working time, etc.), therefore our work becomes more important (under the scenario of high contract and using the big fonts both are related with high resolution).

System Metrics

Windows platform has provided a workable solution to solve the user centric problems under high resolution by Windows itself, we can get the current display resolution by calling the Windows native function GetDeviceCaps(), then by calling the function GetSystemMetrics() and the methods provided by the function that can access the system information and parameters called SystemParametersInfo() to manipulate the image, controls and font styles in inside the Windows platform, from a 3D border effect to the size of a small icon, you can deal with them whatever you want.

System Metrics

The basic principle is by first using the function GetDeviceDaps() for getting the x-axis and y-axis under the current resolution as the basis, then can calculate how much to scale.

Key Issues

During the design process of the high resolution application program, we need pay special attention to four major aspects, Text and Fonts, Image (Image, Icon and Mouse cursor), Layout setup and Owner-draw.

Text and Fonts

There are two type of fonts: Bitmap/Raster font and TrueType font, in order to support high resolution, application should only choose TrueType, since raster fonts can only work under 96-dpi monitor resolution and also cannot be scaled, Windows has already supported TrueType fonts for a long time, so to find a good TrueType font and use it in our application doesn’t cause a big problem. Another main reason for using TrueType font is that, some of the newest technologies, like GDI++, it can only support TureType operations.

Text and Fonts

Default font styles can be gained by Windows handle HWNDs, but what HDCs received is Bitmap (raster) font, so there is the case that when changing from a font to another, no matter missing font is HWNDs or HDC, only if it is a TrueType font, we can definitely change it:

Default font style

HFONT font = (HFONT) GetStockObject (DEFAULT_GUI_FONT);
SendMessage (hwnd, WM_SETFONT, (WPARAM) font, 0);
SelectObject (hdc, font);

When we build up a font in dialogs, we can define the size of the font by pixel measurement, then to adjust the resolution.

Build up a font in dialogs

LOGFONT lf;
Memset (&lf, 0, sizeof (lf));
lf.lfHeight = SCALEY (13);
HFONT font = CreateFontIndirect (&lf);

The alternative method is to use the ‘select font common dialog’ provided by Windows API, it is allowed to use more accurate pixel measurement to redefine the text size, and then convert it into the pixel by some arithmetic, and it can also use TrueType to solve the problem.

'select font common dialog' provided by Windows API

CHOOSEFONT data;
Memset (&data, 0, sizeof (data));
data.lStructSize = sizeof (data);
data.hwndOwner = form;
data.Flags = CF_TTONLY | CF_SCREENFONTS;
ChooseFont (&data);

The best way to solve this problem usually is by this method: define a set of size and a size within a region then use this size as the scale factor as a basis for other elements in the current page, e.g. we can define the space between some buttons as the height of the default fonts, by using function GetTextMetrics() to resize the height of a font.

TEXTMETRIC metrics;
GetTextMetrics (hdc, &metrics);
Int height = metrics.tmHeight;

It is best to avoid the use of the method tmAveCharWidth provided by TEXTMETRIC, since it can only process English characters, on the other hand, we still can use method GetTextExtent() to ensure the scale of all concerned string, we can use GetTextExtentPoint32() to draw a rectangle surrounding a ling of string, like the following figure:

draw a rectangle surrounding a ling of string

SIZE size;
GetTextExtentPoint32 (hdc, string, strlen (string), &size);

Int paddingX = SCALEX (8);
Int paddingY = SCALEX (8);
Rectangle (hdc, x - paddingX, y - paddingY, x + size.cx
+ paddingX, y + size.cy + paddingY);
TextOut (hdc, x, y, string, strlen (string));

Finally, we notice that although TrueType can be scaled to very fine and clear, it is not a linear scaling, that means, whenever 10% percentage of the DPI is increased, not the same proportion (translator note: 10%) of the length of the string is increased, (using GDI+ would not have this problem), because some characters can be viewed fine only under several scale, but TrueType font can self-choose a similar scale for display correctly, it is the reason why using function GetTextExtent.

Image

Image is a kind of document based on raster, (such as BMP, JEPG and GIF), like the icon and mouse cursor. In contrast to the text, it is more difficult to handle the image, because an image is formed by many pixels which are discretely distributed, if there is a difference between the resolution when designed the image and the current viewing resolution, then the image should be resized correctly according to the physical scaling criteria, we can use the function StrectchBlt() to scale a bitmap but not BitBlt(), when an image is loaded into an application, this function can help the application to easily scale the image, and with more accuracy.

BITMAP info;
GetObject (bitmap, sizeof (info), (PTSTR) &info);

HDC hdcBitmap = CreateCompatibleDC (target);
SelectObject (hdcBitmap, bitmap);

StretchBlt (target, x, y,
SCALEX (info.bmWidth), SCALEY (info.bmHeight),
hdcBitmap, 0, 0, info.bmWidth, info.bmHeight, SRCCOPY);
DeleteDC (hdcBitmap);

Truly, the quality must be reduced by the scaling operation, especially in the case that scaled from low resolution to rather high resolution; on the other hand, shrink operation also has some little problem, default is a stretching mode COLORONCOLOR, although the algorithm runs very fast, it lost some details, the speed of the HALFTONE mode scratching calculation is very slow, but scaling quality would be rather better (GDI+ supports a extension option for that)

streching image

SetStretchBltMode (hdc, HALFTONE);

It is specially necessary to point out the possibility to save several image file inside one ICO and .CUR file, so that we doesn’t need to design a set of images under different resolutions, it is recommended to use function GetSystemMetrics() to solve the problem, in the case it is needed to be scaled, system would choose the most suitable image for us. But BMP or most of other file doesn’t support storing several documents inside one document, we can still make a decision to ensure to build which kind of document when Load.

If (GetDeviceCaps (hdc, LOGPIXELSX) < 130) Bitmap = LoadBitmap (hInstance, (char*) IDB_BITMAP1);
Else Bitmap = LoadBitmap (hInstance, (char*) IDB_BITMAP2);

To the special ICON and mouse cursor, currently we use a common size that is 16×16 pixel and 32×32 pixel, high resolution program can support the maximize size up to 64×64 pixel, sure it is not the case of changing the registry. The ideal case is under different resolutions should have a set of corresponding big icons and small icons.

icons

If the program uses HIMAGELIST which is provided by Comctl2.0, it is necessary to scale it to the suitable size before putting into the list, a rather better choice is use the newest technology comctl6.0, but it only be provided by Windows XP, the newest control supports automatically scaling under different resolution (halfton StrechBlt).

User Interface Layout

Another key problem with high resolution is the interface, many dialog use DLU (Dialog Unit) as the format setting unit, since it can be automatically scaled according to the change of system resolution; but the interfaces that are self defined would be needed to manually reset usually, because many interfaces or dialogs theistically works under pixels, we can rearrange the settings of the interface and dialog, for example, it completely uses dialog unit (DLU), although we can call the methods provided by SetWindowPos(), or give up the assumption about DPI and continue to work, let system metrics automatically handles the relationship between those fonts and controls.

Owner-draw

Owner-draw would be the same case as above, sometime we need to draw out the screen and custom controls, also need to care different resolutions. If we develop a self defined control, then it may work under pixel value, but we still need system metrics to avoid the problems caused by the change of resolution, if we are drawing a rather complicated graph, we may use SetMapMode as the image scaling engine.

owner draw

GDI+

GDI+ is the next generation of 2D imaging solution developed by MS, it is also the enhanced and extended version of GDI, GDI+ provides a solution under high resolution, such as linear scaling of text, and image smoothing, a great improvement is done for scaling feature, GDI+ provides many image scaling calculation algorithms that focus on both the performance and quantity aspects, but in contrast to GDI StretchBlt, it does a better performance for manipulating for small images by InterpolationModeBilinear, but it would cause some quality issues, so it is better to use method InterpolationModeHighQuanlityBicubic provided by GDI+.

GDI

Office XP takes the advantage of using GDI+ to enhance reality of its images and graphs, using GDI+, the graphs and the arts text would have a rather smooth outline and adjustable alpha level of the real color. In adjusting the size of the image, it would become clearer.

GDI

On the other hand, GDI+ provides some classes for handling the problems of resolution, such as (Image::GetPhysicalDimension and Bitmap::SetResolution). Those functionscan scale the image suitably by those information, or even let GDI+ engine to do so. In the case that the developer doesn’t define a height and width when calls the method Graphics::DrawImage, GDI+ engine would calculate the image resolution according to the screen resolution.

How to test if any problems exist in the application under high resolution?

Change the system display resolution settings:

  1. In Window platform, right click the mouse at the blank place of desktop;
  2. Left click “porperties”;
  3. Open “setting” tab on the popup dialog and then left click “advance”;
  4. In “general” tab, change the DPI value in the combo box;
  5. Restart Windows;

When testing the program interface layout, more attention should be focus on the following:

  • Whether the text field matches the given space (control or container).
  • Text field overlays with control or leaving some unsuitable space.
  • The size of the text field and image (cannot use or invisible).
  • The size of the image is well suitable, but with low quantity due to scaling.
  • Could hardly notice a thin line (since under 200 dpi, a line with one per one pixel could hardly be seen).

And it is better to have the test of the application under different DPI, since there is a difference in the display accuracy between some of the monitor manufactures, so under 96, 120, 135, 170, 200 dpi, so to have a serious set of testing would be good.

Steven LiuSteven.Liu is the founder of ChinaHCI.Org and Steven.Liu Usability Research and GUI Design Team, Member of ACM SIGCHI and UPA. Focusing on KIOSK and Windows-based, Web-based Design and Analysis all along, he is familiar with User Strategy, User Experience and UI Standard Development.

Comments made

  1. thanks for this support


    20 September 2006, 12:25
  2. Great piece of work


    10 January 2007, 04:27

Add comment

Name
E-mail
http://
Message
  Textile Help

Morae - Usability Testing for Software and Web Sites