Also, wie soll der Textformatierer funktionieren? Wir lesen zeichenweise ein
und ignorieren die strenden Steuerzeichen.  In einer Variable Einrckung wird
festgehalten, wie weit der Absatz am Anfang der Zeile eingerckt werden soll. 
Bei rechtsbndigem Satz wird am rechten Rand eingerckt, oder doch lieber am
linken? Am linken wrde man die Einrckung nicht so schn erkennen, da der
Text links sowie so flattert. Es steht ein Eingabepuffer der Lnge einer
Ausgabezeile bereit. In diesen Eingabepuffer wird geschrieben, bis er voll ist
oder ein Absatzende (\n\n, \n\t, EOF, ...) erkannt wurde. Dann mu er nmlcih
erst entleert werden. Beim Einlesen eines \n, das keinen Absatz bricht, ist zu
testen, ob das letzte Wort der oberen Zeile auf .- (Zeichen,Bindestrich)
endet. Ist dies der Fall, dann kann das betreffende Wort wieder
zusammengesetzt werden. Ist der Eingabepuffer voll, dann werde geguckt, ob wir
bereits mehrere Worte auf der Zeile stehen haben. Wenn ein Wort bereits den
ganzen Platz ausfllt, dann mu es mit einer Warnungsmeldung abgeschnitten
werden. Ist es nicht der Fall, wird gesehen, wie weit wir schon in das letzte
Wort eingedrungen sind, denn diese Zahl ergibt die Zahl der Fller im
Blocksatz bzw. die Lnge des Lochs im Flattersatz. Ist die Zahl gro, dann
wird das letzte Wort rckwarts nach einem '-' durchsucht. ungetc() eignet sich
nicht dafr, mehrere Zeichen zurck in den Eingabestrom zu drcken, da es nur
die erfolgreiche Rckgabe eines einzelnen Zeichens garantiert. Findet sich
auch keine Trennmglichkeit, dann ist auch hier gegebenenfalls eine Warnung
auszugeben. Danach wissen wir, welche Worte in die Ausgabezeile formatiert
werden sollen. Es gilt nun nur noch, die entsprechenden Leerzeichen
einzufgen. Das braucht nicht im Puffer zu geschehen, sondern mit einer
Hilfsfunktion ala leer (Einrueckung); puts (Wort [1]); leer (1); und so
weiter. Dazu sollten zwischen den Worten Nullbytes im Eingabepuffer stehen und
eine dynamische Struktur existieren, die die Adresse und Lnge und
Bindestrichvorkommen jedes Wortes vermerkt, hierbei kann ruhig jedesmal
realloc() aufgerufen werden. Ich habe erst berlegt, ob es nicht besser wre,
in grberen Schritten Speicher zu alloziieren, doch genau das tut realloc ja. 
Das einzige Problem, da es ab einer bestimmten Gre schwierig wird, ein
zusammmenhngendes Gebiet anzubieten, ist ja bei diesem kleinen Beispiel, das
nicht einmal die zehnfache Spaltenbreite belegt, kein Problem. Beim Blocksatz
lassen sich / und % wunderbar dazu gebrauchen, die Unregelmigkeiten
gleichmig zu verteilen (abwechselnd vorwrts und rckwrts. Flattersatz ist
eh billig. Das Ergebnis wird in ein Tempfile geschrieben. Dann mu eventuell
noch das halbfertige letzte gelesene Wort an den Anfang des Eingabepuffers
kopiert werden und dann kann dort weiter gelesen werden.  Am Ende eines
Absatzes wird einach geflusht, wenn berhaupt was sinnvolles in der Zeile
steht. Gut, damit ziehen wir ein mal durch den Eingabefile.  Whrenddessen
laufen Zhlvariablen ber die Zahl der eingelesenen Zeichen und Zeilen, damit
bei Warnungen genau angegeben werden kann, wo der Fehler aufgetreten ist, und
bei unzureichendem Platz geantwortet werden kann, zu wieviel Prozent der Text
auf die vorgegebene Seitenzahl passt.  Leere Zeilen am Ende des Textes sollten
ruhig vergessen werden, dann kann man mit tippe auf 0 Seiten testen, ob eine
Datei etwas sinnvolles enthlt.  Auerdem mu natrlich gezhlt werden,
wieviele Zeilen die Druckfahne lang ist, damit man entscheiden kann, ob die
Seitenzahl ausreicht und wo die Spalten auf der letzten Seite enden, das soll
ja mglichst ausgeglichen aussehen. Dann geht der Umbruch in Spalten vor sich,
dazu brauchen wir bei 1-spaltigem Satz keine weitere Zwischendatei. Bei
zweispaltigem Satz knnte man die Zwischendatei noch mal mit einem zweiten
Read/Write-Offset zum Lesen ffnen, und dann gleichzeitig an verschiedenen
Stellen aus ihr lesen, nur hat man dann das Problem, da es schwierig ist, die
Positionen zu berechnen, die per fseek() auf die richtigen Zeilen zeigen. Man
knnte hierzu die Positionen auf dem Heap oder noch einer Datei abgespeichert
haben.  Eigentlich gar nicht so eine schlechte Idee. Die andere Mglichkeit
wre, noch zwei Zwischendateien zu haben und nur einmal durch die Fahne zu
brausen und folgendermaen zu schreiben: 1. von der Fahne nach A, bis die
erste Spalte voll ist, 2. Zeilen zusammenzusetzen, indem man die erste Spalte
aus A liest und dann aus der Fahne eine Zeile anhngt und dann das Ergebnis in
B speichert, sofern dies noch nicht die letzte Spalte War, dann geht es
nmlich ab in die Ausgabe. Wenn die Spalte voll ist, kommt die nchste Spalte
dran, dazu wird die Bedeutung von A und B einfach vertauscht, denn aller Text
aus A ist ja in B gespeichert und A kann als Speichergebraucht werden. Also
noch mal in der bersicht: es gbe die Methode mit einer Fahnendatei, fr jede
Spalte einmal geffnet. Ich schreibe gleich mal ein Programm, das testet, ob
berhaupt gengend viele Dateien gleichzeitig geffnet werden drfen. Abhilfe
wrde hier schaffen, die Datei nur einmal zu ffnen und dann wie wild hin und
her zu seeken, das wird unter Umstnden langsamer, da vielleicht nach jeder
Zeile der gesamte Puffer berschrieben wird. Die Methode mit zwei zustzlichen
Zwischendateien hat den Nachteil, da hier die erste Spalte Spaltenzahl Male
kopiert wird und zwei Seiten zustzlicher Plattenplatz verbraucht werden. Dann
bestnde noch die Mglichkeit, den ganzen Text oder zumindest eine ganze Seite
im Speicher abzulegen. Das ist prinzipiell in Ordnung, da unter SunOS durch
Swapping ja praktisch unbegrenzt Speicherplatz zur Verfgung steht, der, bis
die ersten 16 MB voll sind, auch wesentlich schneller erreichbar ist. Nur
wissen wir leider nicht, wie gro unsere Seiten sind. Es ist grundstzlich
mglich auf 30 Spalten zu tippen, bei einer Spaltenbreite von 255 und 100
Seiten der Lnge 10000 Zeilen. Aber erstens wre der Speicher dadurch
berhaupt schon berfordert und ist das nicht reichlich unrealistisch fr eine
solch kleine Anwendung? Warum gebrauchen dann professionelle Programme wie xrn
Temporrdateien? Andererseits: Wir knnen doch davon ausgehen, da der Text
mit einem Editor erstellt wurde, der den ganzen Text in den Speicher laden
konnte, bzw. da Splittools existieren, die man vorschalten knnte, wenn
tatschlich Speicherprobleme existieren.  Dann stellt sich nachher bei der
Ausgabe die Frage, was tun mit Leerzeilen, die dadurch berflssig werden, da
in ihnen gerade ein Spaltenumbruch fllt. Ich wrde aus sthetischen Grnden
gerne jede Spalte mit Text beginnen lassen, aber aus praktischen Grnden
darauf verzichten, die Spalten bis zum unteren Rand aufzufllen, das heit,
sie unten ein wenig flattern lassen, Das kann jedoch arg ins Auge gehen.
Algorithmen, die dieses Problem befriedigend lsen, erscheinen mir zu schwer,
um sie eben mal zu finden. Und eine interaktive Einstellung ist leichter
vorzustellen, aber auch nicht einfach zu programmieren.  