Windows 3.1 Device Drivers (ddag31qh.hlp) (Table of Contents; Topic list)
Important Notice
The pages on this site contain documentation for very old MS-DOS software, purely for historical purposes. If you're looking for up-to-date documentation, particularly for programming, you should not rely on the information found here, as it will be woefully out of date.
Device Fonts
                                                     Up Next Previous
────────────────────────────────────────────────────────────────────────────
 
The most common type of device object is a device font. Most printers are
capable of printing some set of built-in fonts. The concept of device fonts
enables drivers and applications to take advantage of a device's ability to
render fonts. Device fonts are also expected to print faster and look better
than GDI fonts.
 
To determine what device fonts are available, GDI calls the EnumDFonts
function and expects the printer driver to enumerate the fonts. Typically,
GDI first calls EnumDFonts passing an empty string for the font name. This
indicates that the driver should enumerate each font name that it supports.
On subsequent calls, GDI passes one of enumerated font names and expects the
driver to enumerate all the sizes of that font.
 
Printer drivers may also wish to support GDI raster and vector fonts. For
banding devices, it is usually not difficult to support GDI raster fonts
because GDI contains support functions to render raster fonts into
monochrome-band bitmaps. GDI raster fonts are most useful for devices (such
as lower-resolution dot-matrix printers) with resolutions near those of the
display.
 
For nonbanding devices, supporting GDI raster fonts is not as easy. In fact,
the PostScript driver (a nonbanding device) does not support GDI raster
fonts.
 
Supporting vector fonts is also optional. If a driver does not support
vector fonts, GDI will simulate them by drawing line segments.
 
 
                                      ♦