The file parser builds the scan line data as a continuous stream of bits that define each pixel. Each pixel is packed into an array of bytes in such a way that if the data were written out in hexadecimal or binary numbers, the pixels could be read in order from left to right. That is, for a 4-bit-per-pixel format, the first pixel is stored in the high-order bits of the first byte (bit 7, bit 6, bit 5, and bit 4), and the second pixel is stored in low-order bits of that byte (bit 3, bit 2, bit 1, and bit 0). Thus, if the first eight pixels of a 4-bit-per-pixel scan line have the hex values of 0, 2, C, 9, A, 4, 3, and F, the first four bytes of scan line data would be 02, C9, A4, and 3F.
If the parser provides a palette for the image, the data for each pixel is interpreted as an index into the palette. If no palette exists for the image, the bits for each pixel specify either a true color (24-bit only) or a gray scale value. For 24-bit color, each 3 bytes of a scan line represent the intensities of red, green, and blue of a single pixel.
When the scan line has been completely specified, the parser must call SOPutBreak with the SO_SCANLINEBREAK value, except for the last line of the bitmap. The last line of the bitmap must end with a break of the SO_SECTIONBREAK or SO_EOFBREAK type, whichever applies.
The following example illustrates the use of the bitmapped functions in the simplest possible case: a parser with scan line data stored one tile wide and with the same format that parsers are required to provide it, so the data requires no additional processing after being read in. This example also does not check for EOF or read errors.
WORD wBytesRead;
WORD wBufSize = Proc.ScanLineBufSize;
do
{
...
xread( hFile, Proc.ScanLineBuf, wBufSize, &wBytesRead );
SOPutScanLineData( Proc.ScanLineBuf, hProc );
...
} while( SOPutBreak( SO_SCANLINEBREAK, 0, hProc ) == SO_CONTINUE );