Resumo

  • Alan R. Katz descreveu em setembro de 1981 um decodificador em funcionamento que convertia dados de fax do Rapicom 450 em bitmap monocromático. Receber o arquivo ainda não era enxergar a página.
  • Bytes armazenados, campos escolhidos do cabeçalho e palavras de comprimento de sequência tinham inversões próprias. Cada bloco fornecia estado e posição para a retomada; a RFC 797 propunha dez bytes de cabeçalho para guardar os pixels de forma simples.

O computador recebeu o fax e ficou com um problema de interpretação. O arquivo existia, os registros tinham tamanho, havia até comando de fim. Só faltava uma coisinha: a página. Alan R. Katz levou essa distância a sério na RFC 798, de setembro de 1981. Ele documentou um programa para transformar a sequência particular de bits do Rapicom 450 num bitmap de um bit por pixel. A RFC 797 descreveu como guardar o resultado para outros programas. A papelada do transporte não dispensava a leitura da letra miúda da máquina.

O programa foi escrito em L10 como subsistema do NLS sobre TOPS20. Um equipamento com microprocessador chamado FAXIE ligava o fax à linha de terminal do computador. Os bits vinham em série e FAXIE montava octetos. Como o Rapicom atribuía a MARK e SPACE valores lógicos opostos aos de RS232, FAXIE complementava cada bit. Ao armazenar os dados no arquivo, o programa invertia a ordem dos bits e complementava os octetos de dados. O decodificador tinha de desfazer essa sequência. Os octetos que traziam comprimento e comando não passavam pela mesma transformação. Era a diferença entre abrir a caixa e virar também a etiqueta de remessa.

Cada bloco do aparelho continha 585 bits. Sete zeros de preenchimento completavam 74 octetos de dados; com comprimento e comando, um registro comum tinha 76 octetos. Havia registros de preparação, de dados e de encerramento. Tudo isso ajudava a preservar a transmissão, como no formato anterior de arquivo Rapicom. Não dizia, por si só, se um ponto da página devia ser preto ou branco.

Na descrição de Katz, uma folha comum tinha cerca de 2.100 linhas de varredura com 1.726 pontos cada. Fine Detail codificava todas. Quality codificava uma a cada duas; Express, uma a cada três. As linhas ausentes seriam repetidas ao exibir a página. O equipamento codificava duas linhas por vez, de modo que cada coluna podia ser branco-branco, branco-preto, preto-branco ou preto-preto. As mudanças entre esses quatro estados usavam códigos de comprimento variável. Trechos uniformes de branco ou preto eram contados por palavras de dois a sete bits. O fluxo não era um pacote de pixels prontos à espera de um monitor paciente.

Havia ainda três maneiras de errar a direção dos bits. Uma dizia respeito ao octeto inteiro guardado no arquivo. Outra aparecia dentro de determinados campos do cabeçalho do bloco: contagem dos bits úteis, posição horizontal e tamanhos das sequências branca e preta eram transmitidos com a ordem interna invertida. Número de sequência e estado atual não eram. As palavras que contavam corridas de cor dentro dos dados também chegavam invertidas, campo a campo. Katz separou expressamente essa operação da inversão e complementação de octetos. Aplicar o mesmo truque a tudo seria econômico no código e caro na imagem.

O cabeçalho servia também de ponto de retomada. Nos 585 bits havia código de sincronização, cabeçalho de 37 bits, área de dados de 512 e verificação CRC. A contagem de dados dizia quantos dos 512 bits eram válidos; zero mandava descartar o bloco. Uma posição horizontal adiante deixava um vão preenchido de branco; uma posição para trás fazia os dados novos substituir a área sobreposta. O número de sequência girava entre 0 e 3, denunciando um bloco perdido. A cada bloco, o programa devia recomeçar com o estado, os tamanhos de sequência e a posição informados naquele cabeçalho, mesmo se o bloco anterior terminasse de outro jeito.

A retomada preservava o resto da página; não inventava o pedaço ausente.

Depois de toda essa engenharia, a RFC 797 era quase uma página em branco. Quatro octetos para largura, quatro para altura, um para incremento horizontal, outro para vertical. Os pixels começavam no décimo primeiro octeto, da esquerda para a direita e do alto para baixo. Cada linha terminava na fronteira de um octeto, com zeros à direita se necessário. Incrementos verticais de um, dois e três correspondiam aos três modos do Rapicom, permitindo repetir linhas na apresentação. Um programa de exibição podia enfim se ocupar de uma imagem, sem aprender os hábitos de um fax específico.

Katz deixou até o custo da operação: aproximadamente dois minutos de CPU num DEC KL10 com TOPS20 para decodificar um documento médio em Fine Detail. O bitmap de cerca de 1.726 por 2.100 pontos ocupava umas 204 páginas de disco. Um terminal gráfico HP mostrava partes da folha e oferecia zoom, pois a página inteira não cabia de uma vez. O fax chegara antes; a imagem só apareceu quando alguém ensinou o computador a lê-lo.