BDF glyphs

After CHARS (see Header and properties) come that many glyph records, each from STARTCHAR to ENDCHAR, then ENDFONT. A record gives the glyph’s name and code, how far it moves the pen, the box its pixels fill, and the pixels themselves.

Coordinates

All metrics are relative to the glyph’s origin, the point on the baseline where it is drawn. x grows to the right and y grows upwards, so a negative y offset reaches below the baseline. Bitmap rows, however, are listed from the top of the bounding box down.

Glyph keywords

In this order:

Keyword	Values	Meaning
`STARTCHAR`	name	Required. The glyph name, with no spaces, such as `A` or `quoteright`: the name in the PostScript font’s encoding, or in a composite (Type 0) font a number such as a glyph ID. Version 2.1 limits it to 14 characters; 2.2 allows up to 65,535 (section 3.2).
`ENCODING`	code, or `-1`, or `-1` code	Required. See below.
`SWIDTH`	x y	Scalable width: the pen movement for writing direction 0, in thousandths of the point size (the widths of the outline font’s AFM file). y is 0 for ordinary horizontal fonts. Mandatory for direction-0 fonts.
`DWIDTH`	x y	Device width: the same movement in whole pixels, which is what is actually used. y is 0 for ordinary fonts. Mandatory for direction-0 fonts.
`SWIDTH1`	x y	Version 2.2: scalable width for writing direction 1 (vertical), as a vector to the next glyph’s origin.
`DWIDTH1`	x y	Version 2.2: device width for writing direction 1, in whole pixels. With `METRICSSET` 1 or 2 both `SWIDTH1` and `DWIDTH1` must be present; with 0 they should be absent (section 3.2).
`VVECTOR`	x y	Version 2.2: the vector from origin 0 (horizontal writing) to origin 1 (vertical writing). With `METRICSSET` 1 or 2 it must be given either globally or in every glyph; a glyph’s value overrides the global one. The bitmap’s offset from origin 1 is the `BBX` offset minus `VVECTOR`.
`BBX`	width height x-offset y-offset	Required. The bitmap’s size in pixels and the position of its lower-left corner relative to origin 0.
`ATTRIBUTES`	four hex digits	Optional, only in the X Consortium’s 2.1 text, which does not define its meaning. Adobe’s 2.2 document does not have it.
`BITMAP`	none	Required. Followed by one line per pixel row, `height` lines in all.
`ENDCHAR`	none	Required. Ends the glyph.

In version 2.1 SWIDTH and DWIDTH are required in every glyph. In version 2.2 the five metric keywords may instead be given once in the global section for the whole font, and in a font with METRICSSET 1 (vertical only) SWIDTH and DWIDTH are optional.

ENCODING

ENCODING 65: a positive code. For a font with an XLFD name it is a character in the set named by CHARSET_REGISTRY and CHARSET_ENCODING (for ISO10646-1, a Unicode code point); otherwise its meaning depends on the font. Adobe’s 2.2 text defines it as the code in Adobe StandardEncoding.
ENCODING -1: the glyph has no code. Software may drop it, or map it to characters by its name.
ENCODING -1 65: in Adobe’s 2.2 text, a glyph not in StandardEncoding, with its index in the font’s own encoding; the X Consortium’s text treats it as the same as ENCODING 65, an old form not to be used in new fonts.

Scalable and device widths

SWIDTH is the width the designer intended, independent of the device; DWIDTH is the width rounded to pixels for this size and resolution. Converting one to the other:

pixels = SWIDTH × (point size ÷ 1000) × (resolution ÷ 72)

For the 24-point, 75 dpi sample font, an SWIDTH of 355 gives 355 × 0.024 × 75 ÷ 72 = 8.875, and its DWIDTH is 8.

BITMAP rows

Each row is written in hexadecimal, most significant bit first, with the leftmost pixel in the top bit. A set bit is a black (inked) pixel.
A row is padded on the right with zero bits to a whole number of bytes, so it always has an even number of hex digits: a glyph 9 pixels wide uses four digits per row, with the last 7 bits 0.
There are exactly as many rows as the BBX height, the first being the top of the box.
The box’s top row is at y = y-offset + height − 1, and its leftmost column at x = x-offset.

Example

The two glyphs of the sample font in the BDF 2.1 specification (its header is on the Header and properties page):

STARTCHAR j
ENCODING 106
SWIDTH 355 0
DWIDTH 8 0
BBX 9 22 -2 -6
BITMAP
0380
0380
0380
0380
0000
0700
0700
0700
0700
0E00
0E00
0E00
0E00
0E00
1C00
1C00
1C00
1C00
3C00
7800
F000
E000
ENDCHAR
STARTCHAR quoteright
ENCODING 39
SWIDTH 223 0
DWIDTH 5 0
BBX 4 6 2 12
ATTRIBUTES 01C0
BITMAP
70
70
70
60
E0
C0
ENDCHAR
ENDFONT

Line	Meaning
`ENCODING 106`	Code 106 in ISO 8859-1: the letter j.
`DWIDTH 8 0`	After drawing, the pen moves 8 pixels right.
`BBX 9 22 -2 -6`	A box 9 × 22 pixels, starting 2 pixels left of the origin and 6 below the baseline, so it reaches up to y = 15.
`0380`	`0000 0011 1000 0000`: of the 9 pixels, columns 6, 7 and 8 are set (the dot).
`0000`	The gap between the dot and the stem.
rows 17 to 22	The last six rows (`1C00 1C00 3C00 7800 F000 E000`) lie below the baseline and draw the tail, which reaches left of the origin into the space of the glyph before.
`BBX 4 6 2 12`	The apostrophe is a 4 × 6 box from x = 2, sitting 12 to 17 pixels above the baseline.

Drawn out, with # for a set bit, the first 9 bits of each row of j give:

......###   0380 × 4
.........   0000
.....###.   0700 × 4
....###..   0E00 × 5
...###...   1C00 × 4   (the last two of these below the baseline)
..####...   3C00
.####....   7800
####.....   F000
###......   E000

The 2.2 specification’s example of a glyph with metrics for both directions (figure 4):

STARTCHAR c133
ENCODING 39
SWIDTH 1000 0
DWIDTH 22 0
BBX 17 17 2 -5
SWIDTH1 0 -1000
DWIDTH1 0 -22
VVECTOR 10 14

Written horizontally it advances 22 pixels to the right; written vertically it advances 22 pixels down, measured from origin 1, which is 10 pixels right of and 14 above origin 0. Seen from origin 1, the bitmap’s lower-left corner is at (2 − 10, −5 − 14) = (−8, −19).