Christian Griesbeck

  • Schrift vergrößern
  • Standard-Schriftgröße
  • Schriftgröße verkleinern
Start Software Die Calamus Story

Die Calamus Story

Nachdem ich 1985 vom alten 8-Bit Atari auf die ST Reihe umgestiegen war, entwickelte ich zunächst das unveröffentlichte Typographieprogramm „C.A.T.“, das ähnlich wie heute noch das TeX System funktionierte, was aber meine Ansprüche an Benutzerfreundlichkeit nicht erreichen konnte. Ich konnte Dietmar Meyfeld von der neu gegründeten DMC GmbH Walluf überzeugen, das Projekt eines DTP-Programms (der Begriff schwappte damals brandheiß vom Mac herüber, ebenso wie WYSIWYG) grundlegend neu zu starten. Meine Aufgaben waren dabei: Das User-Interface Design und die technische Projektleitung - insbesondere der Entwicklung aller notwendigen Techniken, Algorithmen und Datenformate. Hinzu kam die Programmierung von Systemroutinen, für die ich keine geeigneten Programmier finden konnte – bzw. die ich anderen nicht in einem überschaubaren Zeitrahmen so erklären konnte wie sie funktionieren sollten, so dass ich sie besser selber programmierte.

Heute würde man die Calamus Entwicklungsstrategie wohl mit „agil“ beschreiben – Redesign war eines der Zauberwörter, denn das Projekt hat mehrere Häutungen erfahren. In einem Interview in der ST World June 1989 beschrieb das einmal Michel Jung (der damalige Produktmanager) so: „There are six full-time staff at DMC, which was founded by Dietmar Meyfeldt at the beginning of 1987, plus 20 freelancers attached to the company. Interestingly, Mike considers the company to have a philosophical leader in Christian Griesbeck, a man who he credits with having a great creative and guiding influence on the team. There were no less than 12 names in the Calamus credit list and DMC also employ student programmers all over Germany, each of whom has been working on an aspect of the Calamus program.”

Rückblickend ist es immer noch ein Wunder und Wahnsinn, dass Calamus unter den damaligen Umständen überhaupt entstanden ist. Heute würde eine so kleine Firma so etwas einfach nicht mehr wagen, man bräuchte auf dem Stand der Technik vielleicht 20 Vollzeitprogrammierer für zwei Jahre dazu, um ein vergleichbar komplexes Projekt zu heben. Calamus entstand in Wirklichkeit mit einem angestellten Vollzeitprogrammierer und im Kern einer handvoll Schüler und Studenten, die das Projekt mit ihrem guten Willen und auf Versprechungen hin mit ihrer Arbeit vorfinanzierten. Genau hier war aber auch gleichzeitig eine Wurzel von Streit und Niedergang gesetzt. Die Unterfinanzierung, enttäuschte Erwartungen, ideologische Enge und die Angst zu groß zu werden, haben Calamus im entscheidenden Moment gestoppt.

Die Entwicklung des DTP-Programms Calamus ist eine Geschichte mit Spannung, Intrige, Sex und Kriminalität; eine Geschichte um viel Geld, das verdient wurde, und viel Geld das verloren wurde; eine Geschichte um enttäuschte Erwartungen, um gebrochene Versprechungen und sogar Betrug. Das meiste hiervon, geneigter Leser, werde ich aber weglassen oder nur andeuten, das ist Stoff für einen Roman oder eine Seifenoper im Fernsehen und nicht für eine Webseite. Denn Calamus ist auch für viele eine Erfolgsgeschichte und eine schöne Erinnerung an ein geniales Produkt – und wie dies entstand, möchte ich hier der Vergessenheit entreißen und davon berichten.

Christian Griesbeck, im Mai 2010

Version 0.01

 

Der Anfang war ein Henne-Ei-Problem – um meinen Entwurf zu vermitteln, musste ich die vielen Icons und deren Funktion beschreiben. Wie beschreibt man ein DTP-System? Am besten in einem DTP-System, das gab es aber nicht. Also löste ich es mit der Kombination von Bildern und Text, die ich in einem Graphikprogramm zusammenstellte. Dabei entwickelte ich die Bedienstruktur, die später viele Atari ST Programme prägen sollte. Oben waren die normalen Drop Down Menüs. Auf der freien Fläche rechts daneben sollten, wie schon beim meinem Programm PICASO zuvor, künftig beim Überfahren von Icons erklärende Hilfstexte auftauchen. Eine horizontale Reihe von Icons stellte die verschiedenen grundlegenden Bearbeitungsmodi dar (Rahmeneditor, Texteditor etc.) – die später bei Calamus SL „Module“ heißen würden. Daneben dann Icons fürs Zoomen, für das Blättern durch die Seiten, eine Anzeige eines Tastaturshortcuts und die Koordinaten des Cursors auf der Seite. Wichtigster Bestandteil war aber die große Menupalette auf der linken Seite. Oben einige Reiter (die manchmal aus Platzmangel noch zweigeteilt waren), darunter jede Menge Icons. Die Fläche war systematisch aufgeteilt – oben auf weißer Fläche die Icons für die Objekte, also z.B. Textrahmen, Graphikrahmen etc. und unten eingerahmt die Icons für die Funktionen, also z.B. Einfügen, Verschieben, Nach vorne etc. – dies sollte dem Nutzer, trotz der Menge an Funktionen, einen schnellen optischen Zugriff gewähren.

Nun kam der erste festangestellte Programmierer von DMC zum Einsatz: Harald Siegmund. Er hatte sich zuvor mit einem tollen Spiel für die 8-Bit Atari Computer „Gärtner“ eingeführt und wurde von Dietmar eingestellt. Später sollte er für Calamus „kriegswichtig“ werden, denn er fügte die vielen Einzelteile zusammen und trug die Hauptlast der Entwicklung. Aber zunächst war seine Aufgabe erst einmal nur, das User Interface in der Sprache C zum Laufen zu bringen. In der ersten Demoversion bestand die Arbeitsfläche noch aus einem Dummybild, einzig die Elemente der Benutzeroberfläche ließen sich anklicken und vorführen. Während Harald das User Interface für eine Messe zum Laufen brachte, kümmerte ich mich um die Schriften.

Fonteditor

Als erstes entwickelte ich das Zeichnsatzformat von Calamus und einen neuen Zeichensatzeditor, diesmal einen Vektorzeichensatzeditor. Editierbare Vektorgraphik kannte ich bereits vom „Pinball Construction Set“. „GEM-Draw“ - das Referenzgraphikprogramm auf dem Atari ST damals – war hingegen sehr rudimentär und konnte kaum als Vorbild dienen.
 
Im Zeichensatz sollten man neben Linien auch Kurven verwenden können – denn deren Fehlen war ein klares Manko von einem PC Programm, das ich mir zuvor noch im Rahmen von C.A.T. angeschaut hatte und das simple Vektorschriften demonstrierte. Ich entschied mich für die einfach zu berechnenden Bezierkurven mit zwei Kontrollpunkten, die auch bei Postscript Verwendung fanden. Und noch eine zweite Anleihe machte ich bei Postscript – die „Windingnumber-Polygone“, bei denen die Drehrichtung bei Überlappungen entscheidet, ob eine Fläche weiß oder schwarz wird.

Für das Kerning (eine Funktion, bei denen sich Buchstaben überlappen können, um ein besseres ästhetisches Bild zu erzeugen) wählte ich dann allerdings schon einen anderen Weg als Postscript, das nur einige ausgewählte Paare definierte. Bereits C.A.T. untersuchte die Buchstabenkanten, um automatisch Unterschneidungen erzeugen zu können, für Calamus modifizierte ich diese Idee. Die Buchstaben wurden auf beiden Seiten in je 8 vertikale Segmente aufgeteilt, für die jeweils definiert wurde, wie weit ein anderer Buchstabe dort heranrücken durfte. Das Minimum aus den acht Segmenten für das Heranrücken wurde gebildet, und schon hatte man ein einfaches automatisches Kerning.

Die Editiermöglichkeiten im Fonteditor blieben sehr rudimentär – Anwählen und Verschieben, Ein- und Anfügen sowie Löschen von Punkten und Pfaden. Wenige Funktionen erleichterten die Arbeit, wie das Ändern der Drehrichtung, ein Verrunden, ein Gitter, Hilfslinien und ein Clipboard. Die maximale Auflösung, die man durch Zoomen erreichen konnte, waren 1024x1024 – ein Sechzehntel der eigentlichen Auflösung, die professionellen Schriften vorbehalten bleiben sollte. Ein Highlight war vielleicht schon der Taschenrechner, in dem man mittels Formeln die Zeichen (oder Teile davon) umrechnen konnte (z.B. für Kursivschrift). Der Fonteditor war, wie zuvor C.A.T., im Wesentlichen in Pascal programmiert. Um bestehende Zeichensätze über eine Screengrab-Funktion einfacher digitalisieren zu können, hatte ich ihn als Accessory programmiert.

Die zeitkritischen Funktionen für das Rendern von Buchstaben aus der Vektorbeschreibung in eine Rastergraphik schrieb ich in Assembler. Das war eine recht komplexe Aufgabe, denn zunächst wurde die Beschreibung aus „Move“, „Line“, „Curve“ und „End“ in Polygone aus geraden Linien umgesetzt, diese vertikal aufgespaltet und sortiert, und das dann wiederum für die Ausgabe zeilenweise abgehangelt und mit horizontalen Linien ausgegeben. Als I-Tüpfelchen war das Ganze nur mit trickreicher Integerarithmetik aufgebaut, denn das war das Schnellste, was der 68000 hergab. Diese Routine wurde auch eine erste Basis für die Textausgabe in Calamus. Dort war das aber insgesamt noch einmal alles wesentlich komplizierter, denn die Ausgabe musste noch schneller, sowie verschiedenen Schriftarten und Formatierungen berücksichtigt werden.

Die Vektorschriften waren ein Hauptmerkmal, in dem Calamus allen anderen DTP Programmen für Jahre voraus sein würde. Während wir an Calamus arbeiteten, scheiterte Adobe daran, Display Postscript auf dem Markt zu etablieren. WYSIWYG war auf dem Mac lange Zeit eine billige grobpixelige Vorschau – ein halber Blindflug. In Calamus sah man hingegen wirklich alles auf dem Bildschirm, was man bekam – denn Drucker, Satzbelichter wie auch die Bildschirmausgabe verwendeten exakt die gleichen Routinen und Zeichensätze. Man konnte bequem auf jede Druckerauflösung und noch weiter zoomen, ohne dass ein Vektorelement wie die Schrift pixelig werden konnte. Um den ehemaligen Page Autor Matthias Schrader zu zitieren: „Während man auf dem Pagemaker noch Headlines in Klötzchenoptik sah (Adobe rückte erst vier Jahre später den ATM raus), konnte man mit Calamus Ende 1986 bereits auf dem Bildschirm 1:1 in der Belichterauflösung von 2540 dpi arbeiten. Es haute uns schier aus den Socken. Adobe und Steven Jobs griffen das Konzept wenig später unter dem Begriff Display Postscript auf – kriegten es aber unter NextStep nie performant.“ (http://www.fischmarkt.de/2006/05/schuelerzeitung_goes_dtp.html)

Das Kind bekommt einen Namen

Den Namen und das erste Logo des Produktes hatte ich bald gefunden „Calamus“ ein Schilfrohr, das man früher zum Schreiben verwendete. Zunächst gab es leichte Zweifel, ob Calamus und Kalamitäten nicht zu nah beieinander liegen. Dann gab es Probleme mit dem Schutz des Namens – das Patentamt sagte, dass es nicht möglich ist den Namen zu schützen – Calamus ist der Name einer Pflanze und daher als Wort nicht schützbar! So wurde von Alfred Smeets (der später auch einige Schriftarten für Calamus entwerfen würde) ein neues Logo gestaltet – das mit der bekannten Calamus Feder – und nur als Bild-/Wortmarke eingetragen. Etwa ein Jahr später hatte Linotype die besseren Patenanwälte. Sie sorgten dafür, dass ihnen das Patentamt für den Namen einer neuen Schriftart die (zuvor DMC verweigerten) Schutzrechte an der Wortmarke gleich für alle möglichen Bereiche einräumte. Die Rechte mussten dann teuer von DMC gekauft werden – für weit mehr Geld als für manche wichtige Systemkomponente. Glück im Unglück – Linotype hatte Interesse daran, mit DMC ins Geschäft zu kommen, um Schriften zu verkaufen – sonst hätte wohl noch teurer ein neuer Name etabliert werden müssen.

Memory Management

Ein wichtiger Bestandteil, den Calamus benötigte, aber das Atari Betriebsystem „TOS“ nicht hergab, war ein effektiver Memory Manager. Damit wurde ein weiterer Teil des Calamus Teams beauftragt, das ihn eigenständig entwickelte. Klaus Garms und Pierre Hansen waren der Kern der „Darmstädter Gruppe“, sie hatten schon zuvor zusammengearbeitet und einen Treiber für die Atari Laserdrucker entwickelt, der auf ihnen einen Epson FX80 simulierte. Das Problem war, dass eine A4 Seite mit 300 DPI ein MB an Speicher brauchte, mehr als viele Ataris überhaupt an Hauptspeicher hatten. Also bereitete der trickreiche Treiber während des laufenden Druckvorgangs die Seite On-the-fly häppchenweise just in time auf. Auch dieses Programm wurde dann von DMC vertrieben.

An den Memory Manager wurden auch einige On-the-fly Anforderungen gestellt, und er wuchs mit diesen Anforderungen. Ein Calamus Dokument bestand aus vielen einzelnen Objekten, die jeweils in einem linearen Speicherbereich abgelegt sein wollten, sowie temporärem Speicher, der für vielerlei Funktionen benötigt wurde. Dabei konnten die Objekte ihre Größe verändern, gelöscht werden oder mehr werden. Das wurde durch ein Handle System gelöst, so konnten die Objekte im Speicher verschoben werden, falls Speicher freigegeben wurde, um wieder große zusammenhängende Bereiche zu schaffen. Ein Handle konnte aber auch geblockt werden, um ein Verschieben eines Speicherbereichs zu verhindern, den man im Moment benötigte. Später konnte sogar die Festplatte als virtueller Speicher verwendet werden.

Dokumentenformat

Wie sieht ein Calamus Dokument intern aus? Wie sind die einzelnen Objekte aufgebaut? Wie ist das Textformat etc. ? – das sind Fragen, die ich zu beantworten hatte. Dabei konnte ich zum Teil auf die Erfahrungen mit meinem Vorprojekt C.A.T. zurückgreifen, entschied mich aber beim Text zu einem platzsparenderen Binärformat.

Für Harald schälte sich so langsam heraus, dass er wohl mehr als die Programmierung des Userinterface machen musste, denn seine nächste Aufgabe war ein Rahmeneditor, und man konnte im Calamus zum ersten Mal etwas richtiges machen. Zunächst wurden zu Demozwecken noch die GEM Funktionen zum Zeichnen von Linien und Flächen verwendet, aber es war klar, dass diese für die Zukunft nicht geeignet und mächtig genug sein würden.

Vektorgrafikausgabe

Da ich bereits eine Ausgaberoutine für die Vektorzeichen geschrieben hatte machte ich diese über ein Bitmuster graustufenfähig. Die größere Herausforderung war allerdings das Zeichnen von dicken Linien. Sicher, man konnte wie GEM mit einer Pinselfunktion an den Linien entlangzeichnen, aber das war langsam und führte zu mäßigen Ergebnissen. Mein Vorbild war die mächtige Linienfunktion von Postscript, dort konnte man neben der Breite bestimmen, ob und wie die Linien gestrichelt sein sollten, ob Ecken spitz, rund oder flach sein sollten und wie die Enden aussehen sollten. Um das zu realisieren gab es nur einen sinnvollen Weg, man musste die Außenkante (Outline) der entsprechende Linie als Vektorgraphik errechnen – also quasi entlang eines Linienzuges nach beiden Seiten Boxen bauen. Dank der Windingnumber Polygone musste ich mich zumindest nicht um Selbstüberlappungen kümmern, und die modifizierte Ausgaberoutine für Vektorzeichen konnte die errechneten Linienpolygone ausgeben. Das alles erforderte einiges an Trigonometrie und das Lösen von Gleichungen in Assembler. Keine sehr spaßige Aufgabe, aber ich schaffte es. Ich glaube nicht, das jemand jemals verstanden hat, wie die Routine arbeitet. Beim Übertragen auf den PC wurde dann der Maschinencode blind in C übersetzt und er funktionierte.

Rasterbildausgabe

Da ich es zeitlich kaum schaffen würde, alle Ausgaberoutinen selber in Assembler zu programmieren, übte ich mich endlich im Delegieren und übertrug die Routine für das skalierte Ausgeben von Rasterbildern Jochen Mickel. Sein Vater arbeitete sogar bei Motorola, so dass der 68000 fast in der Familie lag. Ich erklärte ihm, was wir brauchten und wie eine integer Version (Bresenham) eines Digital Differential Analyzers funktioniert – mit zwei davon (einen für jede Achse) konnte man meiner Meinung nach einfach und schnell Bilder skalieren. Wir brauchten eine Ausgaberoutine für Schwarzweissbilder und eine für Graustufenbilder, dabei experimentierten wir neben einem Punktraster auch mit Rastern durch eine Floyd–Steinberg Fehlerverteilung. Alles weitere überließ ich Jochen, der sich mit Harald koordinierte, um die Routinen in Calamus zu integrieren. In späteren Versionen von Calamus wurden die Routinen aber nochmals durch neu programmierte ersetzt.

Textausgabe

Der härteste Brocken in Calamus war mit Sicherheit die Textausgabe, die im Laufe der Zeit mehrere Häutungen über sich ergehen lassen musste, um besser und performanter zu werden. Sie ist sicherlich das größte Wunderwerk in Calamus, das Harald implementierte. Wie das mit dem Kerning funktionieren soll, war leicht erklärt und eine einfache Textausgaberoutine bald programmiert. Es wurde schnell klar, dass man bei der Textausgabe zuschauen kann, falls es bei einer reinen Vektorausgabe bleiben würde – die rettende Idee kam hier von Klaus, der meinte, dass man in der Informatik durch das Speichern und Wiederverwenden von Zwischenergebnissen (Caching) Dinge beschleunigen kann. Auch Postscript verwendete zum schnelleren Ausgeben von Zeichen einen Cache, der aber für einen kompletten Zeichnsatz aufgebaut wurde und so bei nicht verwendeten Zeichen unnötig Zeit und Speicherplatz schluckte.

In Calamus wurde Caching künftig ein Zaubermittel. Wurde ein Zeichen zum ersten Mal in einer bestimmten Schriftart, einem bestimmten Stil und einer bestimmten Größe benötigt, wurde es zunächst im Cache abgelegt und daraus dann, mit einer schnellen Bitmap Kopierfunktion, auf den Schirm gebracht. Dabei musste allerdings immer der beschränkte Speicher des Atari berücksichtigt werden, also ggf. länger nicht mehr verwendete Dinge auch wieder aus dem Cache verschwinden und auch entschieden werden, ob es nicht jeweils sinnvoller ist, das Zeichen doch direkt, mittels der Vektorausgabe, auf den Schirm zu bringen.

Nicht nur die Zeichen landeten in einem Cache, sondern auch Informationen zum Umbruch und zur Position jedes einzelnen Zeichens innerhalb einer Zeile. Dazu wurde die Position normalisiert, um unabhängig vom Zoomfaktor zu werden – das löste zudem ein gängiges Problem, das andere Programme hatten, die den Textsatz in der geringen Bildschirmauflösung berechneten und der dann mit der hohen Auflösung des Druckers völlig anders aussah. Calamus ließ das kalt und wurde so das erste DTP Programm mit wirklichem WYSIWYG.

To be continued..