home
***
CD-ROM
|
disk
|
FTP
|
other
***
search
/
Usenet 1994 October
/
usenetsourcesnewsgroupsinfomagicoctober1994disk2.iso
/
x
/
volume10
/
xv
/
part03
< prev
next >
Wrap
Text File
|
1990-12-08
|
66KB
|
1,617 lines
Path: uunet!fernwood!apple!sun-barr!newstop!exodus!appserv!halibut.cis.upenn.edu
From: bradley@halibut.cis.upenn.edu (John Bradley)
Newsgroups: comp.sources.x
Subject: v10i081: xv - display and manipulate images, Part03/10
Message-ID: <319@appserv.Eng.Sun.COM>
Date: 27 Nov 90 20:08:15 GMT
References: <csx-10i079:xv@uunet.UU.NET>
Sender: news@exodus.Eng.Sun.COM
Lines: 1600
Approved: argv@sun.com
Submitted-by: bradley@halibut.cis.upenn.edu (John Bradley)
Posting-number: Volume 10, Issue 81
Archive-name: xv/part03
#!/bin/sh
# to extract, remove the header and type "sh filename"
if `test ! -d ./bitmaps`
then
mkdir ./bitmaps
echo "mkdir ./bitmaps"
fi
if `test ! -s ./bitmaps/down`
then
echo "writting ./bitmaps/down"
cat > ./bitmaps/down << '\BARFOO\'
#define down_width 16
#define down_height 16
static char down_bits[] = {
0xff, 0xff, 0x01, 0x80, 0x01, 0x80, 0xf1, 0x87, 0x11, 0x84, 0x11, 0x84,
0x11, 0x84, 0x1f, 0xbc, 0x05, 0x90, 0x09, 0x88, 0x11, 0x84, 0x21, 0x82,
0x41, 0x81, 0x81, 0x80, 0x01, 0x80, 0xff, 0xff};
\BARFOO\
else
echo "will not over write ./bitmaps/down"
fi
if `test ! -s ./bitmaps/down1`
then
echo "writting ./bitmaps/down1"
cat > ./bitmaps/down1 << '\BARFOO\'
#define down1_width 16
#define down1_height 16
static char down1_bits[] = {
0xff, 0xff, 0x01, 0x80, 0x01, 0x80, 0xf1, 0x87, 0xf1, 0x87, 0xf1, 0x87,
0xf1, 0x87, 0xff, 0xbf, 0xfd, 0x9f, 0xf9, 0x8f, 0xf1, 0x87, 0xe1, 0x83,
0xc1, 0x81, 0x81, 0x80, 0x01, 0x80, 0xff, 0xff};
\BARFOO\
else
echo "will not over write ./bitmaps/down1"
fi
if `test ! -s ./bitmaps/grasp`
then
echo "writting ./bitmaps/grasp"
cat > ./bitmaps/grasp << '\BARFOO\'
#define grasp_width 64
#define grasp_height 64
static char grasp_bits[] = {
0x00, 0x00, 0x00, 0xbf, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0xc0, 0xff,
0x17, 0x00, 0x00, 0x00, 0x00, 0x00, 0xf0, 0xff, 0xff, 0x05, 0x00, 0x00,
0x00, 0x00, 0xfc, 0xff, 0xff, 0xbf, 0x00, 0x00, 0x00, 0x00, 0xfe, 0xff,
0xff, 0xff, 0x01, 0x00, 0x00, 0x80, 0xff, 0xff, 0xff, 0xff, 0x03, 0x00,
0x00, 0xe0, 0xff, 0xff, 0xff, 0xff, 0x07, 0x00, 0x00, 0xf0, 0xff, 0xff,
0xff, 0xff, 0x0f, 0x00, 0x00, 0xfc, 0xff, 0xff, 0xff, 0xff, 0x1f, 0x00,
0x00, 0xff, 0xff, 0xff, 0xff, 0xff, 0x3f, 0x00, 0xc0, 0xff, 0xff, 0xff,
0xff, 0xff, 0x7f, 0x00, 0xe0, 0xff, 0xff, 0xff, 0xff, 0xff, 0xff, 0x00,
0xf8, 0xff, 0xff, 0xff, 0xff, 0xff, 0xff, 0x01, 0xfe, 0xff, 0xff, 0x07,
0x54, 0xff, 0xff, 0x03, 0xff, 0xff, 0xff, 0x03, 0x00, 0xc0, 0xff, 0x07,
0xff, 0xff, 0xff, 0x01, 0x00, 0x00, 0xff, 0x0f, 0xff, 0xff, 0xff, 0x00,
0x00, 0x00, 0xfe, 0x1f, 0xff, 0xff, 0x7f, 0x00, 0x00, 0x00, 0xf8, 0x3f,
0xff, 0xff, 0x3f, 0x00, 0x00, 0x00, 0xe0, 0x7f, 0xff, 0xff, 0x1f, 0x00,
0x00, 0x00, 0x00, 0x00, 0xff, 0xff, 0x0f, 0x00, 0x00, 0x00, 0x00, 0x00,
0xff, 0xff, 0x07, 0x00, 0x00, 0x00, 0x00, 0x00, 0xff, 0xff, 0x03, 0x00,
0x00, 0x00, 0x00, 0x00, 0xff, 0xff, 0xf9, 0xf8, 0x01, 0x03, 0x8f, 0x3f,
0xff, 0xff, 0xfc, 0xf9, 0x83, 0x83, 0x9f, 0x7f, 0xff, 0x7f, 0xfe, 0xfb,
0x87, 0xc7, 0xbf, 0x7f, 0xff, 0x3f, 0x8e, 0x3b, 0xc7, 0xc7, 0xb9, 0x73,
0x00, 0x00, 0x0e, 0x38, 0xc7, 0xce, 0x83, 0x73, 0x00, 0x00, 0xee, 0xbb,
0xc7, 0x8e, 0x8f, 0x7b, 0x00, 0x00, 0xee, 0xfb, 0xe3, 0x0f, 0x9f, 0x3f,
0x00, 0x00, 0x8e, 0xfb, 0xe1, 0x1f, 0xb8, 0x1f, 0x00, 0x00, 0x9e, 0xbb,
0xe3, 0xde, 0xb9, 0x03, 0x00, 0x00, 0xfc, 0xbb, 0x73, 0xdc, 0xbf, 0x03,
0x00, 0x00, 0xfc, 0x39, 0x77, 0xb8, 0x9f, 0x03, 0x00, 0x00, 0xf0, 0x38,
0x77, 0x38, 0x8f, 0x03, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00,
0x00, 0x00, 0x10, 0x00, 0x00, 0x00, 0x00, 0x00, 0xff, 0x3f, 0x10, 0x20,
0x00, 0x40, 0x00, 0x00, 0xff, 0x7f, 0x10, 0xec, 0xee, 0xec, 0xee, 0x0a,
0xff, 0xff, 0x10, 0xaa, 0x2a, 0x4a, 0x2a, 0x0a, 0xff, 0xff, 0xf1, 0xfe,
0x2e, 0xde, 0x2e, 0x0e, 0xff, 0xff, 0x03, 0x00, 0x00, 0x00, 0x00, 0x08,
0xff, 0xff, 0x07, 0x00, 0x00, 0x00, 0x00, 0x06, 0xff, 0xff, 0x0f, 0x00,
0x00, 0x00, 0x00, 0x00, 0xff, 0xff, 0x1f, 0x00, 0x00, 0x00, 0x00, 0x00,
0xff, 0xff, 0x3f, 0x00, 0x00, 0x00, 0xe0, 0x7f, 0xff, 0xff, 0x7f, 0x00,
0x00, 0x00, 0xf8, 0x3f, 0xff, 0xff, 0xff, 0x00, 0x00, 0x00, 0xfe, 0x1f,
0xff, 0xff, 0xff, 0x01, 0x00, 0x00, 0xff, 0x0f, 0xff, 0xff, 0xff, 0x03,
0x00, 0xc0, 0xff, 0x07, 0xfe, 0xff, 0xff, 0x07, 0x54, 0xff, 0xff, 0x03,
0xf8, 0xff, 0xff, 0xff, 0xff, 0xff, 0xff, 0x01, 0xe0, 0xff, 0xff, 0xff,
0xff, 0xff, 0xff, 0x00, 0x80, 0xff, 0xff, 0xff, 0xff, 0xff, 0x7f, 0x00,
0x00, 0xff, 0xff, 0xff, 0xff, 0xff, 0x3f, 0x00, 0x00, 0xfc, 0xff, 0xff,
0xff, 0xff, 0x1f, 0x00, 0x00, 0xf0, 0xff, 0xff, 0xff, 0xff, 0x0f, 0x00,
0x00, 0xe0, 0xff, 0xff, 0xff, 0xff, 0x07, 0x00, 0x00, 0x80, 0xff, 0xff,
0xff, 0xff, 0x03, 0x00, 0x00, 0x00, 0xfe, 0xff, 0xff, 0xff, 0x01, 0x00,
0x00, 0x00, 0xf8, 0xff, 0xff, 0xbf, 0x00, 0x00, 0x00, 0x00, 0xf0, 0xff,
0xff, 0x05, 0x00, 0x00, 0x00, 0x00, 0xc0, 0xff, 0x17, 0x00, 0x00, 0x00,
0x00, 0x00, 0x00, 0xbf, 0x00, 0x00, 0x00, 0x00};
\BARFOO\
else
echo "will not over write ./bitmaps/grasp"
fi
if `test ! -s ./bitmaps/penn`
then
echo "writting ./bitmaps/penn"
cat > ./bitmaps/penn << '\BARFOO\'
#define penn_width 64
#define penn_height 64
static char penn_bits[] = {
0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00,
0x00, 0x00, 0x00, 0x00, 0x00, 0xf8, 0xff, 0xff, 0xff, 0xff, 0x1f, 0x00,
0x00, 0xf8, 0xff, 0xff, 0xff, 0xff, 0x1f, 0x00, 0x00, 0x18, 0x00, 0x00,
0x00, 0x00, 0x18, 0x00, 0x00, 0xd8, 0xff, 0xff, 0xff, 0xff, 0x1b, 0x00,
0x00, 0xd8, 0xff, 0xff, 0xff, 0xff, 0x1b, 0x00, 0x00, 0xd8, 0xab, 0xff,
0xff, 0xd5, 0x1b, 0x00, 0x00, 0x58, 0x7d, 0xfd, 0xbf, 0xbe, 0x1a, 0x00,
0x00, 0xd8, 0x93, 0x1f, 0xf7, 0xc9, 0x1b, 0x00, 0x00, 0x58, 0x01, 0x0d,
0xb2, 0x80, 0x1a, 0x00, 0x00, 0xd8, 0x11, 0xef, 0xee, 0x88, 0x1b, 0x00,
0x00, 0x58, 0x01, 0x15, 0xad, 0x80, 0x1a, 0x00, 0x00, 0xd8, 0x11, 0x67,
0xe2, 0x88, 0x1b, 0x00, 0x00, 0x58, 0x01, 0xf5, 0xb1, 0x80, 0x1a, 0x00,
0x00, 0xd8, 0x39, 0xff, 0xff, 0x9c, 0x1b, 0x00, 0x00, 0x58, 0xff, 0xfd,
0xbf, 0xff, 0x1a, 0x00, 0x00, 0xd8, 0xaa, 0xfe, 0x7f, 0x55, 0x1b, 0x00,
0x00, 0xd8, 0xff, 0xff, 0xff, 0xff, 0x1b, 0x00, 0x00, 0xd8, 0xff, 0xff,
0xff, 0xff, 0x1b, 0x00, 0x00, 0xd8, 0xff, 0xff, 0xff, 0xff, 0x1b, 0x00,
0x00, 0x58, 0x00, 0x80, 0x01, 0x00, 0x1a, 0x00, 0x00, 0x58, 0x00, 0xc0,
0x03, 0x00, 0x1a, 0x00, 0x00, 0x58, 0x00, 0xe0, 0x07, 0x00, 0x1a, 0x00,
0x00, 0x58, 0x00, 0xf0, 0x0f, 0x00, 0x1a, 0x00, 0x00, 0x58, 0x00, 0xf8,
0x1f, 0x00, 0x1a, 0x00, 0x00, 0x58, 0x00, 0x7c, 0x3e, 0x00, 0x1a, 0x00,
0x00, 0x58, 0x00, 0x1e, 0x78, 0x00, 0x1a, 0x00, 0x00, 0x98, 0x00, 0x1f,
0xf8, 0x00, 0x19, 0x00, 0x00, 0xb8, 0x80, 0x0f, 0xf0, 0x01, 0x1d, 0x00,
0x00, 0xb0, 0xc0, 0x0f, 0xf0, 0x03, 0x0d, 0x00, 0x00, 0xb0, 0xe0, 0x1f,
0xf8, 0x07, 0x0d, 0x00, 0x00, 0xb0, 0xf0, 0x1f, 0xf8, 0x0f, 0x0d, 0x00,
0x00, 0x30, 0x79, 0x7e, 0x7e, 0x9e, 0x0c, 0x00, 0x00, 0x60, 0x1d, 0xf8,
0x1f, 0xb8, 0x06, 0x00, 0x00, 0x60, 0x1f, 0xf8, 0x1f, 0xf8, 0x06, 0x00,
0x00, 0x60, 0x0e, 0xf0, 0x0f, 0x70, 0x06, 0x00, 0x00, 0xc0, 0x0e, 0xf0,
0x0f, 0x70, 0x03, 0x00, 0x00, 0xc0, 0x1c, 0x78, 0x1e, 0x38, 0x03, 0x00,
0x00, 0x80, 0x1d, 0x38, 0x1c, 0xb8, 0x01, 0x00, 0x00, 0x80, 0x79, 0x1e,
0x78, 0x9e, 0x01, 0x00, 0x00, 0x00, 0xfb, 0x0f, 0xf0, 0xdf, 0x00, 0x00,
0x00, 0x00, 0xf3, 0x07, 0xe0, 0xcf, 0x00, 0x00, 0x00, 0x00, 0xe6, 0x03,
0xc0, 0x67, 0x00, 0x00, 0x00, 0x00, 0xec, 0x01, 0x80, 0x37, 0x00, 0x00,
0x00, 0x00, 0xcc, 0x00, 0x00, 0x33, 0x00, 0x00, 0x3c, 0x00, 0x98, 0x00,
0x00, 0x19, 0x00, 0x3c, 0x6e, 0x78, 0x30, 0x01, 0x80, 0x0c, 0x1e, 0x76,
0xda, 0x87, 0x60, 0x06, 0x60, 0x06, 0xe1, 0x5b, 0xfa, 0x88, 0xc1, 0x08,
0x10, 0x83, 0x19, 0x5f, 0x1a, 0x46, 0x81, 0x33, 0xcc, 0x81, 0x72, 0x59,
0xda, 0x70, 0x01, 0xc7, 0xe3, 0x80, 0x0e, 0x59, 0x96, 0xbf, 0x01, 0x1c,
0x38, 0x80, 0xfd, 0x69, 0x60, 0x8a, 0x07, 0x78, 0x1e, 0xe0, 0x59, 0x06,
0xc0, 0xcb, 0x1d, 0xe0, 0x07, 0xb8, 0xd3, 0x03, 0xc0, 0x69, 0xf0, 0x80,
0x01, 0x0f, 0x96, 0x03, 0x00, 0x08, 0x09, 0x1f, 0xf8, 0x60, 0x10, 0x00,
0x00, 0x90, 0x5d, 0xe0, 0x07, 0xf6, 0x08, 0x00, 0x00, 0x60, 0x48, 0x0b,
0xd0, 0x16, 0x06, 0x00, 0x00, 0x80, 0x25, 0xe3, 0xdc, 0x87, 0x01, 0x00,
0x00, 0x00, 0x8e, 0xe4, 0x94, 0x70, 0x00, 0x00, 0x00, 0x00, 0xf0, 0x01,
0x80, 0x0f, 0x00, 0x00, 0x00, 0x00, 0x00, 0xfe, 0x7f, 0x00, 0x00, 0x00,
0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00};
\BARFOO\
else
echo "will not over write ./bitmaps/penn"
fi
if `test ! -s ./bitmaps/scrlgray`
then
echo "writting ./bitmaps/scrlgray"
cat > ./bitmaps/scrlgray << '\BARFOO\'
#define scrlgray_width 8
#define scrlgray_height 8
static char scrlgray_bits[] = {
0x11, 0x44, 0x11, 0x44, 0x11, 0x44, 0x11, 0x44};
\BARFOO\
else
echo "will not over write ./bitmaps/scrlgray"
fi
if `test ! -s ./bitmaps/up`
then
echo "writting ./bitmaps/up"
cat > ./bitmaps/up << '\BARFOO\'
#define up_width 16
#define up_height 16
static char up_bits[] = {
0xff, 0xff, 0x01, 0x80, 0x81, 0x80, 0x41, 0x81, 0x21, 0x82, 0x11, 0x84,
0x09, 0x88, 0x05, 0x90, 0x1f, 0xbc, 0x11, 0x84, 0x11, 0x84, 0x11, 0x84,
0xf1, 0x87, 0x01, 0x80, 0x01, 0x80, 0xff, 0xff};
\BARFOO\
else
echo "will not over write ./bitmaps/up"
fi
if `test ! -s ./bitmaps/up1`
then
echo "writting ./bitmaps/up1"
cat > ./bitmaps/up1 << '\BARFOO\'
#define up1_width 16
#define up1_height 16
static char up1_bits[] = {
0xff, 0xff, 0x01, 0x80, 0x81, 0x80, 0xc1, 0x81, 0xe1, 0x83, 0xf1, 0x87,
0xf9, 0x8f, 0xfd, 0x9f, 0xff, 0xbf, 0xf1, 0x87, 0xf1, 0x87, 0xf1, 0x87,
0xf1, 0x87, 0x01, 0x80, 0x01, 0x80, 0xff, 0xff};
\BARFOO\
else
echo "will not over write ./bitmaps/up1"
fi
if `test ! -s ./bitmaps/gray50`
then
echo "writting ./bitmaps/gray50"
cat > ./bitmaps/gray50 << '\BARFOO\'
#define gray50_width 8
#define gray50_height 8
static char gray50_bits[] = {
0x33, 0xcc, 0x33, 0xcc, 0x33, 0xcc, 0x33, 0xcc};
\BARFOO\
else
echo "will not over write ./bitmaps/gray50"
fi
if `test ! -s ./bitmaps/gray25`
then
echo "writting ./bitmaps/gray25"
cat > ./bitmaps/gray25 << '\BARFOO\'
#define gray25_width 8
#define gray25_height 8
static char gray25_bits[] = {
0x88, 0x22, 0x88, 0x22, 0x88, 0x22, 0x88, 0x22};
\BARFOO\
else
echo "will not over write ./bitmaps/gray25"
fi
if `test ! -s ./bitmaps/i_chr`
then
echo "writting ./bitmaps/i_chr"
cat > ./bitmaps/i_chr << '\BARFOO\'
#define i_chr_width 20
#define i_chr_height 13
static char i_chr_bits[] = {
0xe0, 0x7f, 0x00, 0x20, 0x40, 0x00, 0x20, 0x40, 0x00, 0x20, 0x40, 0x00,
0x20, 0x40, 0x00, 0x20, 0x40, 0x00, 0x20, 0x40, 0x00, 0xe0, 0x7f, 0x00,
0x00, 0x09, 0x00, 0xf0, 0xff, 0x00, 0x50, 0xd5, 0x00, 0xb0, 0xaa, 0x00,
0xf0, 0xff, 0x00};
\BARFOO\
else
echo "will not over write ./bitmaps/i_chr"
fi
if `test ! -s ./bitmaps/i_blk`
then
echo "writting ./bitmaps/i_blk"
cat > ./bitmaps/i_blk << '\BARFOO\'
#define i_blk_width 20
#define i_blk_height 13
static char i_blk_bits[] = {
0x40, 0x00, 0x00, 0xb0, 0x01, 0x00, 0x0c, 0x02, 0x00, 0x03, 0xcc, 0x01,
0x0d, 0x3a, 0x06, 0xb1, 0x19, 0x06, 0x41, 0xe8, 0x05, 0x41, 0x88, 0x04,
0x41, 0x88, 0x04, 0x41, 0x88, 0x04, 0x43, 0x9c, 0x06, 0x4c, 0xb2, 0x01,
0xf0, 0xc1, 0x00};
\BARFOO\
else
echo "will not over write ./bitmaps/i_blk"
fi
if `test ! -s ./bitmaps/i_fifo`
then
echo "writting ./bitmaps/i_fifo"
cat > ./bitmaps/i_fifo << '\BARFOO\'
#define i_fifo_width 20
#define i_fifo_height 13
static char i_fifo_bits[] = {
0x80, 0x0f, 0xf0, 0x80, 0x0f, 0xf0, 0xff, 0xff, 0xff, 0x80, 0x0f, 0xf0,
0xff, 0xff, 0xff, 0xf0, 0x7f, 0xf0, 0xff, 0xff, 0xff, 0xc0, 0x1f, 0xf0,
0xff, 0xff, 0xff, 0x00, 0x07, 0xf0, 0xff, 0xff, 0xff, 0x00, 0x00, 0xf0,
0xff, 0xff, 0xff};
\BARFOO\
else
echo "will not over write ./bitmaps/i_fifo"
fi
if `test ! -s ./bitmaps/i_dir`
then
echo "writting ./bitmaps/i_dir"
cat > ./bitmaps/i_dir << '\BARFOO\'
#define i_dir_width 20
#define i_dir_height 13
static char i_dir_bits[] = {
0xf0, 0x01, 0x00, 0x08, 0x02, 0x00, 0xfe, 0xff, 0x07, 0x02, 0x00, 0x04,
0x02, 0x00, 0x04, 0x02, 0x00, 0x04, 0x02, 0x00, 0x04, 0x02, 0x00, 0x04,
0x02, 0x00, 0x04, 0x02, 0x00, 0x04, 0x02, 0x00, 0x04, 0x02, 0x00, 0x04,
0xfe, 0xff, 0x07};
\BARFOO\
else
echo "will not over write ./bitmaps/i_dir"
fi
if `test ! -s ./bitmaps/i_lnk`
then
echo "writting ./bitmaps/i_lnk"
cat > ./bitmaps/i_lnk << '\BARFOO\'
#define i_lnk_width 20
#define i_lnk_height 13
static char i_lnk_bits[] = {
0x00, 0x00, 0x00, 0x00, 0x40, 0x00, 0x00, 0xc0, 0x01, 0xc0, 0xff, 0x07,
0xe0, 0xff, 0x07, 0x30, 0xc0, 0x01, 0x30, 0x40, 0x00, 0xe0, 0x0f, 0x00,
0xc0, 0x1f, 0x00, 0x00, 0x30, 0x00, 0x00, 0x30, 0x00, 0xfe, 0x1f, 0x00,
0xfe, 0x0f, 0x00};
\BARFOO\
else
echo "will not over write ./bitmaps/i_lnk"
fi
if `test ! -s ./bitmaps/i_sock`
then
echo "writting ./bitmaps/i_sock"
cat > ./bitmaps/i_sock << '\BARFOO\'
#define i_sock_width 20
#define i_sock_height 13
static char i_sock_bits[] = {
0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x80, 0x1f, 0x00, 0x84, 0xf0, 0x0f,
0x8c, 0x10, 0x00, 0x9f, 0x5a, 0x05, 0xbf, 0xb5, 0x0a, 0x9f, 0xff, 0x0f,
0x8c, 0xff, 0x0f, 0x84, 0xff, 0x0f, 0x80, 0x1f, 0x00, 0x00, 0x00, 0x00,
0x00, 0x00, 0x00};
\BARFOO\
else
echo "will not over write ./bitmaps/i_sock"
fi
if `test ! -s ./bitmaps/rb_off`
then
echo "writting ./bitmaps/rb_off"
cat > ./bitmaps/rb_off << '\BARFOO\'
#define rb_off_width 15
#define rb_off_height 15
static char rb_off_bits[] = {
0xe0, 0x03, 0x18, 0x0c, 0x04, 0x10, 0x02, 0x20, 0x02, 0x20, 0x01, 0x40,
0x01, 0x40, 0x01, 0x40, 0x01, 0x40, 0x01, 0x40, 0x02, 0x20, 0x02, 0x20,
0x04, 0x10, 0x18, 0x0c, 0xe0, 0x03};
\BARFOO\
else
echo "will not over write ./bitmaps/rb_off"
fi
if `test ! -s ./bitmaps/i_reg`
then
echo "writting ./bitmaps/i_reg"
cat > ./bitmaps/i_reg << '\BARFOO\'
#define i_reg_width 20
#define i_reg_height 13
static char i_reg_bits[] = {
0xc0, 0x7f, 0x00, 0xa0, 0x40, 0x00, 0x90, 0x40, 0x00, 0xf0, 0x40, 0x00,
0x10, 0x40, 0x00, 0x10, 0x40, 0x00, 0x10, 0x40, 0x00, 0x10, 0x40, 0x00,
0x10, 0x40, 0x00, 0x10, 0x40, 0x00, 0x10, 0x40, 0x00, 0x10, 0x40, 0x00,
0xf0, 0x7f, 0x00};
\BARFOO\
else
echo "will not over write ./bitmaps/i_reg"
fi
if `test ! -s ./bitmaps/fc_left`
then
echo "writting ./bitmaps/fc_left"
cat > ./bitmaps/fc_left << '\BARFOO\'
#define fc_left_width 16
#define fc_left_height 16
static char fc_left_bits[] = {
0x00, 0x00, 0x00, 0x00, 0x00, 0x0f, 0xc0, 0x04, 0x70, 0x82, 0x8c, 0xe2,
0x22, 0x9c, 0x2d, 0x90, 0x2d, 0x80, 0x21, 0x90, 0x22, 0x9c, 0x1c, 0xe3,
0x70, 0x82, 0x80, 0x02, 0x00, 0x07, 0x00, 0x00};
\BARFOO\
else
echo "will not over write ./bitmaps/fc_left"
fi
if `test ! -s ./bitmaps/rb_on`
then
echo "writting ./bitmaps/rb_on"
cat > ./bitmaps/rb_on << '\BARFOO\'
#define rb_on_width 15
#define rb_on_height 15
static char rb_on_bits[] = {
0xe0, 0x03, 0x18, 0x0c, 0x04, 0x10, 0xc2, 0x21, 0xf2, 0x27, 0xf1, 0x47,
0xf9, 0x4f, 0xf9, 0x4f, 0xf9, 0x4f, 0xf1, 0x47, 0xf2, 0x27, 0xc2, 0x21,
0x04, 0x10, 0x18, 0x0c, 0xe0, 0x03};
\BARFOO\
else
echo "will not over write ./bitmaps/rb_on"
fi
if `test ! -s ./bitmaps/rb_on1`
then
echo "writting ./bitmaps/rb_on1"
cat > ./bitmaps/rb_on1 << '\BARFOO\'
#define rb_on1_width 15
#define rb_on1_height 15
static char rb_on1_bits[] = {
0xe0, 0x03, 0xf8, 0x0f, 0x1c, 0x1c, 0xc6, 0x31, 0xf6, 0x37, 0xf3, 0x67,
0xfb, 0x6f, 0xfb, 0x6f, 0xfb, 0x6f, 0xf3, 0x67, 0xf6, 0x37, 0xc6, 0x31,
0x1c, 0x1c, 0xf8, 0x0f, 0xe0, 0x03};
\BARFOO\
else
echo "will not over write ./bitmaps/rb_on1"
fi
if `test ! -s ./bitmaps/rb_off1`
then
echo "writting ./bitmaps/rb_off1"
cat > ./bitmaps/rb_off1 << '\BARFOO\'
#define rb_off1_width 15
#define rb_off1_height 15
static char rb_off1_bits[] = {
0xe0, 0x03, 0xf8, 0x0f, 0x1c, 0x1c, 0x06, 0x30, 0x06, 0x30, 0x03, 0x60,
0x03, 0x60, 0x03, 0x60, 0x03, 0x60, 0x03, 0x60, 0x06, 0x30, 0x06, 0x30,
0x1c, 0x1c, 0xf8, 0x0f, 0xe0, 0x03};
\BARFOO\
else
echo "will not over write ./bitmaps/rb_off1"
fi
if `test ! -s ./bitmaps/grasp.old`
then
echo "writting ./bitmaps/grasp.old"
cat > ./bitmaps/grasp.old << '\BARFOO\'
#define grasp_width 64
#define grasp_height 64
static char grasp_bits[] = {
0x00, 0x00, 0x00, 0x00, 0x00, 0x18, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00,
0x00, 0x3f, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0xe0, 0x7f, 0x00, 0x00,
0x00, 0x00, 0x00, 0x00, 0xfc, 0xff, 0x00, 0x00, 0x00, 0x00, 0x00, 0xc0,
0xff, 0xff, 0x01, 0x00, 0x00, 0x00, 0x00, 0xf8, 0xff, 0xff, 0x03, 0x00,
0x00, 0x00, 0x00, 0xff, 0xff, 0xff, 0x07, 0x00, 0x00, 0x00, 0xe0, 0xff,
0xff, 0xff, 0x0f, 0x00, 0x00, 0x00, 0xfc, 0xff, 0xff, 0xff, 0x1f, 0x00,
0x00, 0x80, 0xff, 0xff, 0xff, 0xff, 0x3f, 0x00, 0x00, 0xf0, 0xff, 0xff,
0xff, 0xff, 0x7f, 0x00, 0x00, 0xff, 0xff, 0xff, 0xff, 0xff, 0xff, 0x00,
0xe0, 0xff, 0xff, 0xff, 0xff, 0xff, 0xff, 0x01, 0xfc, 0xff, 0xff, 0xff,
0xff, 0xff, 0xff, 0x03, 0xff, 0xff, 0xff, 0xff, 0xff, 0xff, 0xff, 0x07,
0xff, 0xff, 0xff, 0xff, 0x01, 0xfe, 0xff, 0x0f, 0xff, 0xff, 0xff, 0x0f,
0x00, 0xf8, 0xff, 0x1f, 0xff, 0xff, 0xff, 0x01, 0x00, 0xf0, 0xff, 0x3f,
0xff, 0xff, 0x7f, 0x00, 0x00, 0xf0, 0xff, 0x7f, 0xff, 0xff, 0x1f, 0x00,
0x00, 0x00, 0x00, 0x00, 0xff, 0xff, 0x07, 0x00, 0x00, 0x00, 0x00, 0x00,
0xff, 0xff, 0x03, 0x00, 0x00, 0x00, 0x00, 0x00, 0xff, 0xff, 0x01, 0x00,
0x00, 0x00, 0x00, 0x00, 0xff, 0xff, 0xf8, 0xf8, 0x01, 0x03, 0x8f, 0x3f,
0xff, 0x7f, 0xfc, 0xf9, 0x83, 0x83, 0x9f, 0x7f, 0xff, 0x3f, 0xfe, 0xfb,
0x87, 0xc7, 0xbf, 0x7f, 0xff, 0x3f, 0x8e, 0x3b, 0xc7, 0xc7, 0xb9, 0x73,
0x00, 0x00, 0x0e, 0x38, 0xc7, 0xce, 0x83, 0x73, 0x00, 0x00, 0xee, 0xbb,
0xc7, 0x8e, 0x8f, 0x7b, 0x00, 0x00, 0xee, 0xfb, 0xe3, 0x0f, 0x9f, 0x3f,
0x00, 0x00, 0x8e, 0xfb, 0xe1, 0x1f, 0xb8, 0x1f, 0x00, 0x00, 0x9e, 0xbb,
0xe3, 0xde, 0xb9, 0x03, 0x00, 0x00, 0xfc, 0xbb, 0x73, 0xdc, 0xbf, 0x03,
0x00, 0x00, 0xfc, 0x39, 0x77, 0xb8, 0x9f, 0x03, 0x00, 0x00, 0xf0, 0x38,
0x77, 0x38, 0x8f, 0x03, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00,
0x00, 0x00, 0x10, 0x00, 0x00, 0x00, 0x00, 0x00, 0xff, 0x3f, 0x10, 0x20,
0x00, 0x40, 0x00, 0x00, 0xff, 0x3f, 0x10, 0xec, 0xee, 0xec, 0xee, 0x0a,
0xff, 0x7f, 0x10, 0xaa, 0x2a, 0x4a, 0x2a, 0x0a, 0xff, 0xff, 0xf0, 0xfe,
0x2e, 0xde, 0x2e, 0x0e, 0xff, 0xff, 0x01, 0x00, 0x00, 0x00, 0x00, 0x08,
0xff, 0xff, 0x03, 0x00, 0x00, 0x00, 0x00, 0x06, 0xff, 0xff, 0x07, 0x00,
0x00, 0x00, 0x00, 0x00, 0xff, 0xff, 0x1f, 0x00, 0x00, 0x00, 0x00, 0x00,
0xff, 0xff, 0x7f, 0x00, 0x00, 0xf0, 0xff, 0x7f, 0xff, 0xff, 0xff, 0x01,
0x00, 0xf0, 0xff, 0x3f, 0xff, 0xff, 0xff, 0x0f, 0x00, 0xf8, 0xff, 0x1f,
0xff, 0xff, 0xff, 0xff, 0x01, 0xfe, 0xff, 0x0f, 0xff, 0xff, 0xff, 0xff,
0xff, 0xff, 0xff, 0x07, 0xfc, 0xff, 0xff, 0xff, 0xff, 0xff, 0xff, 0x03,
0xe0, 0xff, 0xff, 0xff, 0xff, 0xff, 0xff, 0x01, 0x00, 0xff, 0xff, 0xff,
0xff, 0xff, 0xff, 0x00, 0x00, 0xf0, 0xff, 0xff, 0xff, 0xff, 0x7f, 0x00,
0x00, 0x80, 0xff, 0xff, 0xff, 0xff, 0x3f, 0x00, 0x00, 0x00, 0xfc, 0xff,
0xff, 0xff, 0x1f, 0x00, 0x00, 0x00, 0xe0, 0xff, 0xff, 0xff, 0x0f, 0x00,
0x00, 0x00, 0x00, 0xff, 0xff, 0xff, 0x07, 0x00, 0x00, 0x00, 0x00, 0xf8,
0xff, 0xff, 0x03, 0x00, 0x00, 0x00, 0x00, 0xc0, 0xff, 0xff, 0x01, 0x00,
0x00, 0x00, 0x00, 0x00, 0xfc, 0xff, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00,
0xe0, 0x7f, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x3f, 0x00, 0x00,
0x00, 0x00, 0x00, 0x00, 0x00, 0x18, 0x00, 0x00};
\BARFOO\
else
echo "will not over write ./bitmaps/grasp.old"
fi
if `test ! -s ./bitmaps/fc_right`
then
echo "writting ./bitmaps/fc_right"
cat > ./bitmaps/fc_right << '\BARFOO\'
#define fc_right_width 16
#define fc_right_height 16
static char fc_right_bits[] = {
0x00, 0x00, 0x00, 0x00, 0xf0, 0x00, 0x20, 0x03, 0x41, 0x0e, 0x47, 0x30,
0x39, 0x44, 0x09, 0xb4, 0x01, 0xb4, 0x09, 0x84, 0x39, 0x44, 0xc7, 0x38,
0x41, 0x0e, 0x40, 0x01, 0xe0, 0x00, 0x00, 0x00};
\BARFOO\
else
echo "will not over write ./bitmaps/fc_right"
fi
if `test ! -s ./bitmaps/fc_mid`
then
echo "writting ./bitmaps/fc_mid"
cat > ./bitmaps/fc_mid << '\BARFOO\'
#define fc_mid_width 16
#define fc_mid_height 16
static char fc_mid_bits[] = {
0x00, 0x00, 0x00, 0x00, 0x80, 0x03, 0x80, 0x03, 0x40, 0x04, 0x20, 0x08,
0xe0, 0x0e, 0xe0, 0x0e, 0x20, 0x08, 0xa0, 0x0b, 0xe0, 0x0f, 0xa0, 0x0b,
0x40, 0x04, 0x80, 0x03, 0x80, 0x03, 0x00, 0x00};
\BARFOO\
else
echo "will not over write ./bitmaps/fc_mid"
fi
if `test ! -s ./bitmaps/fc_leftm`
then
echo "writting ./bitmaps/fc_leftm"
cat > ./bitmaps/fc_leftm << '\BARFOO\'
#define fc_leftm_width 16
#define fc_leftm_height 16
static char fc_leftm_bits[] = {
0x00, 0x00, 0x00, 0x00, 0x00, 0x0f, 0xc0, 0x07, 0xf0, 0x83, 0xfc, 0xe3,
0xfe, 0xff, 0xff, 0xff, 0xff, 0xff, 0xff, 0xff, 0xfe, 0xff, 0xfc, 0xe3,
0xf0, 0x83, 0x80, 0x03, 0x00, 0x07, 0x00, 0x00};
\BARFOO\
else
echo "will not over write ./bitmaps/fc_leftm"
fi
if `test ! -s ./bitmaps/fc_midm`
then
echo "writting ./bitmaps/fc_midm"
cat > ./bitmaps/fc_midm << '\BARFOO\'
#define fc_midm_width 16
#define fc_midm_height 16
static char fc_midm_bits[] = {
0x00, 0x00, 0x00, 0x00, 0x80, 0x03, 0x80, 0x03, 0xc0, 0x07, 0xe0, 0x0f,
0xe0, 0x0f, 0xe0, 0x0f, 0xe0, 0x0f, 0xe0, 0x0f, 0xe0, 0x0f, 0xe0, 0x0f,
0xc0, 0x07, 0x80, 0x03, 0x80, 0x03, 0x00, 0x00};
\BARFOO\
else
echo "will not over write ./bitmaps/fc_midm"
fi
if `test ! -s ./bitmaps/fc_rightm`
then
echo "writting ./bitmaps/fc_rightm"
cat > ./bitmaps/fc_rightm << '\BARFOO\'
#define fc_rightm_width 16
#define fc_rightm_height 16
static char fc_rightm_bits[] = {
0x00, 0x00, 0x00, 0x00, 0xf0, 0x00, 0xe0, 0x03, 0xc1, 0x0f, 0xc7, 0x3f,
0xff, 0x7f, 0xff, 0xff, 0xff, 0xff, 0xff, 0xff, 0xff, 0x7f, 0xc7, 0x3f,
0xc1, 0x0f, 0xc0, 0x01, 0xe0, 0x00, 0x00, 0x00};
\BARFOO\
else
echo "will not over write ./bitmaps/fc_rightm"
fi
if `test ! -s ./bitmaps/fc_left1`
then
echo "writting ./bitmaps/fc_left1"
cat > ./bitmaps/fc_left1 << '\BARFOO\'
#define fc_left1_width 16
#define fc_left1_height 16
static char fc_left1_bits[] = {
0x00, 0x00, 0x00, 0x00, 0x00, 0x03, 0xc0, 0x02, 0xe0, 0x14, 0x10, 0x1f,
0xd8, 0x14, 0xd8, 0x14, 0x08, 0x10, 0x08, 0x14, 0xd0, 0x14, 0x70, 0x1e,
0x60, 0x13, 0x80, 0x01, 0x00, 0x01, 0x00, 0x00};
\BARFOO\
else
echo "will not over write ./bitmaps/fc_left1"
fi
if `test ! -s ./bitmaps/fc_right1`
then
echo "writting ./bitmaps/fc_right1"
cat > ./bitmaps/fc_right1 << '\BARFOO\'
#define fc_right1_width 16
#define fc_right1_height 16
static char fc_right1_bits[] = {
0x00, 0x00, 0x00, 0x00, 0xc0, 0x00, 0x40, 0x03, 0x28, 0x07, 0xf8, 0x08,
0x28, 0x1b, 0x28, 0x1b, 0x08, 0x10, 0x28, 0x10, 0x28, 0x0b, 0x38, 0x0e,
0xc8, 0x06, 0x80, 0x01, 0x80, 0x00, 0x00, 0x00};
\BARFOO\
else
echo "will not over write ./bitmaps/fc_right1"
fi
if `test ! -s ./bitmaps/fc_right1m`
then
echo "writting ./bitmaps/fc_right1m"
cat > ./bitmaps/fc_right1m << '\BARFOO\'
#define fc_right1m_width 16
#define fc_right1m_height 16
static char fc_right1m_bits[] = {
0x00, 0x00, 0x00, 0x00, 0xc0, 0x00, 0xc0, 0x03, 0xe8, 0x07, 0xf8, 0x0f,
0xf8, 0x1f, 0xf8, 0x1f, 0xf8, 0x1f, 0xf8, 0x1f, 0xf8, 0x0f, 0xf8, 0x0f,
0xc8, 0x07, 0x80, 0x01, 0x80, 0x00, 0x00, 0x00};
\BARFOO\
else
echo "will not over write ./bitmaps/fc_right1m"
fi
if `test ! -s ./bitmaps/fc_left1m`
then
echo "writting ./bitmaps/fc_left1m"
cat > ./bitmaps/fc_left1m << '\BARFOO\'
#define fc_left1m_width 16
#define fc_left1m_height 16
static char fc_left1m_bits[] = {
0x00, 0x00, 0x00, 0x00, 0x00, 0x03, 0xc0, 0x03, 0xe0, 0x17, 0xf0, 0x1f,
0xf8, 0x1f, 0xf8, 0x1f, 0xf8, 0x1f, 0xf8, 0x1f, 0xf0, 0x1f, 0xf0, 0x1f,
0xe0, 0x13, 0x80, 0x01, 0x00, 0x01, 0x00, 0x00};
\BARFOO\
else
echo "will not over write ./bitmaps/fc_left1m"
fi
if `test ! -s ./bitmaps/icon`
then
echo "writting ./bitmaps/icon"
cat > ./bitmaps/icon << '\BARFOO\'
#define icon_width 48
#define icon_height 29
static char icon_bits[] = {
0xff, 0xff, 0xff, 0xff, 0xff, 0xff, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00,
0xff, 0xff, 0xff, 0xff, 0xff, 0xff, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00,
0x3e, 0x00, 0x7c, 0x7c, 0x00, 0x7c, 0x5c, 0x00, 0x2e, 0x5c, 0x00, 0x5c,
0xb8, 0x00, 0x17, 0xb8, 0x00, 0x2e, 0x70, 0x81, 0x0b, 0xb8, 0x00, 0x2e,
0x70, 0x81, 0x0b, 0x70, 0x01, 0x17, 0xe0, 0xc2, 0x05, 0x70, 0x01, 0x17,
0xc0, 0xe5, 0x02, 0xe0, 0x82, 0x0b, 0x80, 0x7b, 0x01, 0xe0, 0x82, 0x0b,
0x00, 0xb7, 0x00, 0xc0, 0xc5, 0x05, 0x00, 0x56, 0x00, 0xc0, 0xc5, 0x05,
0x00, 0x2e, 0x00, 0x80, 0xeb, 0x02, 0x00, 0x56, 0x00, 0x80, 0xeb, 0x02,
0x00, 0xb7, 0x00, 0x00, 0x77, 0x01, 0x80, 0x7b, 0x01, 0x00, 0x77, 0x01,
0xc0, 0xe5, 0x02, 0x00, 0xae, 0x00, 0xe0, 0xc2, 0x05, 0x00, 0xae, 0x00,
0x70, 0x81, 0x0b, 0x00, 0x5c, 0x00, 0x70, 0x81, 0x0b, 0x00, 0x5c, 0x00,
0xb8, 0x00, 0x17, 0x00, 0x38, 0x00, 0x5c, 0x00, 0x2e, 0x00, 0x38, 0x00,
0x3e, 0x00, 0x7c, 0x00, 0x10, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00,
0xff, 0xff, 0xff, 0xff, 0xff, 0xff, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00,
0xff, 0xff, 0xff, 0xff, 0xff, 0xff};
\BARFOO\
else
echo "will not over write ./bitmaps/icon"
fi
if `test ! -d ./docs`
then
mkdir ./docs
echo "mkdir ./docs"
fi
if `test ! -s ./docs/pbm.5`
then
echo "writting ./docs/pbm.5"
cat > ./docs/pbm.5 << '\BARFOO\'
.TH pbm 5 "21 September 1989"
.SH NAME
pbm - portable bitmap file format
.SH DESCRIPTION
The portable bitmap format is a lowest common denominator monochrome
file format.
It was originally designed to make it reasonable to mail bitmaps
between different types of machines using the typical stupid network
mailers we have today.
Now it serves as the common language of a large family of bitmap
conversion filters.
The definition is as follows:
.IP - 2
A "magic number" for identifying the file type.
A pbm file's magic number is the two characters "P1".
.IP - 2
Whitespace (blanks, TABs, CRs, LFs).
.IP - 2
A width, formatted as ASCII characters in decimal.
.IP - 2
Whitespace.
.IP - 2
A height, again in ASCII decimal.
.IP - 2
Whitespace.
.IP - 2
Width * height bits, each either '1' or '0', starting at the top-left
corner of the bitmap, proceding in normal English reading order.
.IP - 2
The character '1' means black, '0' means white.
.IP - 2
Whitespace in the bits section is ignored.
.IP - 2
Characters from a "#" to the next end-of-line are ignored (comments).
.IP - 2
No line should be longer than 70 characters.
.PP
Here is an example of a small bitmap in this format:
.PP
.nf
P1
# feep.pbm
24 7
0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0
0 1 1 1 1 0 0 1 1 1 1 0 0 1 1 1 1 0 0 1 1 1 1 0
0 1 0 0 0 0 0 1 0 0 0 0 0 1 0 0 0 0 0 1 0 0 1 0
0 1 1 1 0 0 0 1 1 1 0 0 0 1 1 1 0 0 0 1 1 1 1 0
0 1 0 0 0 0 0 1 0 0 0 0 0 1 0 0 0 0 0 1 0 0 0 0
0 1 0 0 0 0 0 1 1 1 1 0 0 1 1 1 1 0 0 1 0 0 0 0
0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0
.fi
.PP
Programs that read this format should be as lenient as possible,
accepting anything that looks remotely like a bitmap.
.PP
There is also a variant on the format, available
by setting the RAWBITS option at compile time. This variant is
different in the following ways:
.IP - 2
The "magic number" is "P4" instead of "P1".
.IP - 2
The bits are stored eight per byte, high bit first low bit last.
.IP - 2
No whitespace is allowed in the bits section.
.IP - 2
The files are eight times smaller and many times faster to read and write.
.SH "SEE ALSO"
brushtopbm(1), cmuwmtopbm(1), g3topbm(1), icontopbm(1), gemtopbm(1),
macptopbm(1), mgrtopbm(1), pbmlife(1),
pbmmake(1), pbmmask(1), pbmpaste(1), pbmreduce(1), pbmtoascii(1),
pbmtobbnbg(1), pbmtocmuwm(1), pbmtog3(1), pbmtogo(1), pbmtoicon(1), pbmtolj(1),
pbmtomacp(1), pbmtomgr(1), pbmtoptx(1), pbmtorast(1), pbmtox10bm(1),
pbmtoxbm(1), pbmtoxwd(1), pbmupc(1), pcxtopbm(1), picttopbm(1), rasttopbm(1),
xbmtopbm(1), xwdtopbm(1),
pnm(5), pgm(5), ppm(5)
.SH AUTHOR
Copyright (C) 1989 by Jef Poskanzer.
Permission to use, copy, modify, and distribute this software and its
documentation for any purpose and without fee is hereby granted, provided
that the above copyright notice appear in all copies and that both that
copyright notice and this permission notice appear in supporting
documentation. This software is provided "as is" without express or
implied warranty.
\BARFOO\
else
echo "will not over write ./docs/pbm.5"
fi
if `test ! -s ./docs/pgm.5`
then
echo "writting ./docs/pgm.5"
cat > ./docs/pgm.5 << '\BARFOO\'
.TH pgm 5 "01 August 1989"
.SH NAME
pgm - portable graymap file format
.SH DESCRIPTION
The portable graymap format is a lowest common denominator grayscale
file format.
The definition is as follows:
.IP - 2
A "magic number" for identifying the file type.
A pgm file's magic number is the two characters "P2".
.IP - 2
Whitespace (blanks, TABs, CRs, LFs).
.IP - 2
A width, formatted as ASCII characters in decimal.
.IP - 2
Whitespace.
.IP - 2
A height, again in ASCII decimal.
.IP - 2
Whitespace.
.IP - 2
The maximum gray value, again in ASCII decimal.
.IP - 2
Whitespace.
.IP - 2
Width * height gray values, each in ASCII decimal, between 0 and the specified
maximum value, separated by whitespace, starting at the top-left
corner of the graymap, proceding in normal English reading order.
A value of 0 means black, and the maximum value means white.
.IP - 2
Characters from a "#" to the next end-of-line are ignored (comments).
.IP - 2
No line should be longer than 70 characters.
.PP
Here is an example of a small graymap in this format:
.PP
.nf
P2
# feep.pgm
24 7
15
0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0
0 3 3 3 3 0 0 7 7 7 7 0 0 11 11 11 11 0 0 15 15 15 15 0
0 3 0 0 0 0 0 7 0 0 0 0 0 11 0 0 0 0 0 15 0 0 15 0
0 3 3 3 0 0 0 7 7 7 0 0 0 11 11 11 0 0 0 15 15 15 15 0
0 3 0 0 0 0 0 7 0 0 0 0 0 11 0 0 0 0 0 15 0 0 0 0
0 3 0 0 0 0 0 7 7 7 7 0 0 11 11 11 11 0 0 15 0 0 0 0
0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0
.fi
.PP
Programs that read this format should be as lenient as possible,
accepting anything that looks remotely like a graymap.
.PP
There is also a variant on the format, available
by setting the RAWBITS option at compile time. This variant is
different in the following ways:
.IP - 2
The "magic number" is "P5" instead of "P2".
.IP - 2
The gray values are stored as plain bytes, instead of ASCII decimal.
.IP - 2
No whitespace is allowed in the grays section.
.IP - 2
The files are smaller and many times faster to read and write.
.PP
Note that this raw format can only be used for maxvals less than
or equal to 255.
If you use the PGM library and try to write a file with a larger maxval,
it will automatically fall back on the slower but more general ASCII
format.
.SH "SEE ALSO"
fitstopgm(1), fstopgm(1), hipstopgm(1), psidtopgm(1), rawtopgm(1), tifftopgm(1),
pgmenhance(1), pgmhist(1), pgmnorm(1),
pgmtofits(1), pgmtopbm(1), pgmtops(1),
pnm(5), pbm(5), ppm(5)
.SH AUTHOR
Copyright (C) 1989 by Jef Poskanzer.
Permission to use, copy, modify, and distribute this software and its
documentation for any purpose and without fee is hereby granted, provided
that the above copyright notice appear in all copies and that both that
copyright notice and this permission notice appear in supporting
documentation. This software is provided "as is" without express or
implied warranty.
\BARFOO\
else
echo "will not over write ./docs/pgm.5"
fi
if `test ! -s ./docs/ppm.5`
then
echo "writting ./docs/ppm.5"
cat > ./docs/ppm.5 << '\BARFOO\'
.TH ppm 5 "05 September 1989"
.SH NAME
ppm - portable pixmap file format
.SH DESCRIPTION
The portable pixmap format is a lowest common denominator color image
file format.
The definition is as follows:
.IP - 2
A "magic number" for identifying the file type.
A ppm file's magic number is the two characters "P3".
.IP - 2
Whitespace (blanks, TABs, CRs, LFs).
.IP - 2
A width, formatted as ASCII characters in decimal.
.IP - 2
Whitespace.
.IP - 2
A height, again in ASCII decimal.
.IP - 2
Whitespace.
.IP - 2
The maximum color-component value, again in ASCII decimal.
.IP - 2
Whitespace.
.IP - 2
Width * height pixels, each three ASCII decimal values between 0 and the
specified maximum value, starting at the top-left
corner of the pixmap, proceding in normal English reading order.
The three values for each pixel represent red, green, and blue, respectively;
a value of 0 means that color is off, and the maximum value means that color
is maxxed out.
.IP - 2
Characters from a "#" to the next end-of-line are ignored (comments).
.IP - 2
No line should be longer than 70 characters.
.PP
Here is an example of a small pixmap in this format:
.PP
.nf
P3
# feep.ppm
4 4
15
0 0 0 0 0 0 0 0 0 15 0 15
0 0 0 0 15 7 0 0 0 0 0 0
0 0 0 0 0 0 0 15 7 0 0 0
15 0 15 0 0 0 0 0 0 0 0 0
.fi
.PP
Programs that read this format should be as lenient as possible,
accepting anything that looks remotely like a pixmap.
.PP
There is also a variant on the format, available
by setting the RAWBITS option at compile time. This variant is
different in the following ways:
.IP - 2
The "magic number" is "P6" instead of "P3".
.IP - 2
The pixel values are stored as plain bytes, instead of ASCII decimal.
.IP - 2
Whitespace is not allowed in the pixels area.
.IP - 2
The files are smaller and many times faster to read and write.
.PP
Note that this raw format can only be used for maxvals less than
or equal to 255.
If you use the PPM library and try to write a file with a larger maxval,
it will automatically fall back on the slower but more general ASCII
format.
.SH "SEE ALSO"
giftoppm(1), ilbmtoppm(1), imgtoppm(1), mtvtoppm(1), qrttoppm(1), rasttoppm(1),
tgatoppm(1), xwdtoppm(1),
ppmtogif(1), ppmtoilbm(1), ppmtopgm(1), ppmtops(1), ppmtorast(1), ppmtoxwd(1),
ppmarith(1), ppmconvol(1), ppmcscale(1), ppmhist(1), ppmquant(1), ppmrotate(1),
ppmscale(1), ppmshear(1),
pnm(5), pgm(5), pbm(5)
.SH AUTHOR
Copyright (C) 1989 by Jef Poskanzer.
Permission to use, copy, modify, and distribute this software and its
documentation for any purpose and without fee is hereby granted, provided
that the above copyright notice appear in all copies and that both that
copyright notice and this permission notice appear in supporting
documentation. This software is provided "as is" without express or
implied warranty.
\BARFOO\
else
echo "will not over write ./docs/ppm.5"
fi
if `test ! -s ./docs/gif.doc`
then
echo "writting ./docs/gif.doc"
cat > ./docs/gif.doc << '\BARFOO\'
G I F (tm)
Graphics Interchange Format (tm)
A standard defining a mechanism
for the storage and transmission
of raster-based graphics information
June 15, 1987
(c) CompuServe Incorporated, 1987
All rights reserved
While this document is copyrighted, the information
contained within is made available for use in computer
software without royalties, or licensing restrictions.
GIF and 'Graphics Interchange Format' are trademarks of
CompuServe, Incorporated.
an H&R Block Company
5000 Arlington Centre Blvd.
Columbus, Ohio 43220
(614) 457-8600
Page 2
Graphics Interchange Format (GIF) Specification
Table of Contents
INTRODUCTION . . . . . . . . . . . . . . . . . page 3
GENERAL FILE FORMAT . . . . . . . . . . . . . page 3
GIF SIGNATURE . . . . . . . . . . . . . . . . page 4
SCREEN DESCRIPTOR . . . . . . . . . . . . . . page 4
GLOBAL COLOR MAP . . . . . . . . . . . . . . . page 5
IMAGE DESCRIPTOR . . . . . . . . . . . . . . . page 6
LOCAL COLOR MAP . . . . . . . . . . . . . . . page 7
RASTER DATA . . . . . . . . . . . . . . . . . page 7
GIF TERMINATOR . . . . . . . . . . . . . . . . page 8
GIF EXTENSION BLOCKS . . . . . . . . . . . . . page 8
APPENDIX A - GLOSSARY . . . . . . . . . . . . page 9
APPENDIX B - INTERACTIVE SEQUENCES . . . . . . page 10
APPENDIX C - IMAGE PACKAGING & COMPRESSION . . page 12
APPENDIX D - MULTIPLE IMAGE PROCESSING . . . . page 15
Graphics Interchange Format (GIF) Page 3
Specification
INTRODUCTION
'GIF' (tm) is CompuServe's standard for defining generalized color
raster images. This 'Graphics Interchange Format' (tm) allows
high-quality, high-resolution graphics to be displayed on a variety of
graphics hardware and is intended as an exchange and display mechanism
for graphics images. The image format described in this document is
designed to support current and future image technology and will in
addition serve as a basis for future CompuServe graphics products.
The main focus of this document is to provide the technical
information necessary for a programmer to implement GIF encoders and
decoders. As such, some assumptions are made as to terminology relavent
to graphics and programming in general.
The first section of this document describes the GIF data format
and its components and applies to all GIF decoders, either as standalone
programs or as part of a communications package. Appendix B is a
section relavent to decoders that are part of a communications software
package and describes the protocol requirements for entering and exiting
GIF mode, and responding to host interrogations. A glossary in Appendix
A defines some of the terminology used in this document. Appendix C
gives a detailed explanation of how the graphics image itself is
packaged as a series of data bytes.
Graphics Interchange Format Data Definition
GENERAL FILE FORMAT
+-----------------------+
| +-------------------+ |
| | GIF Signature | |
| +-------------------+ |
| +-------------------+ |
| | Screen Descriptor | |
| +-------------------+ |
| +-------------------+ |
| | Global Color Map | |
| +-------------------+ |
. . . . . .
| +-------------------+ | ---+
| | Image Descriptor | | |
| +-------------------+ | |
| +-------------------+ | |
| | Local Color Map | | |- Repeated 1 to n times
| +-------------------+ | |
| +-------------------+ | |
| | Raster Data | | |
| +-------------------+ | ---+
. . . . . .
|- GIF Terminator -|
+-----------------------+
Graphics Interchange Format (GIF) Page 4
Specification
GIF SIGNATURE
The following GIF Signature identifies the data following as a
valid GIF image stream. It consists of the following six characters:
G I F 8 7 a
The last three characters '87a' may be viewed as a version number
for this particular GIF definition and will be used in general as a
reference in documents regarding GIF that address any version
dependencies.
SCREEN DESCRIPTOR
The Screen Descriptor describes the overall parameters for all GIF
images following. It defines the overall dimensions of the image space
or logical screen required, the existance of color mapping information,
background screen color, and color depth information. This information
is stored in a series of 8-bit bytes as described below.
bits
7 6 5 4 3 2 1 0 Byte #
+---------------+
| | 1
+-Screen Width -+ Raster width in pixels (LSB first)
| | 2
+---------------+
| | 3
+-Screen Height-+ Raster height in pixels (LSB first)
| | 4
+-+-----+-+-----+ M = 1, Global color map follows Descriptor
|M| cr |0|pixel| 5 cr+1 = # bits of color resolution
+-+-----+-+-----+ pixel+1 = # bits/pixel in image
| background | 6 background=Color index of screen background
+---------------+ (color is defined from the Global color
|0 0 0 0 0 0 0 0| 7 map or default map if none specified)
+---------------+
The logical screen width and height can both be larger than the
physical display. How images larger than the physical display are
handled is implementation dependent and can take advantage of hardware
characteristics (e.g. Macintosh scrolling windows). Otherwise images
can be clipped to the edges of the display.
The value of 'pixel' also defines the maximum number of colors
within an image. The range of values for 'pixel' is 0 to 7 which
represents 1 to 8 bits. This translates to a range of 2 (B & W) to 256
colors. Bit 3 of word 5 is reserved for future definition and must be
zero.
Graphics Interchange Format (GIF) Page 5
Specification
GLOBAL COLOR MAP
The Global Color Map is optional but recommended for images where
accurate color rendition is desired. The existence of this color map is
indicated in the 'M' field of byte 5 of the Screen Descriptor. A color
map can also be associated with each image in a GIF file as described
later. However this global map will normally be used because of
hardware restrictions in equipment available today. In the individual
Image Descriptors the 'M' flag will normally be zero. If the Global
Color Map is present, it's definition immediately follows the Screen
Descriptor. The number of color map entries following a Screen
Descriptor is equal to 2**(# bits per pixel), where each entry consists
of three byte values representing the relative intensities of red, green
and blue respectively. The structure of the Color Map block is:
bits
7 6 5 4 3 2 1 0 Byte #
+---------------+
| red intensity | 1 Red value for color index 0
+---------------+
|green intensity| 2 Green value for color index 0
+---------------+
| blue intensity| 3 Blue value for color index 0
+---------------+
| red intensity | 4 Red value for color index 1
+---------------+
|green intensity| 5 Green value for color index 1
+---------------+
| blue intensity| 6 Blue value for color index 1
+---------------+
: : (Continues for remaining colors)
Each image pixel value received will be displayed according to its
closest match with an available color of the display based on this color
map. The color components represent a fractional intensity value from
none (0) to full (255). White would be represented as (255,255,255),
black as (0,0,0) and medium yellow as (180,180,0). For display, if the
device supports fewer than 8 bits per color component, the higher order
bits of each component are used. In the creation of a GIF color map
entry with hardware supporting fewer than 8 bits per component, the
component values for the hardware should be converted to the 8-bit
format with the following calculation:
<map_value> = <component_value>*255/(2**<nbits> -1)
This assures accurate translation of colors for all displays. In
the cases of creating GIF images from hardware without color palette
capability, a fixed palette should be created based on the available
display colors for that hardware. If no Global Color Map is indicated,
a default color map is generated internally which maps each possible
incoming color index to the same hardware color index modulo <n> where
<n> is the number of available hardware colors.
Graphics Interchange Format (GIF) Page 6
Specification
IMAGE DESCRIPTOR
The Image Descriptor defines the actual placement and extents of
the following image within the space defined in the Screen Descriptor.
Also defined are flags to indicate the presence of a local color lookup
map, and to define the pixel display sequence. Each Image Descriptor is
introduced by an image separator character. The role of the Image
Separator is simply to provide a synchronization character to introduce
an Image Descriptor. This is desirable if a GIF file happens to contain
more than one image. This character is defined as 0x2C hex or ','
(comma). When this character is encountered between images, the Image
Descriptor will follow immediately.
Any characters encountered between the end of a previous image and
the image separator character are to be ignored. This allows future GIF
enhancements to be present in newer image formats and yet ignored safely
by older software decoders.
bits
7 6 5 4 3 2 1 0 Byte #
+---------------+
|0 0 1 0 1 1 0 0| 1 ',' - Image separator character
+---------------+
| | 2 Start of image in pixels from the
+- Image Left -+ left side of the screen (LSB first)
| | 3
+---------------+
| | 4
+- Image Top -+ Start of image in pixels from the
| | 5 top of the screen (LSB first)
+---------------+
| | 6
+- Image Width -+ Width of the image in pixels (LSB first)
| | 7
+---------------+
| | 8
+- Image Height-+ Height of the image in pixels (LSB first)
| | 9
+-+-+-+-+-+-----+ M=0 - Use global color map, ignore 'pixel'
|M|I|0|0|0|pixel| 10 M=1 - Local color map follows, use 'pixel'
+-+-+-+-+-+-----+ I=0 - Image formatted in Sequential order
I=1 - Image formatted in Interlaced order
pixel+1 - # bits per pixel for this image
The specifications for the image position and size must be confined
to the dimensions defined by the Screen Descriptor. On the other hand
it is not necessary that the image fill the entire screen defined.
LOCAL COLOR MAP
Graphics Interchange Format (GIF) Page 7
Specification
A Local Color Map is optional and defined here for future use. If
the 'M' bit of byte 10 of the Image Descriptor is set, then a color map
follows the Image Descriptor that applies only to the following image.
At the end of the image, the color map will revert to that defined after
the Screen Descriptor. Note that the 'pixel' field of byte 10 of the
Image Descriptor is used only if a Local Color Map is indicated. This
defines the parameters not only for the image pixel size, but determines
the number of color map entries that follow. The bits per pixel value
will also revert to the value specified in the Screen Descriptor when
processing of the image is complete.
RASTER DATA
The format of the actual image is defined as the series of pixel
color index values that make up the image. The pixels are stored left
to right sequentially for an image row. By default each image row is
written sequentially, top to bottom. In the case that the Interlace or
'I' bit is set in byte 10 of the Image Descriptor then the row order of
the image display follows a four-pass process in which the image is
filled in by widely spaced rows. The first pass writes every 8th row,
starting with the top row of the image window. The second pass writes
every 8th row starting at the fifth row from the top. The third pass
writes every 4th row starting at the third row from the top. The fourth
pass completes the image, writing every other row, starting at the
second row from the top. A graphic description of this process follows:
Image
Row Pass 1 Pass 2 Pass 3 Pass 4 Result
---------------------------------------------------
0 **1a** **1a**
1 **4a** **4a**
2 **3a** **3a**
3 **4b** **4b**
4 **2a** **2a**
5 **4c** **4c**
6 **3b** **3b**
7 **4d** **4d**
8 **1b** **1b**
9 **4e** **4e**
10 **3c** **3c**
11 **4f** **4f**
12 **2b** **2b**
. . .
The image pixel values are processed as a series of color indices
which map into the existing color map. The resulting color value from
the map is what is actually displayed. This series of pixel indices,
the number of which is equal to image-width*image-height pixels, are
passed to the GIF image data stream one value per pixel, compressed and
packaged according to a version of the LZW compression algorithm as
defined in Appendix C.
Graphics Interchange Format (GIF) Page 8
Specification
GIF TERMINATOR
In order to provide a synchronization for the termination of a GIF
image file, a GIF decoder will process the end of GIF mode when the
character 0x3B hex or ';' is found after an image has been processed.
By convention the decoding software will pause and wait for an action
indicating that the user is ready to continue. This may be a carriage
return entered at the keyboard or a mouse click. For interactive
applications this user action must be passed on to the host as a
carriage return character so that the host application can continue.
The decoding software will then typically leave graphics mode and resume
any previous process.
GIF EXTENSION BLOCKS
To provide for orderly extension of the GIF definition, a mechanism
for defining the packaging of extensions within a GIF data stream is
necessary. Specific GIF extensions are to be defined and documented by
CompuServe in order to provide a controlled enhancement path.
GIF Extension Blocks are packaged in a manner similar to that used
by the raster data though not compressed. The basic structure is:
7 6 5 4 3 2 1 0 Byte #
+---------------+
|0 0 1 0 0 0 0 1| 1 '!' - GIF Extension Block Introducer
+---------------+
| function code | 2 Extension function code (0 to 255)
+---------------+ ---+
| byte count | |
+---------------+ |
: : +-- Repeated as many times as necessary
|func data bytes| |
: : |
+---------------+ ---+
. . . . . .
+---------------+
|0 0 0 0 0 0 0 0| zero byte count (terminates block)
+---------------+
A GIF Extension Block may immediately preceed any Image Descriptor
or occur before the GIF Terminator.
All GIF decoders must be able to recognize the existence of GIF
Extension Blocks and read past them if unable to process the function
code. This ensures that older decoders will be able to process extended
GIF image files in the future, though without the additional
functionality.
Graphics Interchange Format (GIF) Page 9
Appendix A - Glossary
GLOSSARY
Pixel - The smallest picture element of a graphics image. This usually
corresponds to a single dot on a graphics screen. Image resolution is
typically given in units of pixels. For example a fairly standard
graphics screen format is one 320 pixels across and 200 pixels high.
Each pixel can appear as one of several colors depending on the
capabilities of the graphics hardware.
Raster - A horizontal row of pixels representing one line of an image. A
typical method of working with images since most hardware is oriented to
work most efficiently in this manner.
LSB - Least Significant Byte. Refers to a convention for two byte numeric
values in which the less significant byte of the value preceeds the more
significant byte. This convention is typical on many microcomputers.
Color Map - The list of definitions of each color used in a GIF image.
These desired colors are converted to available colors through a table
which is derived by assigning an incoming color index (from the image)
to an output color index (of the hardware). While the color map
definitons are specified in a GIF image, the output pixel colors will
vary based on the hardware used and its ability to match the defined
color.
Interlace - The method of displaying a GIF image in which multiple passes
are made, outputting raster lines spaced apart to provide a way of
visualizing the general content of an entire image before all of the
data has been processed.
B Protocol - A CompuServe-developed error-correcting file transfer protocol
available in the public domain and implemented in CompuServe VIDTEX
products. This error checking mechanism will be used in transfers of
GIF images for interactive applications.
LZW - A sophisticated data compression algorithm based on work done by
Lempel-Ziv & Welch which has the feature of very efficient one-pass
encoding and decoding. This allows the image to be decompressed and
displayed at the same time. The original article from which this
technique was adapted is:
Terry A. Welch, "A Technique for High Performance Data
Compression", IEEE Computer, vol 17 no 6 (June 1984)
This basic algorithm is also used in the public domain ARC file
compression utilities. The CompuServe adaptation of LZW for GIF is
described in Appendix C.
Graphics Interchange Format (GIF) Page 10
Appendix B - Interactive Sequences
GIF Sequence Exchanges for an Interactive Environment
The following sequences are defined for use in mediating control
between a GIF sender and GIF receiver over an interactive communications
line. These sequences do not apply to applications that involve
downloading of static GIF files and are not considered part of a GIF
file.
GIF CAPABILITIES ENQUIRY
The GCE sequence is issued from a host and requests an interactive
GIF decoder to return a response message that defines the graphics
parameters for the decoder. This involves returning information about
available screen sizes, number of bits/color supported and the amount of
color detail supported. The escape sequence for the GCE is defined as:
ESC [ > 0 g (g is lower case, spaces inserted for clarity)
(0x1B 0x5B 0x3E 0x30 0x67)
GIF CAPABILITIES RESPONSE
The GIF Capabilities Response message is returned by an interactive
GIF decoder and defines the decoder's display capabilities for all
graphics modes that are supported by the software. Note that this can
also include graphics printers as well as a monitor screen. The general
format of this message is:
#version;protocol{;dev, width, height, color-bits, color-res}... <CR>
'#' - GCR identifier character (Number Sign)
version - GIF format version number; initially '87a'
protocol='0' - No end-to-end protocol supported by decoder
Transfer as direct 8-bit data stream.
protocol='1' - Can use an error correction protocol to transfer GIF data
interactively from the host directly to the display.
dev = '0' - Screen parameter set follows
dev = '1' - Printer parameter set follows
width - Maximum supported display width in pixels
height - Maximum supported display height in pixels
color-bits - Number of bits per pixel supported. The number of
supported colors is therefore 2**color-bits.
color-res - Number of bits per color component supported in the
hardware color palette. If color-res is '0' then no
hardware palette table is available.
Note that all values in the GCR are returned as ASCII decimal
numbers and the message is terminated by a Carriage Return character.
Graphics Interchange Format (GIF) Page 11
Appendix B - Interactive Sequences
The following GCR message describes three standard EGA
configurations with no printer; the GIF data stream can be processed
within an error correcting protocol:
#87a;1 ;0,320,200,4,0 ;0,640,200,2,2 ;0,640,350,4,2<CR>
ENTER GIF GRAPHICS MODE
Two sequences are currently defined to invoke an interactive GIF
decoder into action. The only difference between them is that different
output media are selected. These sequences are:
ESC [ > 1 g Display GIF image on screen
(0x1B 0x5B 0x3E 0x31 0x67)
ESC [ > 2 g Display image directly to an attached graphics printer.
The image may optionally be displayed on the screen as
well.
(0x1B 0x5B 0x3E 0x32 0x67)
Note that the 'g' character terminating each sequence is in lower
case.
INTERACTIVE ENVIRONMENT
The assumed environment for the transmission of GIF image data from
an interactive application is a full 8-bit data stream from host to
micro. All 256 character codes must be transferrable. The establishing
of an 8-bit data path for communications will normally be taken care of
by the host application programs. It is however up to the receiving
communications programs supporting GIF to be able to receive and pass on
all 256 8-bit codes to the GIF decoder software.
Graphics Interchange Format (GIF) Page 12
Appendix C - Image Packaging & Compression
The Raster Data stream that represents the actual output image can
be represented as:
7 6 5 4 3 2 1 0
+---------------+
| code size |
+---------------+ ---+
|blok byte count| |
+---------------+ |
: : +-- Repeated as many times as necessary
| data bytes | |
: : |
+---------------+ ---+
. . . . . .
+---------------+
|0 0 0 0 0 0 0 0| zero byte count (terminates data stream)
+---------------+
The conversion of the image from a series of pixel values to a
transmitted or stored character stream involves several steps. In brief
these steps are:
1. Establish the Code Size - Define the number of bits needed to
represent the actual data.
2. Compress the Data - Compress the series of image pixels to a series
of compression codes.
3. Build a Series of Bytes - Take the set of compression codes and
convert to a string of 8-bit bytes.
4. Package the Bytes - Package sets of bytes into blocks preceeded by
character counts and output.
ESTABLISH CODE SIZE
The first byte of the GIF Raster Data stream is a value indicating
the minimum number of bits required to represent the set of actual pixel
values. Normally this will be the same as the number of color bits.
Because of some algorithmic constraints however, black & white images
which have one color bit must be indicated as having a code size of 2.
This code size value also implies that the compression codes must start
out one bit longer.
COMPRESSION
The LZW algorithm converts a series of data values into a series of
codes which may be raw values or a code designating a series of values.
Using text characters as an analogy, the output code consists of a
character or a code representing a string of characters.
Graphics Interchange Format (GIF) Page 13
Appendix C - Image Packaging & Compression
The LZW algorithm used in GIF matches algorithmically with the
standard LZW algorithm with the following differences:
1. A special Clear code is defined which resets all
compression/decompression parameters and tables to a start-up state.
The value of this code is 2**<code size>. For example if the code
size indicated was 4 (image was 4 bits/pixel) the Clear code value
would be 16 (10000 binary). The Clear code can appear at any point
in the image data stream and therefore requires the LZW algorithm to
process succeeding codes as if a new data stream was starting.
Encoders should output a Clear code as the first code of each image
data stream.
2. An End of Information code is defined that explicitly indicates the
end of the image data stream. LZW processing terminates when this
code is encountered. It must be the last code output by the encoder
for an image. The value of this code is <Clear code>+1.
3. The first available compression code value is <Clear code>+2.
4. The output codes are of variable length, starting at <code size>+1
bits per code, up to 12 bits per code. This defines a maximum code
value of 4095 (hex FFF). Whenever the LZW code value would exceed
the current code length, the code length is increased by one. The
packing/unpacking of these codes must then be altered to reflect the
new code length.
BUILD 8-BIT BYTES
Because the LZW compression used for GIF creates a series of
variable length codes, of between 3 and 12 bits each, these codes must
be reformed into a series of 8-bit bytes that will be the characters
actually stored or transmitted. This provides additional compression of
the image. The codes are formed into a stream of bits as if they were
packed right to left and then picked off 8 bits at a time to be output.
Assuming a character array of 8 bits per character and using 5 bit codes
to be packed, an example layout would be similar to:
byte n byte 5 byte 4 byte 3 byte 2 byte 1
+-.....-----+--------+--------+--------+--------+--------+
| and so on |hhhhhggg|ggfffffe|eeeedddd|dcccccbb|bbbaaaaa|
+-.....-----+--------+--------+--------+--------+--------+
Note that the physical packing arrangement will change as the
number of bits per compression code change but the concept remains the
same.
PACKAGE THE BYTES
Once the bytes have been created, they are grouped into blocks for
output by preceeding each block of 0 to 255 bytes with a character count
byte. A block with a zero byte count terminates the Raster Data stream
for a given image. These blocks are what are actually output for the
Graphics Interchange Format (GIF) Page 14
Appendix C - Image Packaging & Compression
GIF image. This block format has the side effect of allowing a decoding
program the ability to read past the actual image data if necessary by
reading block counts and then skipping over the data.
Graphics Interchange Format (GIF) Page 15
Appendix D - Multiple Image Processing
Since a GIF data stream can contain multiple images, it is
necessary to describe processing and display of such a file. Because
the image descriptor allows for placement of the image within the
logical screen, it is possible to define a sequence of images that may
each be a partial screen, but in total fill the entire screen. The
guidelines for handling the multiple image situation are:
1. There is no pause between images. Each is processed immediately as
seen by the decoder.
2. Each image explicitly overwrites any image already on the screen
inside of its window. The only screen clears are at the beginning
and end of the GIF image process. See discussion on the GIF
terminator.
\BARFOO\
else
echo "will not over write ./docs/gif.doc"
fi
echo "Finished archive 3 of 10"
exit
dan
----------------------------------------------------
O'Reilly && Associates argv@sun.com / argv@ora.com
Opinions expressed reflect those of the author only.
--
dan
----------------------------------------------------
O'Reilly && Associates argv@sun.com / argv@ora.com
Opinions expressed reflect those of the author only.