Westwood BitFont Format
| Format type | Font |
|---|---|
| Max glyph count | ? |
| Minimum glyph size (pixels) | 0×0 |
| Maximum glyph size (pixels) | 255×? |
| Access mode | Indexed |
| Metadata? | None |
| Bitmap glyphs? | Yes |
| Vector glyphs? | No |
| Compressed glyphs? | No |
| Hidden data? | Yes |
| Games |
In Nox and Red Alert 2, Westwood Studios switched back to using one bit per pixel font types. The result of this was the Westwood BitFont Format.
There are two variants of this font type; one used in Red Alert 2, and one in Nox. The Red Alert 2 ones are present in the game, but were only ever used in their internal map editor, with the font used in the final game being the Unicode BitFont. The Nox one has a slightly different header, but is otherwise identical.
Note that these are not DOS games. This font format is included on this wiki for the sake of completeness in the scope of documenting all indexed graphics formats in the Westwood Studios games.
File format
Header
Though the width and height are saved as 32-bit integers in the header, they are limited by the fact symbol widths in the image data are saved in a single byte, and by the fact the SymbolDataSize, being 1 + (Stride * FontHeight), must also fit in a 32-bit integer.
Red Alert 2
The Red Alert 2 font format starts with the following header. Apparently the game only sees this font type's header as 0x24 bytes long, and the additional 0x0C bytes behind it are considered an extra part.
| Offset | Data type | Name | Description |
|---|---|---|---|
| 0x00 | Char[4] | Format | Literal string "FoNt". |
| 0x04 | UINT32LE | FontWidth? | Unsure. This might be something like the ideograph width in the Unicode variant, which would probably make it act as default space width in case the space character is missing. |
| 0x08 | UINT32LE | Stride | Stride of all font image data. |
| 0x0C | UINT32LE | Lines | Amount of pixel lines stored for each symbol. |
| 0x10 | UINT32LE | FontHeight | Actual font height, in pixels. If this acts like the Unicode variant, this can add a vertical padding to the lines. |
| 0x14 | UINT32LE | Dword10 | Always 0x01. Apparently related to how much extra data is read behind the normal 0x24 byte header. |
| 0x18 | UINT32LE | SymbolDataSize | Size of one symbol data block. Should always match 1 + Stride*Lines.
|
| 0x1C | UINT32LE | Dword1C | Always 0x24. This may refer to the start of the extra data block behind the normal 0x24 header which contains the start and end of the symbols range. |
| 0x20 | UINT32LE | Dword20 | Always 0x30. Could refer to end of the added header part. |
| 0x24 | UINT32LE | Dword24 | Always 0x00. |
| 0x28 | UINT32LE | StartSymbol | First stored symbol. |
| 0x2C | UINT32LE | EndSymbol | Last stored symbol. |
Nox
The Nox font format starts with the following header. It contains a bit less data than the RA2 version, with the start and end symbol stored in 16 bit rather than 32 bit, and without the explicitly saved font height. It is unknown whether this is a cleanup of the RA2 type, or if the RA2 type is expanded as precursor to its upgrade to the Unicode BitFont.
| Offset | Data type | Name | Description |
|---|---|---|---|
| 0x00 | Char[4] | Format | Literal string "tNoF"; same as the RA2 one, but backwards. |
| 0x0x04 | UINT32LE | Dword04 | Always 0x01. |
| 0x0x08 | UINT32LE | FontWidth? | Unsure. This might be something like the ideograph width in the Unicode variant, which would probably make it act as default space width in case the space character is missing. |
| 0x0x0C | UINT32LE | Stride | Stride of all font image data. |
| 0x0x10 | UINT32LE | Lines | Amount of pixel lines stored for each symbol. This also seems to serve as the font height, meaning the Nox type does not support vertical padding below the symbols. |
| 0x0x14 | UINT32LE | Dword14 | Always 0x01. |
| 0x0x18 | UINT32LE | SymbolDataSize | Size of one symbol data block. Should always match 1 + Stride*Lines.
|
| 0x0x1C | UINT32LE | Dword1C | Always 0x00. |
| 0x0x20 | UINT16LE | StartSymbol | First stored symbol. |
| 0x0x22 | UINT16LE | EndSymbol | Last stored symbol. |
Image data
The actual font data is identical in both the RA2 and Nox formats, and is very simply straightforward 1 bit per pixel, using the stride and height indicated in the header. The data is prefixed by a byte that gives the symbol width.
Since all symbol image blocks are the same size, the block of data for a specific symbol inside the range given in the header can be found simply by going to the address HeaderSize + SymbolDataSize * (index - StartSymbol).
| Offset | Data type | Name | Description |
|---|---|---|---|
| 0x00 | UINT8 | SymbolWidth | Width of this symbol. This does not change the stride of the following data, but only limits the final image width to show. |
| 0x01 | BYTE[Stride*FontHeight] | SymbolData | 1-bpp image block with the stride and height given in the header. |
The font does not contain any padding between symbols. Padding was apparently applied automatically by the program using it, and, judging from the Unicode version of the format, seems to be intended as one pixel between the symbols.
Technically, data could be hidden in the SymbolData, in the portion of the full stride that is cut off by the local width value.
Tools
The following tools are able to work with files in this format.
| Name | Platform | View images in this format? | Convert/export to another file/format? | Import from another file/format? | Access hidden data? | Edit metadata? | Notes |
|---|---|---|---|---|---|---|---|
| Westwood Font Editor | Windows | Yes | Yes | Yes | No | N/A |