要約

  • Alan R. Katzが1981年9月に記したプログラムは、Rapicom 450の保存データを白黒ビットマップへ復号した。届いたファイルと読める紙面の間には、まだ機械固有の規則があった。
  • データのバイト、ブロック見出しの一部、連続する白黒の長さは、それぞれ別のビット反転を要した。ブロックごとの状態と位置で復帰し、RFC 797の簡素な画像形式に収めた。

送信は済んだ。ファイルもある。ところが画面に出すと、紙面がどこにあるのかわからない。1981年のRapicom 450では、それで話は終わらなかった。Alan R. KatzのRFC 798が解いたのは通信後の厄介事だ。機械が残したビット列を、別の装置が表示できる白黒の点に戻す。同じ月のRFC 797は、その点を置くための簡潔なファイル形式を提案した。ファクスの到着通知と画像の到着は、別々のイベントだった。

KatzはTOPS20上のNLSで動くL10プログラムを書いた。ファクスとコンピューターの端末回線の間には、FAXIEというマイクロプロセッサー付きの装置が入る。Rapicomはビットを直列に送り、FAXIEは八つずつまとめた。最初の落とし穴は、RapicomのMARKとSPACEがRS232と逆の論理値を持つことだった。FAXIEはビットを反転する。保存用プログラムはさらに、データの各バイト内でビット順を逆にし、値も反転した。復号側はその処理を戻す。ただし長さとコマンドのバイトには適用しない。入口の表札まで裏返したら、どの部屋に入るかもわからなくなる。

機械から来る一ブロックは585ビット。末尾に七つのゼロを足して74バイトのデータとし、長さとコマンドを加えた通常の保存レコードは76バイトになる。設定、データ、終了のコマンドもある。ここまでは、塊を保存して運ぶための整理だ。画像を作るには、Rapicomが白と黒をどう圧縮したかを解かなければならない。

Katzの記述では、普通の紙一枚は約2100本の走査線を持ち、一行に1726個の画素が並ぶ。Fine Detailは全行を符号化し、Qualityは一行おき、Expressは三行に一行を使う。表示時に欠けた行を繰り返す。しかも符号化の単位は上下二行の組で、一列には白白、白黒、黒白、黒黒の四状態がある。状態の遷移は長さが変わるビット列で示し、白だけ、または黒だけの連続部分には二～七ビットの長さ欄を使う。受け取った一ビットをそのまま一画素と思うと、図はあっという間に迷子になる。

「逆に読む」にも種類があった。保存されたデータバイトの反転と、ブロック内部のフィールド単位の反転は違う。見出しにある有効データ数、横位置、白黒の連続長の欄は、欄の中のビット順が逆。連番と現在の状態は逆にしない。画像本体にある連続長の語も、それぞれの欄で逆順だった。Katzは、nビットの欄を裏返す処理とバイト全体を裏返して補数を取る処理を、はっきり分けて説明している。便利な「全部反転」ボタンは、ここでは破壊的な親切だ。

各ブロックの見出しは、途中で崩れた画像を先へ進める手がかりにもなった。585ビットの内訳は同期符号、37ビットの見出し、512ビットのデータ領域、検査値。有効データ数が512ビットのうち読む長さを決め、ゼロならそのブロックを捨てる。横位置が前の終点より先なら空白を白で埋め、手前に戻れば重なったところを新しいデータで置き換える。連番は0から3を巡り、飛べば欠落がわかる。新しいブロックに入るたび、その見出しにある状態、連続長欄の大きさ、横位置から始め直す。前ブロックの終わりと違っていても、新しい見出しを採る。失った線は戻せなくても、その先の解読を続けられる。

出来上がった画素には、RFC 797が実に質素な入れ物を用意した。最初の四バイトで幅、次の四バイトで高さ、その後の二バイトで横と縦の間隔を示す。11バイト目から画像本体。左から右へ、上から下へと並べ、各行の端数は右側にゼロを足してバイト境界で終える。縦の間隔が一、二、三なら、Rapicomの三つの画質モードで省いた行を表示時に繰り返せる。次のプログラムが読むのは機械の癖ではなく、画像の寸法と点だ。

代償も数字で残る。Katzによれば、DEC KL10のTOPS20で平均的なFine Detail文書を復号するのに約二分のCPU時間がかかった。約1726×2100画素の結果は約204ディスクページを使い、HPのグラフィック端末にはページの一部分ずつを拡大して表示した。ファイルの配送は速くても、紙面を人間の目に戻すには、こんなに細かい手順が要った。