From e1addf3d35d1cb0e8d30464309a8ed58cad33411 Mon Sep 17 00:00:00 2001 From: Dimitri Sokolyuk Date: Tue, 12 May 2015 21:04:25 +0200 Subject: Add Hershey Fonts --- doc/FONTFMT.TXT | 437 ++++++++++++++++++++++++++++++++++++++++++++++++++++++++ 1 file changed, 437 insertions(+) create mode 100644 doc/FONTFMT.TXT (limited to 'doc/FONTFMT.TXT') diff --git a/doc/FONTFMT.TXT b/doc/FONTFMT.TXT new file mode 100644 index 0000000..fca42f3 --- /dev/null +++ b/doc/FONTFMT.TXT @@ -0,0 +1,437 @@ +INF: Font-File Format [P_WinSDK] + +3.00 +WINDOWS +PSSONLY | Windows 3 Developer's Notes summary ENDUSER + +Summary: + +Note: This article is part of a set of seven articles, collectively +called the "Windows 3.00 Developer's Notes." More information about +the contents of the other articles, and procedures for ordering a +hard-copy set, can be found in the knowledge base article titled "INF: +The Windows 3.00 Developer's Notes" (Q65260). + +This article can be found in the Software/Data Library by searching on +the keyword FONTFMT or S12687. + +More Information: + +Formats for Microsoft Windows font files are defined for both raster +and vector fonts. These formats can be used by smart text generators +in some GDI support modules. The vector formats, in particular, are +more frequently used by GDI itself than by support modules. + + +Both raster and vector font files begin with information that is +common to both, and then continue with information that differs for +each type of file. + +For Windows 3.00, the font-file header includes six new fields: +dFlags, dfAspace, dfBspace, dfCspace, dfColorPointer, and dfReserved1. +These fields are not used in Windows 3.00. To ensure compatibility +with future versions of Windows, these fields should be set to zero. + +All device drivers support the Windows 2.x fonts. However, not all +device drivers support the Windows 3.00 version. + +Windows 3.00 font files include the glyph table in dfCharTable, which +consists of structures that describe the bits for characters in the +font file. This version enables fonts to exceed 64K in size, the size +limit of Windows 2.x fonts. This is made possible by the use of 32-bit +offsets to the character glyphs in dfCharTable. + +Because of the 32-bit offsets and their potentially large size, these +fonts are designed for use on systems that are running Windows version +3.00 in protected (standard or 386 enhanced) mode with an 80386 (or +higher) processor where the processor's 32-bit registers can access +the character glyphs. Typically, device drivers use the Windows 3.00 +version of a font only when both of these conditions are true. + +Font files are stored with an .FNT extension of the form NAME.FNT. The +information at the beginning of both raster and vector versions of +Windows 3.00 font files is shown in the following list: + +Field Description +----- ----------- + +dfVersion 2 bytes specifying the version (0200H or 0300H) of + the file. + +dfSize 4 bytes specifying the total size of the file in + bytes. + +dfCopyright 60 bytes specifying copyright information. + +dfType 2 bytes specifying the type of font file. + + The low-order byte is exclusively for GDI use. If the + low-order bit of the WORD is zero, it is a bitmap + (raster) font file. If the low-order bit is 1, it is a + vector font file. The second bit is reserved and must + be zero. If no bits follow in the file and the bits are + located in memory at a fixed address specified in + dfBitsOffset, the third bit is set to 1; otherwise, the + bit is set to 0 (zero). The high-order bit of the low + byte is set if the font was realized by a device. The + remaining bits in the low byte are reserved and set to + zero. + + The high byte is reserved for device use and will + always be set to zero for GDI-realized standard fonts. + Physical fonts with the high-order bit of the low byte + set may use this byte to describe themselves. GDI will + never inspect the high byte. + +dfPoints 2 bytes specifying the nominal point size at which + this character set looks best. + +dfVertRes 2 bytes specifying the nominal vertical resolution + (dots-per-inch) at which this character set was + digitized. + +dfHorizRes 2 bytes specifying the nominal horizontal resolution + (dots-per-inch) at which this character set was + digitized. + +dfAscent 2 bytes specifying the distance from the top of a + character definition cell to the baseline of the + typographical font. It is useful for aligning the + baselines of fonts of different heights. + +dfInternalLeading + Specifies the amount of leading inside the bounds set + by dfPixHeight. Accent marks may occur in this area. + This may be zero at the designer's option. + +dfExternalLeading + Specifies the amount of extra leading that the designer + requests the application add between rows. Since this + area is outside of the font proper, it contains no + marks and will not be altered by text output calls in + either the OPAQUE or TRANSPARENT mode. This may be zero + at the designer's option. + +dfItalic 1 (one) byte specifying whether or not the character + definition data represent an italic font. The low-order + bit is 1 if the flag is set. All the other bits are + zero. + +dfUnderline 1 byte specifying whether or not the character + definition data represent an underlined font. The + low-order bit is 1 if the flag is set. All the other + bits are 0 (zero). + +dfStrikeOut 1 byte specifying whether or not the character + definition data represent a struckout font. The low- + order bit is 1 if the flag is set. All the other bits + are zero. + +dfWeight 2 bytes specifying the weight of the characters in the + character definition data, on a scale of 1 to 1000. A + dfWeight of 400 specifies a regular weight. + +dfCharSet 1 byte specifying the character set defined by this + font. + +dfPixWidth 2 bytes. For vector fonts, specifies the width of the + grid on which the font was digitized. For raster fonts, + if dfPixWidth is nonzero, it represents the width for + all the characters in the bitmap; if it is zero, the + font has variable width characters whose widths are + specified in the dfCharTable array. + +dfPixHeight 2 bytes specifying the height of the character bitmap + (raster fonts), or the height of the grid on which a + vector font was digitized. + +dfPitchAndFamily + Specifies the pitch and font family. The low bit is set + if the font is variable pitch. The high four bits give + the family name of the font. Font families describe in + a general way the look of a font. They are intended for + specifying fonts when the exact face name desired is + not available. The families are as follows: + + Family Description + ------ ----------- + FF_DONTCARE (0<<4) Don't care or don't know. + FF_ROMAN (1<<4) Proportionally spaced fonts + with serifs. + FF_SWISS (2<<4) Proportionally spaced fonts + without serifs. + FF_MODERN (3<<4) Fixed-pitch fonts. + FF_SCRIPT (4<<4) + FF_DECORATIVE (5<<4) + + +dfAvgWidth 2 bytes specifying the width of characters in the font. + For fixed-pitch fonts, this is the same as dfPixWidth. + For variable-pitch fonts, this is the width of the + character "X." + +dfMaxWidth 2 bytes specifying the maximum pixel width of any + character in the font. For fixed-pitch fonts, this is + simply dfPixWidth. + +dfFirstChar 1 byte specifying the first character code defined by + this font. Character definitions are stored only for + the characters actually present in a font. Therefore, + use this field when calculating indexes into either + dfBits or dfCharOffset. + +dfLastChar 1 byte specifying the last character code defined by + this font. Note that all the characters with codes + between dfFirstChar and dfLastChar must be present in + the font character definitions. + +dfDefaultChar 1 byte specifying the character to substitute + whenever a string contains a character out of the + range. The character is given relative to dfFirstChar + so that dfDefaultChar is the actual value of the + character, less dfFirstChar. The dfDefaultChar should + indicate a special character that is not a space. + +dfBreakChar 1 byte specifying the character that will define word + breaks. This character defines word breaks for word + wrapping and word spacing justification. The character + is given relative to dfFirstChar so that dfBreakChar is + the actual value of the character, less that of + dfFirstChar. The dfBreakChar is normally (32 - + dfFirstChar), which is an ASCII space. + +dfWidthBytes 2 bytes specifying the number of bytes in each row of + the bitmap. This is always even, so that the rows start + on WORD boundaries. For vector fonts, this field has no + meaning. + +dfDevice 4 bytes specifying the offset in the file to the string + giving the device name. For a generic font, this value + is zero. + +dfFace 4 bytes specifying the offset in the file to the + null-terminated string that names the face. + +dfBitsPointer 4 bytes specifying the absolute machine address of + the bitmap. This is set by GDI at load time. The + dfBitsPointer is guaranteed to be even. + +dfBitsOffset 4 bytes specifying the offset in the file to the + beginning of the bitmap information. If the 04H bit in + the dfType is set, then dfBitsOffset is an absolute + address of the bitmap (probably in ROM). + + For raster fonts, dfBitsOffset points to a sequence of + bytes that make up the bitmap of the font, whose height + is the height of the font, and whose width is the sum + of the widths of the characters in the font rounded up + to the next WORD boundary. + + For vector fonts, it points to a string of bytes or + words (depending on the size of the grid on which the + font was digitized) that specify the strokes for each + character of the font. The dfBitsOffset field must be + even. + +dfReserved 1 byte, not used. + +dfFlags 4 bytes specifying the bits flags, which are additional + flags that define the format of the Glyph bitmap, as + follows: + + DFF_FIXED equ 0001h ; font is fixed pitch + DFF_PROPORTIONAL equ 0002h ; font is proportional + ; pitch + DFF_ABCFIXED equ 0004h ; font is an ABC fixed + ; font + DFF_ABCPROPORTIONAL equ 0008h ; font is an ABC pro- + ; portional font + DFF_1COLOR equ 0010h ; font is one color + DFF_16COLOR equ 0020h ; font is 16 color + DFF_256COLOR equ 0040h ; font is 256 color + DFF_RGBCOLOR equ 0080h ; font is RGB color + +dfAspace 2 bytes specifying the global A space, if any. The + dfAspace is the distance from the current position to + the left edge of the bitmap. + +dfBspace 2 bytes specifying the global B space, if any. The + dfBspace is the width of the character. + +dfCspace 2 bytes specifying the global C space, if any. The + dfCspace is the distance from the right edge of the + bitmap to the new current position. The increment of a + character is the sum of the three spaces. These apply + to all glyphs and is the case for DFF_ABCFIXED. + +dfColorPointer + 4 bytes specifying the offset to the color table for + color fonts, if any. The format of the bits is similar + to a DIB, but without the header. That is, the + characters are not split up into disjoint bytes. + Instead, they are left intact. If no color table is + needed, this entry is NULL. + [NOTE: This information is different from that in the + hard-copy Developer's Notes and reflects a correction.] + +dfReserved1 16 bytes, not used. + [NOTE: This information is different from that in the + hard-copy Developer's Notes and reflects a correction.] + +dfCharTable For raster fonts, the CharTable is an array of entries + each consisting of two 2-byte WORDs for Windows 2.x and + three 2-byte WORDs for Windows 3.00. The first WORD of + each entry is the character width. The second WORD of + each entry is the byte offset from the beginning of the + FONTINFO structure to the character bitmap. For Windows + 3.00, the second and third WORDs are used for the + offset. + + There is one extra entry at the end of this table that + describes an absolute-space character. This entry + corresponds to a character that is guaranteed to be + blank; this character is not part of the normal + character set. + + The number of entries in the table is calculated as + ((dfLastChar - dfFirstChar) + 2). This includes a + spare, the sentinel offset mentioned in the following + paragraph. + + For fixed-pitch vector fonts, each 2-byte entry in this + array specifies the offset from the start of the bitmap + to the beginning of the string of stroke specification + units for the character. The number of bytes or WORDs + to be used for a particular character is calculated by + subtracting its entry from the next one, so that there + is a sentinel at the end of the array of values. + + For proportionally spaced vector fonts, each 4-byte + entry is divided into two 2-byte fields. The first + field gives the starting offset from the start of the + bitmap of the character strokes. The second field gives + the pixel width of the character. + + An ASCII character string specifying the name of the + font face. The size of this field is the length of the + string plus a NULL terminator. + + An ASCII character string specifying the name of the + device if this font file is for a specific device. The + size of this field is the length of the string plus a + NULL terminator. + + This field contains the character bitmap definitions. + Each character is stored as a contiguous set of bytes. + (In the old font format, this was not the case.) + + The first byte contains the first 8 bits of the first + scanline (that is, the top line of the character). The + second byte contains the first 8 bits of the second + scanline. This continues until a first "column" is + completely defined. + + The following byte contains the next 8 bits of the + first scanline, padded with zeros on the right if + necessary (and so on, down through the second + "column"). If the glyph is quite narrow, each scanline + is covered by 1 byte, with bits set to zero as + necessary for padding. If the glyph is very wide, a + third or even fourth set of bytes can be present. + + Note: The character bitmaps must be stored + contiguously and arranged in ascending order. + + The following is a single-character example, in which + are given the bytes for a 12 x 14 pixel character, as + shown here schematically. + + ............ + .....**..... + ....*..*.... + ...*....*... + ..*......*.. + ..*......*.. + ..*......*.. + ..********.. + ..*......*.. + ..*......*.. + ..*......*.. + ............ + ............ + ............ + + The bytes are given here in two sets, because the + character is less than 17 pixels wide. + + 00 06 09 10 20 20 20 3F 20 20 20 00 00 00 + 00 00 00 80 40 40 40 C0 40 40 40 00 00 00 + + Note that in the second set of bytes, the second digit + of each is always zero. It would correspond to the 13th + through 16th pixels on the right side of the character, + if they were present. + + +The Windows 2.x version of dfCharTable has a GlyphEntry structure with +the following format: + +GlyphEntry struc +geWidth dw ? ; width of character bitmap in pixels +geOffset dw ? ; pointer to the bits +GlyphEntry ends + +The Windows 3.00 version of the dfCharTable is dependent on the format +of the Glyph bitmap. + + Note: The only formats supported in Windows 3.00 will be DFF_FIXED + and DFF_PROPORTIONAL. + +DFF_FIXED +DFF_PROPORTIONAL + +GlyphEntry struc +geWidth dw ? ; width of character bitmap in pixels +geOffset dd ? ; pointer to the bits +GlyphEntry ends + +DFF_ABCFIXED +DFF_ABCPROPORTIONAL + +GlyphEntry struc +geWidth dw ? ; width of character bitmap in pixels +geOffset dd ? ; pointer to the bits +geAspace dd ? ; A space in fractional pixels (16.16) +geBspace dd ? ; B space in fractional pixels (16.16) +geCspace dw ? ; C space in fractional pixels (16.16) +GlyphEntry ends + +The fractional pixels are expressed as a 32-bit signed number with an +implicit binary point between bits 15 and 16. This is referred to as a +16.16 ("sixteen dot sixteen") fixed-point number. + +The ABC spacing here is the same as that defined above. However, here +there are specific sets for each character. + +DFF_1COLOR +DFF_16COLOR +DFF_256COLOR +DFF_RGBCOLOR + +GlyphEntry struc +geWidth dw ? ; width of character bitmap in pixels +geOffset dd ? ; pointer to the bits +geHeight dw ? ; height of character bitmap in pixels +geAspace dd ? ; A space in fractional pixels (16.16) +geBspace dd ? ; B space in fractional pixels (16.16) +geCspace dd ? ; C space in fractional pixels (16.16) +GlyphEntry ends + +DFF_1COLOR means 8 pixels per byte +DFF_16COLOR means 2 pixels per byte +DFF_256COLOR means 1 pixel per byte +DFF_RGBCOLOR means RGBquads + + +Microsoft is a registered trademark and Windows is a trademark of +Microsoft Corporation. -- cgit v1.2.3