JNFR Files (jnlib font resource) store font information. These files are present in the DS firmware program and Mario Kart DS's Kiosk Demo. The format is different in the two cases. This page will outline these formats.

!! Format Version 1.2

This version of the format appears in the DS firmware program (IPL2). It requires the use of a supplemental character map file in the form of a [JNCM File|JNCM]. The header takes the following structure:

||Offset||Type||Meaning
| 0x00  | char[[4] | File signature ({{{"JNFR"}}})
| 0x04  | u16 | Version ({{{0x102}}} for 1.2)
| 0x06  | u16 | Number of glyphs
| 0x08  | u16 | Glyph size. Low 5 bits are glyph width in pixels, the next 5 bits are the glyph height.

Following the header is the glyph width array. These entries take the following structure:

||Offset||Type||Meaning
| 0x00  | u8  | Glyph leading overlap
| 0x01  | u8  | Glyph width

After the glyph width array is the glyph pixel data, which consists of 1-bit-per-pixel bitmap data with a halfword-aligned size.

!! Format Version 2.0

The version of the format used in Mario Kart DS is 2.0, and makes use of a binary block structure. There is also no need for a supplemental JNCM file for character mapping information. The header of the file takes on the following structure:

||Offset||Type||Meaning
| 0x00  | char[[4]| File signature ({{{"JNFR"}}})
| 0x04  | u16 | Version ({{{0x200}}} for 2.0)
| 0x06  | u16 | Endianness ({{{0xFEFF}}} in the used endianness)
| 0x08  | u16 | Number of blocks
| 0x0A  | u16 | Reserved (0)

This header is followed by a sequence of binary blocks. Each block begins with a block header with the following structure:

||Offset||Type||Meaning
| 0x00  | char[[4]| Block signature
| 0x04  | u32 | Block size (including this header)

! IMG1 Block

The {{{IMG1}}} block stores font glyph information. It takes on the following structure:
||Offset||Type||Meaning
| 0x08 | u32 | Offset to glyph bitmap
| 0x0C | u8  | Glyph cell width
| 0x0D | u8  | Glyph cell height
| 0x0E | u8  | Pixel info
| 0x0F | u8  | Leading
| 0x10 | u8  | Ascent
| 0x11 | u8  | Descent
| 0x12 | u16 | Index of invalid glyph

Next is the glyph pixel data, which consists of 1-bit-per-pixel bitmap data.

! WID1 Block

The {{{WID1}}} block stores font glyph width information. Its structure is the following:

||Offset||Type||Meaning
| 0x08  | u32 | Offset to width data
| 0x0C  | u16 | Number of entries
| 0x0E  | u16 | Reserved (0)

Each entry in the width table takes the following structure:

||Offset||Type||Meaning
| 0x00  | u8  | Glyph leading overlap
| 0x01  | u8  | Glyph width

! CMP1 Block

The {{{CMP1}}} block stores the character mapping information. Its structure is the following:

||Offset||Type||Meaning
| 0x08  | u32 | Offset to continuous entries
| 0x0C  | u32 | Offset to direct entries
| 0x10  | u16 | Number of continuous entries
| 0x12  | u16 | Number of direct entries

The continuous mapping entries define the ranges of code points the font has glyphs for. Each code point within the set of contained code points have incrementing glyph indices. The continuous mapping entry takes this structure:

||Offset||type||Meaning
| 0x00  | u16 | Starting code point
| 0x02  | u16 | Ending code point (inclusive)

Next is the direct entries. If a glyph is not found in the continuous glyph map, the direct map is searched next. Each direct entry is a single {{{u16}}} code point. Glyph indices for the direct map come after those in the continuous map.