Schöner drucken -- /usr/lib/term/taboll

Braucht man am Anfang keinen Plotterschritt, muß man doch als zweites Byte \200
angeben (kein Schritt nach rechts) — sonst gibt’s keine Plot-Schritte.
Getrennt marschieren...
Wie definiert man nun eine möglichst raffinierte Treibertabelle? Man kann dabei
zwei Ziele verfolgen: Falls das Ausgabegerät die nötigen vertikalen und horizontalen
Bewegungen beherrscht, oder falls man fehlende Intelligenz zum Beispiel durch col
oder ähnliche, vorhandene Filter ersetzen kann, wird man wohl versuchen, alles
durch die Treibertabelle zu kontrollieren. Hat man Probleme, schaltet man eher
einen Postprozessor ein und liefert ihm mit der Treibertabelle zu.
Ich selbst neige eher dazu, die Treibertabelle so zu gestalten, daß ein
Postprozessor möglichst leichtes Spiel beim Dekodieren seiner Eingabe, also der
nroff-Ausgabe, hat. Ich kenne nur col als Lösung des Problems, vertikale
Rückwärtsbewegungen mit Hilfe eines ringförmigen Puffers für Zeilen durch
verspätete Vorwärtsbewegungen in Verbindung mit Überdrucken zu ersetzen. Ein
solches Verfahren ist bei allen Druckern nötig, die ich kenne — auch Matrixdrucker
mit perfektem Formulareinzug haben anscheinend Probleme, Papier rückwärts
faltenfrei zu ziehen und anschließend vorwärts wieder exakt die ursprüngliche
Position zu erreichen. col funktioniert aber nicht transparent in bezug auf andere
Zeichenfolgen: nur sehr wenige Steuerzeichen passieren überhaupt die Lesephase
von col (bei System V kann man escape-Sequenzen durchreichen lassen), und zum
Beispiel shift-out und shift-in werden von col möglicherweise verschoben!
Bei horizontalen Bewegungen gibt es außerdem noch ein Effizienzproblem: col
kann zwar für eine Folge von überdruckten Zeichen nur das letze ausgeben (ein Plus
für online Manual-Seiten, die am Terminal betrachtet werden sollen), aber col kann