Article ID: 201978
The fonts that reside in printers can sometimes be very useful and difficult to use in application program code. This article describes how to determine which printer-resident device fonts are available for use in a Win32 printer device context. The article also describes several problems that can occur when you try to use those printer fonts in application code.
In most cases, a software developer relies on the operating system to provide the fonts that will be used for its drawing. To do this, you can select an operating system-supplied font through the application programming interface (API) or through the common Choose Font dialog box. However, the application is typically not concerned with the particular font that is used, only that it meets certain requirements and that the user prefers the font. These requirements include:
However, sometimes an application developer may have to select only a certain font specifically from a target printer. Historically, this was necessary on impact-type printers (for example, dot matrix printers) to obtain certain formatting or to speed up the printing.
Today, most printers are fundamentally designed as raster devices and can draw a dot (a pixel) on any part of the paper just as efficiently as all of a character glyph. For most applications, it is not an issue whether a character glyph is drawn as a whole form from a printer-resident definition or is drawn as a collection of pixels that the operating system provides. However, you may still want to use a font that only the printer provides. For example, this may occur because the font is unique and has no similar substitute in the operating system or perhaps because you want to avoid the overhead of downloading a font definition to the printer.
For the purposes of this article, "device fonts" are any fonts whose definition exists either permanently or transiently in the printer's memory. These device fonts provide a character glyph definition that can be addressed per character by the printer's page rasterizer hardware to ink the shape onto paper.
Device fonts can be categorized into three basic types:
Downloadable FontsThe operating system provides downloadable fonts, which are also known as soft fonts. When you print a document, the definition for the font is provided as part of the print job. When the printer processes the print job, the font definition is installed in the printer memory so that the font definition can be inked onto the printed page of the document.
Some argue that because the printer is drawing the character glyphs of the font, these fonts are device fonts. However, when a font definition is downloaded or when a glyph is drawn onto the printer through a bitmap, only some overhead or print job spool size is saved. This process occurs transparently to the application so that the font in the operating system can be used on the screen and on the printer. Because this article focuses on how to use device fonts that only the printer provides, this article does not describe how to use downloadable fonts.
Device Font SubstitutionDevice font substitution occurs when there are two, distinct font definitions: one that the operating system uses, and one that the printer uses. That is, an application selects and uses a font in the operating system in a document on the screen. When you print the document, the printed output is drawn by using the similarly-defined font that the printer provides. Therefore, the font in the operating system has been substituted on the printer with the printer-defined font.
This typically occurs on PostScript printers when a common Windows TrueType font is used. An example of this is the TrueType Arial font that is typically printed by using the PostScript font definition for the Helvetica font on most PostScript devices. This is an example of a substitution by using a similar font whose font name is actually different. In this case, you can typically find and use this similar font definition directly because the similar font definition is also exposed as a true device font. This is discussed later in this article.
Device font substitution also occurs when the font on the printer has the same name as the font that the operating system provides. This typically occurs on printers such as Hewlett-Packard LaserJet printers. Those printers typically have their own versions of the Windows core fonts such as Arial and Times New Roman. Although these fonts can also typically be found by looking for true device fonts, their use sometimes cannot be guaranteed because the printer drivers frequently select on their own or select through user settings whether to use the font that the operating system provides instead.
Device FontsTrue device fonts are those that only have a definition on the printer. The only way that an application can use these fonts is for the application to specifically identify the font and to create it for use in the printer device context.
If you know enough information about a device, you can create a logical font description in a LOGFONT structure that will result in the realization of the device font. In particular, it is important to provide the correct information for the lfFacename member, the lfHeight member, and the character set of the font. Also, the lfOutPrecision member should contain an OUT_DEVICE_PRECIS flag to influence the font mapping process to choose device fonts instead of similarly-named system fonts.
If the description of the font is not known, you can enumerate fonts to discover device fonts. To obtain a list of device fonts that the printer supports, use one of the font enumeration functions such as EnumFontFamiliesEx. Application code that is put in the callback function can examine the data that is handed to the callback function to determine which font instances describe a device font.
Using True Device FontsThe process of using a device font in a printer device context follows these general steps:
Enumerating the Fonts of a Printer Device ContextTo enumerate all of the fonts that are available in a device context, you can use callback functions and the EnumFontFamiliesEx function from the Win32 application programming interface (API). To enumerate all of the fonts for a device context, you must call EnumFontFamiliesEx two times: first to get a list of font families, and a second time to get all of the distinct fonts that are in each font family. For more information about the complete enumeration of system fonts, see the "References" section of this article.
To find all of the device fonts on a printer device context, you must enumerate all of the fonts of the printer device context. When each font is passed to the callback functions, the font is examined to determine if it is a device font. The PrinterDeviceFontEnum and PrinterDeviceFontFamiliesEnum callback functions in the following sample code perform this operation.
You can see in the sample code where the EnumFontFamiliesEx function is called two times. The first call is made in the PrintDeviceFontList function. The second call is in the PrinterDeviceFontFamiliesEnum callback function.
PrintDeviceFontList is the top-level function. PrintDeviceFontList performs two tasks by starting a print job on the printer device context and then invoking the first call to EnumFontFamiliesEx to start the font enumeration process. According to the Platform Software Development Kit (SDK) documentation, when you set the LOGFONT structure's lfCharSet member to the DEFAULT_CHARSET value, EnumFontFamiliesEx enumerates all of the font families. After the font enumeration is complete, the code completes the print job management task by calling the EndDoc method.
The PrinterDeviceFontFamiliesEnum callback function is called for each font family by the EnumFontFamiliesEx function. In that callback function, the code initially screens the font families to find only the device fonts that are marked by the FontType parameter. It also screens out any fonts that are marked as TrueType because those fonts are likely to be downloadable fonts. For those font families that are considered device fonts, the EnumFontFamiliesEx function is called again but is passed the ENUMLOGFONTEX structure that the callback function received. The use of the callback parameter as the input parameter to the second enumeration function call causes the second enumeration to list all of the distinct fonts in that font family.
Selecting Device FontsYou can use certain criteria of printer device fonts to distinguish these fonts from any other font that is enumerated. Specifically, look for the DEVICE_FONTTYPE value in the FontType callback function's DWORD parameter. Almost all of the fonts that are handed to the callback function with this value set are device fonts for the printer device context (except with Adobe fonts).
In the sample code, the PrinterDeviceFontEnum callback function is called by the second enumeration for each distinct font in the font family. The PrinterDeviceFontEnum callback function performs three tasks:
This function detects when a font that is marked as a device font but is not a true device font (according to the definition in this article). This occurs when Adobe fonts are installed into the system through either the Adobe Type Manager or through the native Adobe rasterizer that is present in Microsoft Windows 2000 or Microsoft Windows XP.
When this occurs, the font is really a system-supplied font that is downloaded to the printer, which sometimes occurs with TrueType fonts. Unfortunately, there is no flag that you can use across Windows 98, Windows Millennium Edition (Me), Windows 2000, and Windows XP that indicates that the font is an Adobe font that the system provides (unlike TrueType fonts, which include a flag). There is an indication in the NEWTEXTMETRIC structure's ntmFlags member, but this is only available in Windows 2000 and later. Therefore, the code must resort to a process of elimination. The font is removed when IsSystemFont determines that the device font is provided by both the screen device context and the printer device context.
To avoid repetitious samples of a font that scales, the code also notes when a candidate font has already been used. The specific implementation of this relies on the enumeration order of the fonts to see when sequential enumerations of a font are the same font but in a different scale. To remove fonts that are only a different scale, the code uses the CompareLogFontEx function.
NOTE: The documentation for programming Windows operating systems does not state that font instances that differ only by scale will be enumerated sequentially. The code sample uses this technique because enumeration was seen to work this way, and the reduction in the number of sample lines on the printed page is not a critical feature of the demonstration code. If you want to rely on eliminating different scales of the same font, you must keep a data structure of the device fonts that are used. Then the program must check the currently-enumerated font against that data structure.
Scalable vs. Bitmap FontsThere are two types of device fonts that can be enumerated on printers:
The classic example of a bitmap font is Courier 10 cpi. As the name implies, this font is a hold over from the transition from typewriters to impact-type printers. It is called a bitmap font because the most common definition of the font was located in a ROM bitmap image of a dot matrix printer.
Examples of scalable, printer-resident fonts can be found in most PostScript printers where there is typically a standard set of PostScript fonts such as Helvetica and Times.
Device fonts that are not scalable have a bit that is set in the FontType parameter of the callback function. That bit is represented by the symbol RASTER_FONTTYPE in the SDK. If the FontType parameter to the callback function does not have the RASTER_FONTTYPE bit set, the font is a scalable font. For an example of how to determine this, see the PrinterDeviceFontEnum callback function of the sample code.
Drawing the Device FontsAfter fonts that are device fonts are found, the sample uses them in the printer device context on which the enumeration was performed. Device fonts are used much like other fonts by creating a logical description with the CreateFontIndirect function. This function call is passed the LOGFONT that was passed into the font enumeration callback function. After the HFONT is created, it is used in the printer device context by selecting it into the device context with the SelectObject function call.
Metrics for the device font are obtained through the GetTextMetrics function call. It is best to operate on printer device contexts by using the MM_TEXT mapping mode, which is the default mapping mode for a device context. When you use the MM_TEXT mapping mode, you avoid mathematical errors that can occur during the unit conversion process of other mapping modes.
When you use a device font in a printer device context, you must be careful not to transport the metrics for the font and the strings to other device contexts. This is true particularly of memory device contexts. By definition, a memory device context is not the print job but is a temporary memory buffer of raster graphics and therefore cannot use a device font.
There is another significant consideration when you use printer device fonts: you cannot provide a What-You-See-Is-What-You-Get type preview of the print job. Clearly, fonts that reside in the printer hardware cannot be drawn onto the screen. The closest that you can come to previewing the print job is to find a system-supplied font that has the general characteristics of a printer device font and then draw the glyphs of that font on the screen by using the ExtTextOut function to simulate the placement of the character glyphs on the printed page.
Problems Using Device FontsYou may experience the following problems when you use device fonts:
For additional information, click the article numbers below to view the articles in the Microsoft Knowledge Base:
(https://support.microsoft.com/kb/99672/EN-US/ )INFO: Complete Enumeration of System Fonts
(https://support.microsoft.com/kb/75469/EN-US/ )How To Accurately Showing on the Screen What Will Print
(https://support.microsoft.com/kb/230342/EN-US/ )How To Determine When Font Creation Was Successful
Article ID: 201978 - Last Review: June 22, 2014 - Revision: 4.0