---
name: "bitmap"
section: "7g"
platform: "linux"
package: "sam"
version: "4.3-18.2"
release: "Debian 5.0 (Lenny)"
platforms: ["linux"]
url: "https://new.carta.tech/bitmap/7g"
---

# bitmap(7g)

external format for bitmaps

## NAME

bitmap - external format for bitmaps

## SYNOPSIS

**#include \<libc.h\>** **#include \<libg.h\>**

## DESCRIPTION

Bitmaps are described in [*graphics*(3g)](/graphics/3g.md). Fonts and bitmaps are stored in external files in machine-independent formats.

Bitmap files are read and written using *rdbitmapfile* and *wrbitmapfile* (see [*balloc*(3g)](/balloc/3g.md)). A bitmap file starts with 5 decimal strings: **ldepth**, **r.min.x**, **r.min.y**, **r.max.x**, and **r.max.y**. Each number is right-justified and blank padded in 11 characters, followed by a blank. The rest of the file contains the **r.max.y**-**r.min.y** rows of bitmap data. A *row* consists of the byte containing pixel **r.min.x** and all the bytes up to and including the byte containing pixel **r.max.x−1.** A pixel with x-coordinate = *x* in a bitmap with **ldepth** = *l* will appear as w = 2^l contiguous bits in a byte, with the pixel's high order bit starting at the byte's bit number w\*(x mod 8/w), where bits within a byte are numbered 0 to 7 from the high order to the low order bit. If *w* is greater than 8, it is a multiple of 8, so pixel values take up an integral number of bytes. Rows contain integral number of bytes, so there may be some unused pixels at either end of a row.

The *rdbitmap* and *wrbitmap* functions described in [*balloc*(3g)](/balloc/3g.md) also deal with rows in this format, stored in user memory.

Some small images, in particular 48×48 face files and 16×16 cursors, are stored textually, suitable for inclusion in C source. Each line of text represents one scan line as a comma-separated sequence of hexadecimal bytes, shorts, or words in C format. For cursors, each line defines a pair of bytes. (It takes two images to define a cursor; each must be stored separately.) Face files of one bit per pixel are stored as a sequence of shorts, those of larger pixel sizes as a sequence of longs. Software that reads these files must deduce the image size from the input; there is no header. These formats reflect history rather than design.

## SEE ALSO

[*graphics*(3g)](/graphics/3g.md), [*bitblt*(3g)](/bitblt/3g.md), [*balloc*(3g)](/balloc/3g.md), [*font*(5g)](/font/5g.md)