Font Metric Functions

When a driver must support fonts, it must supply font information to GDI through the IFIMETRICS structure. There is a separate IFIMETRICS structure for each font. Most of the fields are expressed in terms of FWORDs, each a signed 16-bit quantity, in the design space. If the font is a raster font, the design space and device space are the same and a font unit is equivalent to the distance between pixels.

Basically, the IFIMETRIC structure is the DDI version of a text-metric structure. All distances refer to the notional coordinate system of the font designer. The notional space coordinate system is a right-handed Cartesian coordinate system in which the y coordinate increases towards the top and the x coordinate increases towards the right.

The IFIMETRICS structure is designed to be of variable length. No restriction is placed on the length of the character strings associated with the font. It is common practice to store the strings immediately following the last field of the IFIMETRICS structure.

Any driver that provides fonts must support the DrvQueryFont function. The driver also can include the function DrvQueryFontData to retrieve information about a realized font. In a call to this function, GDI provides a pointer to an array of glyphs or kerning handles. The driver returns information about associated glyphs in GDI GLYPHDATA structures. If it has been given kerning handles, it returns information about kerning pairs in the form of Win32 POINTL structures. The following table lists the font metric functions.

DrvQueryFontTree allows GDI to obtain pointers to tree structures that define one of the following:

·Mapping from Unicode to glyph handles, including glyph variants (GDI FD_GLYPHSET structure)

·Mapping of kerning pairs to kerning handles (FD_KERNINGPAIRS structure)

DrvQueryFontTree requires effort to generate the needed structures, so the driver should precompute these files if possible. The structures can be stored in a resource or in a file. If the structures are stored in a file, the ideal method for loading or reading them is to call EngMapFontFile, which maps a file to the memory. Because the file does not get added to the swap file, the memory can be made available if needed, which is more efficient than opening and reading in a file.

In particular, the driver returns an identifier in the pid parameter. GDI passes it to DrvFree, with the returned pointer, when the FD_GLYPHSET structure or an array of FD_KERNINGPAIR structures is no longer needed. Depending on how memory is managed in the driver, pid could identify the structure, the way the structure was allocated, or do nothing at all.

DrvFree and DrvDestroyFont are both optional. GDI calls DrvFree to inform the driver that the specified data structure is no longer needed. The driver does not need to implement it unless it allocates memory for the structure and needs to be informed when the corresponding data structure can be released. For example, if the data is associated with the FONTOBJ, the deletion could be deferred until a call to DrvDestroyFont, so it would not be necessary to implement DrvFree.

DrvDestroyFont notifies the driver that a font realization is no longer needed so the driver can free any data structures it allocated. GDI calls this function once for the font producer and once for the font consumer. It should be implemented only if the driver must free allocated resources when the font instance is destroyed.