RFC 797

Format for Bitmap files

πŸ“… published September 1981, from ietf

Format for Bitmap Files ✨

okay bestie, this is RFC 797 πŸ“œ from the Network Working Group, written by A. Katz at ISI and dated September 1981 πŸ¦‹. The original doesn't list a category, and it doesn't say it obsoletes or updates anything, so there's nothing more to add up top 🌸. It's a proposed format for storing simple bitmaps, with one bit per pixel πŸ’–.

The whole thing is about how to save a bitmap in a file. These files can get seriously huge 😭, and the goal is short term storage and passing data between programs that are closely coupled πŸ”₯. The data goes in 8-bit bytes (octets), and bitmaps can be any size 🌈.

The first 4 octets tell you the width of each line (the x direction) πŸŽ€. The next 4 octets give the number of lines in the display, which is the length or y direction πŸ’…. After that comes one octet for the x increment and one octet for the y increment ✨. Those 10 octets are the header, and right after them is the bitmap itself 🧚. The length and width fields are stored most significant octet first, so the big end of the number goes in first πŸ‘‘.

The x and y increment octets tell you how much space there is between pixels 🫢. For an ordinary display, both of them are one πŸ’œ.

Each line gets scanned from left to right, and the lines start at the top and work their way down ⭐. Each line has to end on an octet boundary πŸ™ˆ. If the width of the display isn't divisible by 8, the leftover bits in the last octet get filled with zeros on the right πŸ“.

Here's a picture of a bitmap file, where each square is one octet πŸ¦‹:

      ----------------------------------------------------------
      |    1     |    2     |    3     |     4     |     5     |
      |  width   |  width   |  width   |   width   |  length   |
      ----------------------------------------------------------

      ----------------------------------------------------------
      |     6    |     7    |     8    |     9     |     10    |
      |  length  |  length  |  length  |x-increment|y-increment|
      ----------------------------------------------------------

      ----------------------------------------------------------
      |   11     |   12     |   13     |    14     |   15
      |  data    |  data    |  data    |   data    |  data...
      ----------------------------------------------------------

For an example 🌸, bitmaps from the RAPICOM 450 can come in Fine Detail, Quality, or Express Mode πŸ“ . In Fine Detail mode, the x-increment and y-increment are both 1 πŸ’–. In Quality mode, the x-increment is 1 and the y-increment is 2 ✨. In Express mode, the x-increment is 1 and the y-increment is 3 πŸŽ€. For these bitmaps, each scan line is meant to be repeated y-increment times when it gets displayed πŸ”₯. that's the whole vibe, bestie πŸŒˆπŸ’…

πŸ“¦ where this page comes from