Click to view graphic (22 KB)
Now that we've nailed down the concept of logical inches and logical twips, it's time to talk about logical fonts.
A logical font is a GDI object whose handle is stored in a variable of type HFONT. A logical font is a description of a font. Like the logical pen and logical brush, it is an abstract object that becomes real only when it is a selected into a device context when an application calls SelectObject. For logical pens, for instance, you can specify any color you want for the pen, but Windows converts that to a pure color available on the device when you select the pen into the device context. Only then does Windows know about the color capabilities of the device.
You create a logical font by calling CreateFont or CreateFontIndirect. The CreateFontIndirect function takes a pointer to a LOGFONT structure, which has 14 fields. The CreateFont function takes 14 arguments, which are identical to the 14 fields of the LOGFONT structure. These are the only two functions that create a logical font. (I mention this because there are multiple functions in Windows for some other font jobs.) Because the 14 fields are difficult to remember, CreateFont is rarely used, so I'll focus on CreateFontIndirect.
There are three basic ways to define the fields of a LOGFONT structure in preparation for calling CreateFontIndirect:
In this chapter, I'll use the first and third approaches.
Here is the process for creating, selecting, and deleting logical fonts:
The GetTextFace function lets a program determine the face name of the font currently selected in the device context:
GetTextFace (hdc, sizeof (szFaceName) / sizeof (TCHAR), szFaceName) ;
The detailed font information is available from GetTextMetrics:
GetTextMetrics (hdc, &textmetric) ;
where textmetric is a variable of type TEXTMETRIC, a structure with 20 fields.
I'll discuss the fields of the LOGFONT and TEXTMETRIC structures in detail shortly. The structures have some similar fields, so they can be confusing. For now, just keep in mind that LOGFONT is for defining a logical font and TEXTMETRIC is for obtaining information about the font currently selected in the device context.
With the PICKFONT program shown in Figure 17-1, you can define many of the fields of a LOGFONT structure. The program creates a logical font and displays the characteristics of the real font after the logical font has been selected in the screen device context. This is a handy program for understanding how logical fonts are mapped to real fonts.
Figure 17-1
The PICKFONT program.
PICKFONT.C |
PICKFONT.RC |
RESOURCE.H |
Figure 17-2 shows a typical PICKFONT screen. The left side of the PICKFONT display is a modeless dialog box that allows you to select most of the fields of the logical font structure. The right side of the dialog box shows the results of GetTextMetrics after the font is selected in the device context. Below the dialog box, the program displays a string of characters using this font. Because the modeless dialog box is so big, you're best off running this program on a display size of 1024 by 768 or larger.
Click to view graphic (22 KB)
Figure 17-2.
A typical PICKFONT display (Unicode version under Windows NT).
The modeless dialog box also contains some options that are not part of the logical font structure. These are the mapping mode, including my Logical Twips mode; the Match Aspect option, which changes the way Windows matches a logical font to a real font; and "Adv Grfx Mode," which sets the advanced graphics mode in Windows NT. I'll discuss these in more detail shortly.
From the Device menu you can select the default printer rather than the video display. In this case, PICKFONT selects the logical font into the printer device context and displays the TEXTMETRIC structure from the printer. The program then selects the logical font into the window device context for displaying the sample string. Thus, the text displayed by the program might use a different font (a screen font) than the font described by the list of the TEXTMETRIC fields (which is a printer font).
Much of the PICKFONT program contains the logic necessary to maintain the dialog box, so I won't go into detail on the workings of the program. Instead, I'll explain what you're doing when you create and select a logical font.
To create a logical font, you can call CreateFont, a function that has 14 arguments. Generally, it's easier to define a structure of type LOGFONT,
LOGFONT lf ;
and then define the fields of this structure. When finish, you call CreateFontIndirect with a pointer to the structure:
hFont = CreatFontIndirect (&lf) ;
You don't need to set each and every field of the LOGFONT structure. If your logical font structure is defined as a static variable, all the fields will be initialized to 0. The 0 values are generally defaults. You can then use that structure directly without any changes, and CreateFontIndirect will return a handle to a font. When you select that font into the device context, you'll get a reasonable default font. You can be as specific or as vague as you want in the LOGFONT structure, and the Windows will attempt to match your requests with a real font.
As I discuss each field of the LOGFONT structure, you may want to test them out using the PICKFONT program. Be sure to press Enter or the OK button when you want the program to use any fields you've entered.
The first two fields of the LOGFONT structure are in logical units, so they depend on the current setting of the mapping mode:
The next two fields specify the "escapement" and "orientation" of the text. In theory, lfEscapement allows character strings to be written at an angle (but with the baseline of each character still parallel to the horizontal axis) and lfOrientation allows individual characters to be tilted. These fields have never quite worked as advertised, and even today they don't work as they should except in one case: you're using a TrueType font, you're running Windows NT, and you call SetGraphicsMode with the CM_ADVANCED flag set. You can accomplish the final requirement in PICKFONT by checking the "Adv Grfx Mode" check box.
To experiment with these fields in PICKFONT, be aware that the units are in tenths of a degree and indicate a counterclockwise rotation. It's easy to enter values that cause the sample text string to disappear! For this reason, use values between 0 and -600 (or so) or values between 3000 and 3600.
| Value | Placement of Characters |
| 0 | Run from left to right (default) |
| 900 | Go up |
| 1800 | Run from right to left |
| 2700 | Go down |
In Windows 98, this value sets both the escapement and orientation of TrueType text. In Windows NT, this value also normally sets both the escapement and orientation of TrueType text, except when you call SetGraphicsMode with the GM_ADVANCED argument, in which case it works as documented.
| Value | Character Appearance |
| 0 | Normal (default) |
| 900 | Tipped 90 degrees to the right |
| 1800 | Upside down |
| 2700 | Tipped 90 degrees to the left |
This field has no effect except with a TrueType font under Windows NT with the graphics mode set to GM_ADVANCED, in which case it works as documented.
The remaining 10 fields follow:
| Value | Identifier |
| 0 | FW_DONTCARE |
| 100 | FW_THIN |
| 200 | FW_EXTRALIGHT or FW_ULTRALIGHT |
| 300 | FW_LIGHT |
| 400 | FW_NORMAL or FW_REGULAR |
| 500 | FW_MEDIUM |
| 600 | FW_SEMIBOLD or FW_DEMIBOLD |
| 700 | FW_BOLD |
| 800 | FW_EXTRABOLD or FW_ULTRABOLD |
| 900 | FW_HEAVY or FW_BLACK |
In reality, this table is much more ambitious than anything that was ever implemented. You can use 0 or 400 for normal and 700 for bold.
Notice that the lfCharSet field is the only field where a zero does not indicate a default value. A zero value is equivalent to ANSI_CHARSET, the ANSI character set used in the United States and Western Europe. The DEFAULT_CHARSET code, which equals 1, indicates the default character set for the machine on which the program is running.
| Value | Identifier |
| 0 | DEFAULT_PITCH |
| 1 | FIXED_PITCH |
| 2 | VARIABLE_PITCH |
The upper half of this byte specifies the font family:
| Value | Identifier |
| 0x00 | FW_DONTCARE |
| 0x10 | FF_ROMAN (variable widths, serifs) |
| 0x20 | FF_SWISS (variable widths, no serifs) |
| 0x30 | FF_MODERN (fixed pitch) |
| 0x40 | FF_SCRIPT (mimics handwriting) |
| 0x50 | FF_DECORATIVE |
After you set up the logical font structure, you call CreateFontIndirect to get a handle to the logical font. When you call SelectObject to select that logical font into a device context, Windows finds the real font that most closely matches the request. In doing so, it uses a "font-mapping algorithm." Certain fields of the structure are more important than other fields.
The best way to get a feel for font mapping is to spend some time experimenting with PICKFONT. Here are some general guidelines:
At the right side of the modeless dialog box in PICKFONT is the information obtained from the GetTextMetrics function after the font has been selected in a device context. (Notice that you can use PICKFONT's device menu to indicate whether you want this device context to be the screen or the default printer. The results might be different because different fonts might be available on the printer.) At the bottom of the list in PICKFONT is the typeface name available from GetTextFace.
All the size values that Windows copies into the TEXTMETRIC structure are in logical units except for the digitized aspect ratios. The fields of the TEXTMETRIC structure are as follows:
| Value | Identifier |
| 0x01 | TMPF_FIXED_PITCH |
| 0x02 | TMPF_VECTOR |
| 0x04 | TMPF_TRUETYPE |
| 0x08 | TMPF_DEVICE |
Despite the name of the TMPF_FIXED_PITCH flag, the lowest bit is 1 if the font characters have a variable pitch. The second lowest bit (TMPF_VECTOR) will be 1 for TrueType fonts and fonts that use other scalable outline technologies, such as PostScript. The TMPF_DEVICE flag indicates a device font (that is, a font built into a printer) rather than a GDI-based font.
The top four bits of this field indicates the font family, which are the same values used in the LOGFONT lfPitchAndFamily field.
I discussed the concept of the Windows character set in Chapter 6, where we had to deal with international issues involving the keyboard. In the LOGFONT and TEXTMETRIC structures, the character set of the desired font (or the actual font) is indicated by a one-byte number between 0 and 255. The character set identifiers are defined in WINGDI.H like so:
#define ANSI_CHARSET 0
#define DEFAULT_CHARSET 1
#define SYMBOL_CHARSET 2
#define MAC_CHARSET 77
#define SHIFTJIS_CHARSET 128
#define HANGEUL_CHARSET 129
#define HANGUL_CHARSET 129
#define JOHAB_CHARSET 130
#define GB2312_CHARSET 134
#define CHINESEBIG5_CHARSET 136
#define GREEK_CHARSET 161
#define TURKISH_CHARSET 162
#define VIETNAMESE_CHARSET 163
#define HEBREW_CHARSET 177
#define ARABIC_CHARSET 178
#define BALTIC_CHARSET 186
#define RUSSIAN_CHARSET 204
#define THAI_CHARSET 222
#define EASTEUROPE_CHARSET 238
#define OEM_CHARSET 255
The character set is similar in concept to the code page, but the character set is specific to Windows and is always less than or equal to 255.
As with all of the programs in this book, you can compile PICKFONT both with and without the UNICODE identifier defined. As usual, on the companion disc, the two versions of the program are located in the DEBUG and RELEASE directories, respectively.
Notice that the character string that PICKFONT displays towards the bottom of its window is longer in the Unicode version of the program. In both versions, the character string begins with the character codes 0x40 through 0x45 and 0x60 through 0x65. Regardless of the character set you choose (except for SYMBOL_CHARSET), these character codes will display as the first five uppercase and lowercase letters of the Latin alphabet (that is, A through E and a through e).
When running the non-Unicode version of the PICKFONT program, the next 12 characters—the character codes 0xC0 through 0xC5 and 0xE0 through 0xE5—will be dependent upon the character set you choose. For ANSI_CHARSET, these character codes correspond to accented versions of the uppercase and lowercase letter A. For GREEK_CHARSET, these codes will correspond to letters of the Greek alphabet. For RUSSIAN_CHARSET, they will be letters of the Cyrillic alphabet. Notice that the font might change when you select one of these character sets. This is because a raster font might not have these characters, but a TrueType font probably will. You'll recall that most TrueType fonts are "big fonts" and include characters for several different character sets. If you're running a Far Eastern version of Windows, these characters will be interpreted as double-byte characters and will display as ideographs rather than letters.
When running the Unicode version of PICKFONT under Windows NT, the codes 0xC0 through 0xC5 and 0xE0 through 0xE5 will always (except for SYMBOL_CHARSET) be accented versions of the uppercase and lowercase letter A because that's how these codes are defined in Unicode. The program also displays character codes 0x0390 through 0x0395 and 0x03B0 through 0x03B5. Because of their definition in Unicode, these codes will always correspond to letters of the Greek alphabet. Similarly the program displays character codes 0x0410 through 0x0415 and 0x0430 through 0x0435, which always correspond to letters in the Cyrillic alphabet. However, note that these characters might not be present in a default font. You may have to select the GREEK_CHARSET or RUSSIAN_CHARSET to get them. In this case, the character set ID in the LOGFONT structure doesn't change the actual character set; the character set is always Unicode. The character set ID instead indicates that characters from this character set are desired.
Now select HEBREW_CHARSET (code 177). The Hebrew alphabet is not included in Windows' usual big fonts, so the operating system picks Lucida Sans Unicode, as you can verify at the bottom right corner of the modeless dialog box.
PICKFONT also displays character codes 0x5000 through 0x5004, which correspond to a few of the many Chinese, Japanese, and Korean ideographs. You'll see these if you're running a Far Eastern version of Windows, or you can download a free Unicode font that is more extensive than Lucida Sans Unicode. This is the Bitstream CyberBit font, available at http://www.bitstream.com/products/world/cyberbits. (Just to give you an idea of the difference, Lucida Sans Unicode is roughly 300K while Bitstream CyberBit is about 13 megabytes.) If you have this font installed, Windows will select it if you want a character set not supported by Lucida Sans Unicode, such as SHIFTJIS_CHARSET (Japanese), HANGUL_CHARSET (Korean), JOHAB_CHARSET (Korean), GB2312_CHARSET (Simplified Chinese), or CHINESEBIG5_CHARSET (Traditional Chinese).
I'll present a program that lets you view all the characters of a Unicode font later in this chapter.
The introduction of TrueType—and its basis in traditional typography—has provided Windows with a solid foundation for displaying text in its many varieties. However, some of the Windows font-selection functions are based on older technology, in which raster fonts on the screen had to approximate printer device fonts. In the next section, I'll describe font enumeration, which lets a program obtain a list of all the fonts available on the video display or printer. However, the ChooseFont dialog box (to be discussed shortly) largely eliminates the necessity for font enumeration by a program.
Because the standard TrueType fonts are available on every system, and because these fonts can be used for both the screen and the printer, it's not necessary for a program to enumerate fonts in order to select one, or to blindly request a certain font type that might need to be approximated. A program could simply and precisely select TrueType fonts that it knows to exist on the system (unless, of course, the user has deliberately deleted them). It really should be almost as simple as specifying the name of the font (probably one of the 13 names listed in this book) and its point size. I call this approach EZFONT ("easy font"), and the two files you need are shown in Figure 17-3.
Figure 17-3
The EZFONT files
EZFONT.H |
EZFONT.C |
EZFONT.C has only one function, called EzCreateFont, which you can use like so:
hFont = EzCreateFont (hdc, szFaceName, iDeciPtHeight, iDeciPtWidth,
iAttributes, fLogRes) ;
The function returns a handle to a font. The font can be selected in the device context by calling SelectObject. You should then call GetTextMetrics or GetOutlineTextMetrics to determine the actual size of the font dimensions in logical coordinates. Before your program terminates, you should delete any created fonts by calling DeleteObject.
The szFaceName argument is any TrueType typeface name. The closer you stick to the standard fonts, the less chance there is that the font won't exist on the system.
The third argument indicates the desired point size, but it's specified in "decipoints," which are 1/10ths of a point. Thus, if you want a point size of 121/2, use a value of 125.
Normally, the fourth argument should be set to zero or made identical to the third argument. However, you can create a TrueType font with a wider or narrower size by setting this argument to something different. This is sometimes called the "em-width" of the font, and it describes the width of the font in points. Don't confuse this with the average width of the font characters or anything like that. Back in the early days of typography, a capital M was as wide as it was high. So, the concept of an "em-square" came into being, and that's the origin of the em-width measurement. When the em-width equals the em-height (the point size of the font), the character widths are as the font designer intended. A smaller or wider em-width lets you create slimmer or wider characters.
You can set the iAttributes argument to one or more of the following values defined in EZFONT.H:
EZ_ATTR_BOLD
EZ_ATTR_ITALIC
EZ_ATTR_UNDERLINE
EZ_ATTR_STRIKEOUT
You could use EZ_ATTR_BOLD or EZ_ATTR_ITALIC or include the style as part of the complete TrueType typeface name.
Finally, you set the last argument to TRUE to base the visible font size on the "logical resolution" returned by the GetDeviceCaps function using the LOGPIXELSX and LOGPIXELSY arguments. Otherwise, the font size is based on the resolution as calculated from the HORZRES, HORZSIZE, VERTRES, and VERTSIZE values. This makes a difference only for the video display under Windows NT.
The EzCreateFont function begins by making some adjustments that are recognized by Windows NT only. These are the calls to the SetGraphicsMode and ModifyWorldTransform functions, which have no effect in Windows 98. The Windows NT world transform should have the effect of modifying the visible size of the font, so the world transform is set to the default—no transform—before the font size is calculated.
EzCreateFont basically sets the fields of a LOGFONT structure and calls CreateFontIndirect, which returns a handle to the font. The big chore of the EzCreateFont function is to convert a point size to logical units for the lfHeight field of the LOGFONT structure. It turns out that the point size must be converted to device units (pixels) first and then to logical units. To perform the first step, the function uses GetDeviceCaps. Getting from pixels to logical units would seem to involve a fairly simple call to the DPtoLP ("device point to logical point") function. But in order for the DPtoLP conversion to work correctly, the same mapping mode must be in effect when you later display text using the created font. This means that you should set your mapping mode before calling the EzCreateFont function. In most cases, you use only one mapping mode for drawing on a particular area of the window, so this requirement should not be a problem.
The EZTEST program in Figure 17-4 tests out the EZFONT files but not too rigorously. This program uses the EZTEST files shown above and also includes FONTDEMO files that are used in some later programs in this book.
Figure 17-4
The EZTEST program
EZTEST.C |
FONTDEMO.C |
FONTDEMO.RC |
RESOURCE.H |
The PaintRoutine function in EZTEST.C sets its mapping mode to Logical Twips and then creates Times New Roman fonts with sizes ranging from 8 points to 12 points in 0.1 point intervals. The program output may be a little disturbing when you first run it. Many of the lines of text use a font that is obviously the same size, and indeed the tmHeight font on the TEXTMETRIC function reports these fonts as having the same height. What's happening here is a result of the rasterization process. The discrete pixels of the display can't allow for every possible size. However, the FONTDEMO shell program allows printing the output as well. Here you'll find that the font sizes are more accurately differentiated.
As you may have discovered by experimenting with PICKFONT, the lfOrientation and lfEscapement fields of the LOGFONT structure allow you to rotate TrueType text. If you think about it, this shouldn't be much of stretch for GDI. Formulas to rotate coordinate points around an origin are well known.
Although EzCreateFont does not allow you to specify a rotation angle for the font, it's fairly easy to make an adjustment after calling the function, as the FONTROT ("Font Rotate") program demonstrates. Figure 17-5 shows the FONTROT.C file; the program also requires the EZFONT files and the FONTDEMO files shown earlier.
Figure 17-5.
The FONTROT program.
FONTROT.C |
FONTROT calls EzCreateFont just to obtain the LOGFONT structure associated with a 54-point Times New Roman font. The program then deletes that font. In the for loop, for each angle in 30 degree increments, a new font is created and the text is displayed. The results are shown in Figure 17-6.
Click to view graphic (17 KB)
Figure 17-6.
The FONTROT display.
If you're interested in a more-generalized approach to graphics rotation and other linear transformation and you know that your programs will be restricted to running under Windows NT, you can use the XFORM matrix and the world transform functions.
Visit Microsoft Press for more information on Programming Windows, Fifth Ed.