Résumé

  • Alan R. Katz a décrit en septembre 1981 un programme qui décodait les données du Rapicom 450 en bitmap monochrome. Avoir reçu le fichier ne suffisait pas à voir la page.
  • Les octets de données, certains champs d’en-tête et les longueurs de séquences demandaient des inversions différentes. Les en-têtes de blocs permettaient de retrouver la position après une perte; la RFC 797 proposait ensuite un fichier bitmap à dix octets d’en-tête.

Un fax peut être parfaitement arrivé et rester illisible. C’est même une petite réussite administrative : le fichier est là, bien rangé, mais personne ne reconnaît la feuille. Le Rapicom 450 livrait des blocs et un alphabet de bits qui n’était pas celui d’un écran. Dans sa RFC 798 de septembre 1981, Alan R. Katz raconte le travail concret pour faire sortir une image de ce paquet. La RFC 797, publiée le même mois, décrit le fichier simple qui pouvait recevoir le résultat.

Katz avait écrit le décodeur en L10, comme sous-système de NLS sur TOPS20. Une interface à microprocesseur, FAXIE, reliait le télécopieur au terminal de l’ordinateur. Elle assemblait les bits reçus en octets. Première bizarrerie : le Rapicom attribuait aux signaux MARK et SPACE des valeurs logiques opposées à celles de RS232, si bien que FAXIE complémentait les bits. Avant l’enregistrement, le programme inversait l’ordre des bits et complémentait chaque octet de données selon la convention du fichier Rapicom. À la lecture, le décodeur devait refaire le chemin à l’envers.

Les octets de longueur et de commande, eux, échappaient à cette manœuvre.

Un bloc venu de la machine comptait 585 bits; sept zéros de bourrage en faisaient 74 octets de données. Avec longueur et commande, l’enregistrement courant occupait 76 octets. Les commandes distinguaient la préparation, les données et la fin. C’était une façon de conserver et de déplacer des morceaux cohérents. Pour les transformer en points noirs et blancs, il fallait encore connaître la grammaire du télécopieur.

Une feuille ordinaire avait, selon Katz, environ 2 100 lignes de 1 726 points. Le mode Fine Detail codait toutes les lignes; Quality n’en codait qu’une sur deux et Express une sur trois. À l’affichage, on répétait les lignes absentes. L’encodage prenait deux lignes ensemble : chaque colonne était blanc-blanc, blanc-noir, noir-blanc ou noir-noir. Les passages entre ces quatre états utilisaient des codes de longueur variable. Les longues plages toutes blanches ou toutes noires avaient des compteurs dont la taille passait de deux à sept bits.

Lire le flux comme une suite de pixels isolés revenait à lire une partition de musique comme une liste de clous.

Le piège le plus coûteux tenait au mot « inverser ». L’octet stocké subissait une opération globale. Dans l’en-tête du bloc, le nombre de bits utiles, la position horizontale et la taille des séquences noires et blanches étaient transmis avec leurs bits internes en ordre inverse. Le numéro de séquence et l’état courant ne l’étaient pas. Les mots qui comptaient les séries dans les données de l’image étaient inversés à leur tour, champ par champ. Katz distinguait explicitement cette dernière opération du renversement et de la complémentation des octets du fichier. Un bouton unique « mettre à l’endroit » aurait raté la moitié de la page.

L’en-tête fournissait aussi un point de reprise. Le bloc de 585 bits comprenait un code de synchronisation, un en-tête de 37 bits, 512 bits réservés aux données et un contrôle CRC. Le nombre de bits utiles disait quelle part des 512 bits devait être décodée; zéro ordonnait d’écarter le bloc. Si la position horizontale sautait vers l’avant, le décodeur remplissait le vide de blanc; si elle revenait en arrière, les nouvelles données remplaçaient le chevauchement. Le numéro de séquence tournait de 0 à 3 : un saut signalait un bloc manquant.

À chaque nouveau bloc, le programme repartait de l’état, des tailles de séquence et de la position indiqués dans son propre en-tête. Il pouvait ainsi reprendre après une perte, sans recréer les pixels disparus.

La sortie devenait beaucoup moins capricieuse. La RFC 797 plaçait d’abord quatre octets de largeur, quatre de hauteur, puis un octet pour chacun des pas horizontal et vertical. Les pixels commençaient au onzième octet, de gauche à droite et de haut en bas; chaque ligne finissait à la frontière d’un octet, avec des zéros de bourrage à droite. Un pas vertical de un, deux ou trois correspondait aux trois modes du Rapicom. Un autre programme pouvait répéter les lignes à l’affichage et traiter enfin une image plutôt que mémoriser toutes les habitudes de la machine.

Le programme a laissé une mesure très terrestre de cette victoire. Katz indiquait environ deux minutes de temps processeur sur DEC KL10/TOPS20 pour décoder un document moyen en mode détaillé. Son bitmap d’environ 1 726 par 2 100 points occupait quelque 204 pages disque; un terminal graphique HP n’en affichait que des portions, avec zoom. Le fax était devenu visible, au prix de beaucoup de précision et d’un peu de patience machine.