[comp.windows.x] Bitmap File format

stuart@cs.rochester.edu (05/07/88)

I have a question about the X11 format of (C-language) bitmap files.

For output bytes that are completely filled, the leftmost input bits
are the most significant output bits.  However, XWriteBitmapFile does
something non-intuitive (to me, at least) for incompletely filled
output bytes, "least significance justifying" the output.  For
consistency, I'd think the data would be "most significance justified."

Which is the correct format for encoding N < 8 bits?
  1) Use the least significant N bits (e.g., N = 3, output = 0x07)
  1) Use the most significant N bits  (e.g., N = 3, output = 0xe0)

I am using X11R2, on a Sun-3/50 running SunOS 3.4, but that should all
be irrelevant, since I'm asking about the defined behavior.

Stu Friedberg  {ames,cmcl2,rutgers}!rochester!stuart  stuart@cs.rochester.edu

oj@apollo.uucp (Ellis Oliver Jones) (05/10/88)

In article <9478@sol.ARPA> stuart@cs.rochester.edu writes:
>I have a question about the X11 format of (C-language) bitmap files.
...
>Which is the correct format for encoding N < 8 bits?

Here's how the source for XCreateBitmapFromData (.../lib/X/XCrBFData.c) defines
the format for the bitmap data (the same stuff as in X11 format 
bitmap files, of course).   I've added annotations.

    ximage.height = height;                number of rows
    ximage.width = width;                  number of columns
    ximage.depth = 1;                      number of bits/pixel
    ximage.xoffset = 0;                    unused pixels at beginnings of rows
    ximage.format = ZPixmap;               "pixel-mode" image, not "plane-mode"
    ximage.data = data;                    pointer to user-furnished data
    ximage.byte_order = LSBFirst;          least significant byte first (footnote*)
    ximage.bitmap_unit = 8;                data is byte organized (footnote*)
    ximage.bitmap_bit_order = LSBFirst;    least significant bit in each byte
                                               is leftmost in Drawable (footnote **)
    ximage.bitmap_pad = 8;                 scanlines are padded to ends of bytes)
    ximage.bytes_per_line = (width+7)/8;   offset from scanline to scanline

Footnote*  Because the data is byte-organized, byte_order makes no difference.  Hooray!
footnote** This means the bits (left-->right) are packed from low-order-->high-order
           in each byte.  When a byte is not filled completely with bits 
           from the bitmap, it is (due to the bitmap_pad setting) filled 
           up with padding.

Image-handling is one of the nicest innovations in X11:  you set up your image, and
declare its characteristics (byte-order, bit-order, packing,...) in the Ximage structure.
The bitmap-file handling calls are layered directly on the image calls.

Then, the procedures behind the XGetPixel and XPutPixel macros pay attention
to the characteristics you declare.  So does XPutImage, which draws
the image in a Drawable.

/Ollie Jones