für den AMIGA

Dokumentation zu Version 2.71

Andreas Scherer Abt-Wolf-Straße 17 96215 Lichtenfels Germany

28. November 1993

Zusammenfassung

Dieser Text beschreibt eine neue Implementierung von in der Version 2.71 für den Commodore Amiga. ist der Name eines Systems zur Zeichensatzerzeugung von Prof. Donald E. Knuth von der Stanford Universität. Es liest Textdateien mit ’Programmen‘, die das Aussehen von Buchstaben, graphischen Symbolen oder anderen Elementen beschreiben, die für die Erstellung von qualitativ hochwertigen Dokumenten benötigt werden. Schriftsatzsysteme wie TEX verwenden die Informationen über die Zeichensatzabmessungen, die von erzeugt werden, und Druckertreiber oder Bildschirmanzeiger verwenden die Pixelinformationen, wohin die ”Tinte“ gesetzt werden soll. Die Verwendung der zugehörigen Programme wird einigermaßen genau beschrieben, es wird aber keine Einführung in die -Sprache selbst gegeben. Genaue Informationen über die Programmierung mit finden sich im Literaturverzeichnis. (Abschnitt 6 dieses Textes.)

Urheberrecht \begin{matrix}c \\ ◯ \end{matrix} 1993 Andreas Scherer Die Anfertigung und Verteilung von unveränderten Kopien der elektronischen Form dieses Dokumentes ist erlaubt, sofern der Urheberrechtshinweis und dieser Berechtigungshinweis bei allen Kopien erhalten bleibt. Die Anfertigung und Verteilung von veränderten Versionen dieses Dokumentes ist erlaubt unter den Bedingungen für unveränderte Kopien, sofern das gesamte hiervon abgeleitete Werk unter den Bedingungen eines mit diesem vergleichbaren Berechtigungshinweises verteilt wird.

Inhaltsverzeichnis

1 Urheberrechtshinweise 3

2 Systemvoraussetzungen 3

3 Kompatibilität 4

4 Installation 4 4.1 Entpacken des Archives . . . . . . . . . . . . . . . . . . . . . . . 4 4.2 Steuerung der Konfigurationsgrößen . . . . . . . . . . . . . . . . 6 4.3 Verwendung der Umgebungsvariablen . . . . . . . . . . . . . . . 9

5 Verwendung der Programme 10 5.1 Erzeugung neuer base-Dateien mit IniMF . . . . . . . . . . . . . 10 5.2 Erzeugung neuer Zeichensatzgrößen mit VirMF . . . . . . . . . . 11 5.3 Umwandlung zwischen den gf- und pk-Formaten . . . . . . . . . 13 5.4 Probedrucke der Zeichensätze mit GFtoDVI . . . . . . . . . . . . 14 5.5 Ausdruck von Zeichensatzprogrammen mit MFT . . . . . . . . . 14 5.6 Analyse von gf- und pk-Dateien . . . . . . . . . . . . . . . . . . 15

6 Empfohlene Lektüre 15

7 Geschichte 16

8 Quelltext 18

1 Urheberrechtshinweise

Das -Programm und die zugehörigen Hilfsprogramme sind urheberrechtlich geschützt für Donald E. Knuth \begin{matrix}c \\ ◯ \end{matrix} 1984. Alle Rechte sind vorbehalten. Der vollständige WEB-Quelltext ist veröffentlicht als [5].

Diese neue Implementierung von 2.71 für den Commodore Amiga ist zu FREEWARE erklärt. Alle Rechte sind vorbehalten. Sie dürfen das Paket verwenden, kopieren und weitergeben, und zwar entweder in archivierter oder installierter Form, aber nicht mehr als eine geringe Bearbeitungsgebühr für Disketten und Versand verlangen.

Obwohl beträchtliche Arbeit investiert wurde, das -Programm fehlerfrei und zuverlässig zu machen, wird keinerlei Gewährleistung übernommen; der Autor und der Implementierer weisen jede Verantwortung für eventuelle Schäden, die sich, direkt oder indirekt, aus der Benutzung oder dem Verhalten dieser Programme ergeben, zurück.

Diese Arbeit war ”Liebesmühe“ und sowohl der Autor als auch der Implementierer hoffen, daß zukünftige Benutzer und Benutzerinnen daran ihre Freude haben.

Bitte senden Sie Anmerkungen, Vorschläge, Fehlermeldungen oder sonstiges an Andreas Scherer, Abt-Wolf-Straße 17, 96215 Lichtenfels, Deutschland. Ein ”Entwicklerpaket“, das den vollständigen Quelltext mitsamt allen Änderungen und Erweiterungen enthält, kann über diese Adresse bezogen werden. (Siehe Abschnitt 8 für nähere Einzelheiten.)

TEX ist ein Warenzeichen der American Mathematical Society. ist ein Warenzeichen von Addison-Wesley Publishing Company. Commodore ist ein eingetragenes Warenzeichen von Commodore Electronics Limited. Amiga, AmigaDOS, Amiga Kickstart und Amiga Workbench sind eingetragene Warenzeichen von Commodore-Amiga Incorporated. SAS und SAS/C sind eingetragene Warenzeichen von SAS Institute Incorporated.

2 Systemvoraussetzungen

Die minimale Rechnerkonfiguration, mit der diese Implementierung von - getestet wurde, war ein Commodore Amiga 2000 mit dem handelsüblichen 68000 Prozessor von Motorola sowie 2 MB ChipRAM und 4 MB FastRAM, obwohl insgesamt nur 1,5 MB RAM mit den Standardeinstellungen tatsächlich benutzt wurden. Der Speicherbedarf kann sich erhöhen in Abhängigkeit vom zu generierenden Zeichensatz und den gewählten Einstellungen in der - Konfiguration. (Siehe Abschnitt 4.2.) Das Betriebssystem bestand aus Kickstart 37.175 und Workbench 38.36. Alle in diesem Paket enthaltenen Programme können unter Version 1.3 des Betriebssystems ablaufen. Nur die Bildschirmanzeige von benötigt Version 2, da sie erweiterte Graphikfunktionen einsetzt. Bei Verwendung der Version 1.3 ist diese Eigenschaft ausgeschaltet.

Es sind gesonderte Versionen der IniMF- und VirMF-Programme vorhanden, die für erweiterte Geräteausstattungen wie den Amiga 3000 oder Amiga 4000 oder Amigas mit Turbokarten gedacht sind. Diese beiden Programme verwenden Eigenschaften des 68020 Motorola Prozessors, die im 68000 Prozessor nicht vorhanden sind. Unter gleichen Bedingungen laufen diese Programmversionen etwa zwanzig bis dreißig Prozent schneller als die nicht-optimierten Versionen, auf Amigas ohne Prozessor mit den 32 Bit-Erweiterungen stürzen sie jedoch ab! Alle anderen Programme in diesem Paket sind so übersetzt, daß sie auf jeder handelsüblichen Amiga-Ausstattung laufen.

ist ein großes System, gedacht für große Aufgaben. Die Erzeugung von cmr10 für den 300 dpi DeskJet-Druckertreiber aus dem PasTEX-Paket benötigt auf einer 50 MHz schnellen 68030-Turbokarte mit mathematischem Koprozessor und ausreichend viel 32 Bit-RAM nur 48 Sekunden, auf einem Standard-Amiga mit 7 MHz und recht langsamem 16 Bit RAM dagegen 10 Minuten und 5 Sekunden, obwohl die Programme auf beiden Konfigurationen laufen.

3 Kompatibilität

Dies ist 2.71 für den Commodore Amiga. Es stimmt völlig überein mit der originalen Implementierung von Donald E. Knuth und hat den TRAP-Test vom 25. Januar 1992 glänzend bestanden. Lediglich in trapman.tex als zulässig gekennzeichnete Abweichungen traten auf. diff-Dateien, die den letzten Lauf des TRAP-Testes dokumentieren, werden auf Anfrage vom Implementierer zugänglich gemacht. (Siehe Abschnitt 8 zu Einzelheiten.)

Weiter enthält dieses Paket die Programme GFtoDVI Version 3.0 (Oktober 1989), GFtoPK Version 2.3 (Juli 1990), GFtype Version 3.0 (April 1989), MFT Version 2 (Oktober 1989), PKtoGF Version 1.0 (Januar 1988) und PKtype Version 2.3 (November 1989).

4 Installation

4.1 Entpacken des Archives

Dieser ” -Anwenderbausatz“ ist in sich vollständig; alles was Sie zur Erzeugung wunderschöner Zeichensätze für TEX benötigen, finden Sie hier. Dieser Abschnitt beschreibt die verschiedenen Unterverzeichnisse und ihren Inhalt. Normalerweise sollte dieses Paket in Form eines LHA-Archives vorliegen, das eine arbeitsfähige Installation aller Programme und Skripten enthält. Lediglich einige Umgebungsvariablen müssen von Hand eingerichtet werden. Leider gibt es kein ’Installer‘-Skript, aber die Installation ist trotzdem sehr einfach. Zuerst müssen Sie die Dateien mit dem Kommando

> LHa x MetaFont[.lha] <Installationspfad oder -Device>

auspacken. (Sie benötigen dazu das LHa-Programm. Sollten Sie es noch nicht haben, holen Sie es sich von der Fish-Diskette 715 mit der aktuellen Version.^{1}) Ein Hauptverzeichnis MetaFont wird angelegt, das das vollständige Archiv in einzelnen Unterverzeichnissen enthält, wie sie im folgenden beschrieben werden. Insgesamt benötigen Sie weniger als 3 MB Platz auf der Festplatte, um das komplette -System zu installieren.

MetaFont:bases: Dieses Verzeichnis enthält die ’base‘-Dateien, die zu Beginn eines Laufes sehr schnell laden kann. Hier finden Sie auch die Datei plain.mf (Version 2.71) und einige Installationsdateien für die Formate ’plain‘ und ’cm‘. Neue base-Dateien sollten in diesem Verzeichnis angelegt werden. Die Umgebungsvariable MFBASES sollte einen Eintrag enthalten, der auf dieses Verzeichnis verweist, damit es finden kann. (Siehe Abschnitt 4.3 zu Einzelheiten über die Umgebungsvariablen, die kennt.)

MetaFont:bin: Der wichtigste Teil dieses Paketes sind die eigentlichen Programmdateien für und die zugehörigen Hilfsprogramme. Sie sollten dem Betriebssystem behilflich sein, und die PATH-Umgebungsvaria-ble um einen Verweis auf dieses Verzeichnis erweitern, damit die Programme aufgerufen werden können. Eine ausführlichere Beschreibung, wie die Programme aufzurufen sind, wird im nächsten Abschnitt 5 gegeben.

MetaFont:config: Die vorliegende Implementierung von ist in der Lage, die Speicherbelegung beim Programmaufruf anzupassen, falls die benutzten Einstellungen zu klein für eine gestellte Aufgabe sind. In solch einem Fall bricht unwiderruflich die Verarbeitung mit der

Fehlermeldung METAFONT capacity exceeded, sorry... ab. Die Konfi-

gurationsdatei mfmemory.config enthält Einträge der Form

   set memmax             65530     % default 30000
   set screenheight         200     % default  1024
   set <internal size> <user value> % default <value>

Sie können die Einstellungen in beschränktem Maße verändern oder einzelne Zeilen aus dieser Datei löschen, so daß dann auf interne Werte zurückgegriffen wird. (Diese sind in der ’default‘-Spalte vermerkt.) Die Umgebungsvariable MFCONFIG sollte einen Eintrag enthalten, der auf dieses Verzeichnis verweist. (Siehe Abschnitt 4.3 zu Einzelheiten bezüglich der von erkannten Umgebungsvariablen und Abschnitt 4.2 zu Einzelheiten über die Speicherkonfiguration.)

1Aber schicken Sie kein Geld an Stefan Boberg, denn es erfolgt keine Lieferung!

MetaFont:doc: Zumindest dieses Verzeichnis kennen Sie schon, da Sie ja diesen Text lesen. Hier finden Sie die Dokumentation zu 2.71 sowohl in deutscher als auch in englischer Sprache. Die LaTEX-Quellendateien müssen vorhanden sein, dagegen können die dvi-Ausgabedateien bei unzureichendem Diskettenplatz gelöscht sein. Diese können Sie mit Hilfe einer lauffähigen TEX-Installation aber neu erzeugen; es werden keine speziellen Makros oder ungewöhnlichen Zeichensätze benötigt.

MetaFont:inputs: Dieses Verzeichnis ist lediglich gedacht für - Programmierer und Systemadministratoren. Es enthält Textdateien, die für die Erzeugung neuer oder veränderter base-Dateien benötigt werden sowie die vollständige Sammlung der Computer Modern Zeichensätze, dem Standard für die meisten TEX-Anwender. Hier können Sie Ihre eigenen Zeichensatzprogramme hinzufügen. wird sie finden, wenn die Umgebungsvariable MFINPUTS einen Eintrag für dieses Verzeichnis enthält. (Siehe Abschnitt 4.3 zu Einzelheiten über die von erkannten Umgebungsvariablen.)

MetaFont:pool: (genau wie TEX) ist ein Pascal-Programm und muß wegen der Einschränkungen dieser Programmiersprache eine eigene Methode zur Verwaltung von Zeichenketten anwenden. Die ’pool‘-Datei mf.pool enthält alle Texte und Meldungen, die auf Ihren Bildschirm oder in die Logdatei ausgeben will. Sie wurde maschinell durch TANGLE bei der Übersetzung erzeugt und sollte nicht gelöscht oder in irgendeiner Weise verändert werden.

MetaFont:rexx: Dieses Verzeichnis enthält das Public Domain Paket ’CallMF‘ (Version 1.0), bestehend aus drei ARexx-Skripten von Georg Heßmann, Martin Bokämper, Jörg Höhle und Ulrich Wisser. Es ist sehr sinnvoll in Zusammenhang mit Heßmann’s PasTEX. Sowohl der Bildschirmanzeiger als auch der Druckertreiber versuchen ’CallMF‘ aufzurufen, falls ein Zeichensatz in einer bestimmten Auflösung nicht vorhanden ist. Die Arexx-Skripten erzeugen den fehlenden Zeichensatz entweder automatisch oder in einem gesonderten Lauf. Die Dokumentation zu ’CallMF‘ [1] finden Sie in einem Unterverzeichnis von rexx, deshalb wird an dieser Stelle nicht näher auf die Installation und Verwendung von ’CallMF‘ eingegangen.

4.2 Steuerung der Konfigurationsgrößen

Ursprünglich handelt es sich bei (und TEX) um ein Pascal-Pro-gramm, das nicht in der Lage ist, seine Speicherkonfiguration zur Laufzeit anzulegen. Um diese zu verändern, müssen Sie normalerweise den Quelltext von mit geänderten internen Vorgabewerten neu übersetzen. Doch mit dieser Implementierung müssen Sie nicht mehr die Meldung ”ask a wizard to enlarge me“ fürchten, sondern können stattdessen selbst ’zaubern‘! Sie wurde nämlich mit Hilfe des Web2C-Sprachwandlers aus der UNIX-Verteilung durchgeführt und somit ist es möglich, die zusätzliche Eigenschaft zur Kontrolle der internen Variablen einzubauen.

verwendet einen gesonderten Suchpfad sowie die Umgebungsvariable MFCONFIG. (Siehe Abschnitt 4.3 zu Einzelheiten über die Benutzung von Umgebungsvariablen.) Die Programme IniMF und VirMF werden in den darin angegebenen Verzeichnissen nach der Datei mfmemory.config suchen, die in einzelnen Zeilen Anweisungen der Form

   set memmax       100000
   set screenheight    400
   set scalefactor       2

enthalten sollte. Die Beispieldatei im config-Verzeichnis ’set‘zt die in meiner gegenwärtigen Standardkonfiguration verwendeten Werte, die etwas höher sind als die internen Vorgabewerte. Nicht alle Einstellungen müssen in dieser Datei angegeben werden. Beachten Sie aber, daß Sie auch nicht alle Einstellungen bis zum Maximum hochdrehen können – dazu müßten Sie über mehr als 8 Gigabyte an freiem Speicher verfügen!^{2}

Wenn Sie eine Standard-base-Datei mit IniMF erzeugen, so ist jede weitere Änderung der Konfiguration mfmemory.config zulässig für VirMF in Verbindung mit dieser speziellen base-Datei, außer Änderungen am Wert memtop. Dies

führt zur  -Meldung ”(Fatal base file error; I'm stymied)“,

was anzeigt, daß diese base-Datei von einem IniMF mit einer anderen Konfiguration stammt.

Hier ist eine vollständige Liste aller Parameter, die in der Konfigurationsdatei zulässig sind, ihre internen Vorgabewerte und einige Regeln für ihre kleinsten und größten Werte:

2Sollten Sie soviel haben, dann glaube ich Ihnen nicht!

Bezeichnung  Vorgabe  Grenzwert Zweck
memmax  30000 maxhalfword Größe des Hauptspeichers
maxinternal  100  ≤ 259774 Anzahl der Internas

bufsize  500 maxhalfword Eingabezeichen

errorline  72 maxhalfword Länge der Fehlerzeile

halferrorline  42 <errline−15 Erste Fehlerzeile

maxprintline  79  ≥ 60 Länge der Ausgabezeile
screenwidth  768  4095 Breite der Bildschirmanzeige
screenheight  1024  4095 Höhe der Bildschirmanzeige
stacksize  30  300 Anzahl der Eingabequellen
maxstrings  2000 maxhalfword Anzahl der Zeichenketten
poolsize  32000 maxhalfword und der enthaltenen Zeichen
movesize  5000  10000 Speicher für Oktantenschritte
maxwiggle  300  1000 Gerundete Punkte pro Kreis
gfbufsize  100  4096 Ausgabepuffergröße
pathsize  300  1000 Knotenzahl in einem Pfad
bistacksize  785  785 Stack für Teilungsalgorithmus
headersize  25  100 Worte in TFM-Köpfen
ligtablesize  5000  32510 Ligaturen/Einrückungen
maxkerns  500  1000 Unterschiedliche Abstände
maxfontdimen  50  100 Anzahl von ’fontdimen‘sionen
memtop  30000  memmax Höchste Speicherstelle
scalefactor  1  10 Anzeige ’SF‘-fach verkleinert
maxinopen  6  20 Anzahl der Ausgabedateien
paramsize  150  1000 Makro-Parameter

Einige dieser Werte werden vor ihrer Verwendung noch mit 4 oder 8 multipliziert, so daß die tatsächlich benötigte Bytezahl für eine spezielle Einstellung nicht so einfach zu bestimmen ist. Solange Sie jedoch keine Probleme mit den Vorgabewerten oder dieser Standardkonfiguration haben, empfehle ich Ihnen, sie so zu lassen. In den meisten Fällen von ungenügender Speichergröße muß nur memmax erhöht werden, und dies wurde tatsächlich bis zum fürchterlich hohen Wert 750.000 ausprobiert, und zwar auf meinem Amiga 2000 mit 8 MB 32 Bit FastRAM.

Sie können die Größe der Bildschirmanzeige durch Veränderung der beiden

Werte screenwidth, screenheight und scalefactor beeinflussen. Die Bedeu-

tung der ersten beiden dürfte klar sein, nur sei angemerkt, daß screenheight den Wert für die interlaced Darstellung bezeichnet, obwohl non-interlaced Bildschirmmodi automatisch erkannt werden und entsprechend nur halb soviele Pixelzeilen angezeigt werden. Außerdem wird durch die beiden Werte nicht die Fenstergröße sondern die zugehörigen Werte innerwidth und innderheight eingestellt. Der scalefactor ist ein Reduktionsfaktor, das heißt die Anzeige wird sowohl in der Höhe als auch in der Breite um diesen Faktor verkleinert dargestellt. Um sinnvoll mit dieser Einstellung arbeiten zu können, enthält die mitgelieferte plain.base die internen Vorgaben

   screen_rows:=4095; screen_cols:=4095; % infinity

wie sie in meiner Druckermodusdatei festgelegt sind. Bei der Bildschirmanzeige verwendet den jeweils kleineren Wert von screenheight und screen rows beziehungsweise screenwidth und screen cols, so daß mit diesen Maximalwerten nur die in der Konfigurationsdatei angegebenen Werte berücksichtigt werden.

4.3 Verwendung der Umgebungsvariablen

kennt und verwendet einige Umgebungsvariablen bei der Suche nach Dateien, für den Aufruf des Systemeditors nach dem ’E‘-Kommando im Fehlerfall und zur Einstellung der Bildschirmanzeige. Die beiden Programme IniMF und VirMF verwenden einen Algorithmus zur rekursiven Suche nach base-Kommandodateien, der Konfigurationsdatei mfmemory.config, den Zeichensatzbeschreibungsprogrammen und der Textdatei mf.pool. Sie können die Umgebungsvariablen entweder mit dem Systemaufruf

    SetEnv <Variable> <Ersetzung>

verändern, um die bei Ihnen gültige Konfiguration zu berücksichtigen, oder Sie können die internen Standardwerte beibehalten. Hier ist eine Liste der vier Suchpfad-Umgebungen, ihrer Vorgabewerte und dessen, was in den jeweiligen Verzeichnissen zu finden hofft.

Umgebungsvariable Vorgabewert Dateien

     MFBASES           ",MF:bases"   *.base Kommandodateien
     MFCONFIG          ",MF:config"  mfmemory.config
     MFINPUTS          ",MF:inputs"  *.mf Programmdateien
     MFPOOL            ",MF:pool"    mf.pool Textverzeichnis

Das Komma in den Vorgabewerten zeigt an, daß das aktuelle Verzeichnis in allen vier Fällen stets zuerst durchsucht wird. Wollen Sie stattdessen zuerst in ’RAM:‘ suchen lassen, so könnten sie den Eintrag "RAM:,,MF:inputs" verwenden und damit das aktuelle Verzeichnis an die zweite Stelle im Suchpfad verweisen. Falls die Umgebungsvariablen nicht durch das ’SetEnv‘-Kommando gesetzt werden, bleiben die internen Standardwerte aktiv und das aktuelle Verzeichnis wird stets zuerst durchsucht. Vielleicht kommt Ihnen dies ja gelegen.

Tritt bei der Verarbeitung ein Fehler auf oder unterbrechen Sie bei seiner Arbeit, so meldet sich mit dem Fragezeichen als Eingabemarke. Geben Sie in solch einem Fall ’e‘ (oder ’E‘) ein, so wird dadurch Ihr Texteditor aufgerufen. Welcher das in Ihrem Fall ist, wird durch die Umgebungsvariable MFEDIT gesteuert, die ein Aufrufmuster enthält, um Ihren bevorzugten Systemeditor in der gerade bearbeiteten Datei an der fehlerhaften Stelle zu positionieren. Dies ist nicht notwendigerweise die Datei, mit der Sie aufgerufen haben. Geben Sie als Wert von MFEDIT einen beliebigen Programmaufruf oder ein beliebiges Skript an, der/das Ihren Editor in der Datei ’%s‘ und der Zeile ’%d‘ positioniert. Die Standardeinstellung lautet folgendermaßen und startet den mit dem Betriebssystem gelieferten Editor MEmacs auf:

   EDITOR "MEmacs goto %d %s"

Im rexx-Verzeichnis finden Sie einige ARexx-Skripten zur Verwendung des Cygnus Ed Professional Editors. Wenn Sie diese verwenden wollen, müssen Sie einfach der Umgebungsvariablen MFEDIT die Zeichenkette

   "rx MF:rexx/MFEdit.rexx %s %d"

zuweisen. Das zweite Skript NameStruc müssen Sie in das REXX:-Verzeichnis kopieren, da es direkt aus MFEdit.rexx aufgerufen wird.

Außerdem gibt es die Möglichkeit, Generierungsläufe am Bildschirm mitzuverfolgen, so wie es im ’ book‘ von Don Knuth [4] beschrieben ist. Da dies aber einige erweiterte Bibliotheksroutinen verwendet, die in älteren Versionen des Betriebssystems nicht vorhanden sind, funktioniert dies nur ab AmigaDOS 2.0 und höher (tut mir leid). Um die Bildschirmanzeige zu aktivieren, müssen Sie die Umgebungsvariable MFWTERM auf den Wert AMITERM setzen. Anschließend wird jeder Lauf für die virtuellen Gerätetreiber proof und smoke seine Ergebnisse auf Ihrem Bildschirm anzeigen.

5 Verwendung der Programme

5.1 Erzeugung neuer base-Dateien mit IniMF

Obwohl Sie eine betriebsfertige plain.base-Datei in diesem Paket finden, kann es sein, daß Sie zusätzliche base-Dateien erzeugen wollen, die andere - -Kommandos als die Standardeinstellung aus dem ’ book‘ [4] enthalten. Zu diesem Zweck gibt es das Programm IniMF, das in der Lage ist, solche neuen binären base-Dateien zu erzeugen, die dann sehr schnell nachgeladen werden können. Wenn Sie IniMF vom CLI (command line input, die Shell) ohne Argumente aufrufen, meldet es sich mit zwei Sternchen, die anzeigen, daß ” begierig darauf ist, Großes zu leisten“ und Sie ”bitte einen Dateinamen eingeben“ sollen.

   > IniMF
   This is METAFONT, C Version 2.71 (INIMF)
   **

Wenn Sie dem hier gegebenen Vorschlag folgen, ist es ganz einfach, den nächsten Schritt zu tun. Beantworten Sie die -Eingabeaufforderung mit dem Namen eines ”Initialisierungsprogrammes“ wie zum Beispiel des mitgelieferten plain.inimf oder cm.inimf und der Rest wird völlig automatisch ausgeführt, so daß schnell eine neue base-Datei plain.base oder cm.base entsteht. Oder Sie geben eine Folge von input-Kommandos ein, um mehrere Dateien in die base einzubinden. Das letzte Kommando sollte dump lauten; dies weist IniMF an, die verdichtete Kommandodatei zu erzeugen und seinen Bearbeitungslauf zu beenden.

Alternativ können Sie auch folgenden Einzeiler eingeben

   > IniMF plain.inimf

was zum gleichen Ergebnis wie oben führt.

5.2 Erzeugung neuer Zeichensatzgrößen mit VirMF

Die Produktionsversion von heißt ’VirMF‘ und unterscheidet sich in einigen Punkten von IniMF. Es ist dazu gedacht, in hoher Geschwindigkeit Zeichensätze zu erzeugen und kann deshalb keine base-Dateien schreiben, diese aber zu Beginn eines Laufes schnell einlesen. Genau wie IniMF können Sie VirMF auf zweierlei Weise aufrufen. Geben Sie lediglich seinen Namen ein (und gesetzt, das Betriebssystem weiß, wo es das Programm zu suchen hat), so meldet sich für einen interaktiven Dialog.

   > VirMF
   This is METAFONT, C Version 2.71
   **

Sie können diese Aufforderung mit jedem gültigen Kommando beantworten und dabei die ’plain‘ base als gegeben voraussetzen, wie sie im ’ book‘ [4] beschrieben wird.

Als leichten Einstieg versuchen Sie doch einfach folgendes. (Zitiert von Seite 31 des ’ book‘ [4]). Geben Sie ’\relax‘ ein—also Rückstrich, r, e, l, a, x—und drücken Sie ⟨return⟩ (oder was auch immer auf Ihrer Tastatur für ”Zeilenende“ steht). ist ganz begierig darauf loszulegen, bereit einen großen Zeichensatz zu erzeugen; Sie aber sagen ihm, es erst einmal ruhig anzugehen, denn dies wird ein ganz vergnüglicher Spaziergang. Der Rückstrich bedeutet, daß nicht eine Datei einlesen soll, sondern direkt Anweisungen von der Tastatur entgegen zu nehmen; der Befehl ’relax‘ bedeutet ”tue nichts“.

Die Maschine wird jetzt mit einem einzelnen Sternchen antworten: ’*‘. Dies bedeutet, daß sie jetzt bereit ist, Befehle (und nicht den Namen einer Datei) entgegen zu nehmen. Nur so zum Spaß geben Sie jetzt folgendes ein:

   drawdot (35,70); showit;

und ⟨return⟩—nicht vergessen, die Strichpunkte mit dem anderen Zeug einzugeben. Ein mehr oder weniger runder Klecks sollte jetzt auf Ihrem Bildschirm erscheinen! Und Sie sollten ein weiteres Sternchen als Eingabeaufforderung sehen. Tippen Sie jetzt

   drawdot (65,70); showit;

und ⟨return⟩, um einen zweiten Klecks zu erhalten. (Im folgenden werden wir die Notwendigkeit, nach jeder Eingabezeile ⟨return⟩ zu drücken, nicht mehr erwähnen.) Zum Abschluß tippen Sie

   draw (20,40)..(50,25)..(80,40); showit;
   shipit; end.

Dies malt eine Kurve durch drei gegebene Punkte, zeigt das Gesamtergebnis an, schreibt es gleichzeitig in eine Ausgabedatei und beendet das Programm. sollte noch mit ’[0]‘ antworten, was soviel bedeutet, daß es einen Buchstaben mit der Nummer Null in dem gerade verarbeiteten ”Zeichensatz“ geschrieben hat; und es sollte Ihnen mitteilen, daß es eine Ausgabedatei mit dem Namen mfput.2602gf erzeugt hat.

Alternativ können Sie auch ein oder mehrere Argumente beim Aufruf von VirMF angeben. Das erste Argument kann der Name einer abweichenden base-Datei sein, was durch ein vorangestelltes &-Zeichen (wie bei &plain) festgelegt wird, und es dürfen mehrere Kommandos in Form einer Zeichenkette folgen, die nach dem Einlesen der base-Datei ausgeführt werden. Zum Beispiel geben Sie folgendes ein, wenn Sie einen Zeichensatz in einer bestimmten Auflösung erzeugen wollen:

   > VirMF &plain "\mode:=previewer; mag:=magstep2; input cmr10"

Sie müssen die Anführungszeichen in dieser Form eingeben, denn die Strichpunkte haben eine besondere Bedeutung für das Betriebssystem des Amiga. Dieses Kommando wird den normalen Textzeichensatz cmr10 passend für den Bildschirmanzeiger der Auflösung 100 dpi in zweifacher Vergrößerung erzeugen, so daß der Zeichensatz die Bezeichnung cmr10.144gf erhalten wird und - folgenden Text auf Ihren Bildschirm (und in die Logdatei) schreiben wird.

   This is METAFONT, C Version 2.71
   (...cmr10.mf (...cmbase.mf) (...roman.mf (...romanu.mf
   [65] [66] [67] [68] [69] [70] [71] [72] [73] [74] [75]
   [76] [77] [78] [79] [80] [81] [82] [83] [84] [85] [86]
   [87] [88] [89] [90]) (...romanl.mf [97] [98] [99] [100]
   [101] [102] [103] [104] [105] [106] [107] [108] [109]
   [110] [111] [112] [113] [114] [115] [116] [117] [118]
   [119] [120] [121] [122]) (...greeku.mf [0] [1] [2] [3]
   [4] [5] [6] [7] [8] [9] [10]) (...romand.mf [48] [49]

   [50] [51] [52] [53] [54] [55] [56] [57]) (...romanp.mf
   [36] [38] [63] [62]) (...romspl.mf [16] [17] [25] [26]
   [27] [28]) (...romspu.mf [29] [30] [31]) (...punct.mf
   [33] [60] [35] [37] [39] [40] [41] [42] [43] [44] [46]
   [47] [58] [59] [61] [64] [91] [93] [96]) (...accent.mf
   [18] [19] [20] [21] [22] [23] [24] [32] [94] [95] [125]
   [126] [127]) (...romlig.mf [11] [12] [13] [14] [15])
   (...comlig.mf [34] [45] [92] [123] [124]) ) )
   Font metrics written on cmr10.tfm.
   Output written on cmr10.144gf (128 characters, 7276 bytes).
   Transcript written on cmr10.log.

Wenn Sie sich schon etwas mit der -Sprache auskennen, wissen Sie sicher, was an dieser Stelle noch möglich ist; falls nicht, rate ich Ihnen, sich das ’ book‘ [4] oder den zweiten Band von Kopka [9] zu kaufen.

5.3 Umwandlung zwischen den gf- und pk-Formaten

(und TEX) ist ein höchst portables Programmiersystem, das es für eine Vielzahl von Rechnern gibt, angefangen bei kleinen Systemen wie dem Amiga bis hin zu echten ”Zahlenfressern“. Auch seine binäre Ausgabe ist unabhängig von einer speziellen technischen Ausstattung. Wie in dem Beispiellauf aus Abschnitt 5.2 gezeigt, erzeugt normalerweise drei verschiedene Ausgabedateien.

Schriftsatzsysteme wie TEX kümmern sich nicht darum, wo am Ende die Tinte hinkommt. Sie wollen lediglich Informationen darüber, wie groß die einzelnen Buchstaben sind und wo in einem bestimmten Zeichensatz sie sich befinden. Diese Informationen werden in ein ’tfm‘-Datei geschrieben (im Beispiel war das cmr10.tfm) und enthalten die ”(TEX) font metric“ Information.

Druckertreiber und Bildschirmanzeiger, die ”device independent files“ verarbeiten, wie sie von TEX oder anderen Programmen erzeugt werden, brauchen dagegen Informationen über das tatsächliche Aussehen der Buchstaben, die sie anzeigen sollen. schreibt diese Pixelinformation für jeden Buchstaben in einem Zeichensatz im sogenannten ”generic font“ Format, das heißt es schreibt eine ’gf‘-Datei (cmr10.144gf in obigem Beispiel). Die Dateiendung bezeichnet dabei die spezifische Auflösung des erzeugten Zeichensatzes in ”Punkten pro Zoll“, so daß Sie zwischen Zeichensätzen für den Bildschirmanzeiger und den Druckertreiber unterscheiden können. Das ”generic font“ Format ist an dieser Stelle sehr gut geeignet und einige Gerätetreiber können es sogar direkt verarbeiten.

In den meisten Fällen aber wird Ihr TEX-System mit etwas ganz anderem arbeiten, der sogenannten ’pk‘-Darstellung der Pixelinformation. ’pk‘-Dateien enthalten die gleiche Information wie die zugehörigen ’gf‘-Dateien, nur ist diese stark komprimiert, so daß ’pk‘-Dateien viel kleiner sind. Die Umwandlung zwischen diesen beiden Formaten der Pixelinformation geschieht mit Hilfe der beiden Programme GFtoPK und PKtoGF. Diese werden folgendermaßen aufgerufen

   > GFtoPK [-v] gffile [pkfile]
   > PKtoGF [-v] pkfile [gffile]

Die ’-v‘-Option sagt den Programmen, etwas wortreicher zu sein, ansonsten würden Sie überhaupt keine Ausgabe am Bildschirm sehen. Das erste Argument bezeichnet die Eingabedatei (dabei ist die Endung wichtig) im jeweiligen Ausgangsformat. Das optionale zweite Argument bezeichnet die Ausgabedatei im jeweils anderen Format. Geben Sie dieses zweite Argument nicht an, so wird die Endung der Eingabedatei auf standardisierte Weise in die Endung der Ausgabedatei umgewandelt. Der Aufruf

   > GFtoPK cmr10.144gf

wird cmr10.144gf nach cmr10.144pk umwandeln. Sie können für das zweite Argument einen vollständigen Pfadnamen eingeben, so daß dann die Ausgabedatei gleich in das richtige Verzeichnis gestellt wird.

5.4 Probedrucke der Zeichensätze mit GFtoDVI

Diese Installation von kennt zwei spezielle Modi genannt ’proof‘ und ’smoke‘, die zwei virtuellen Gerätetreibern entsprechen mit einer Auflösung von 2602 dpi. Das Programm GFtoDVI kann formatierte Ausdrucke dieser Zeichensätze erzeugen. Geben Sie einfach ein

   > GFtoDVI

und GFtoDVI wird Sie nach einem gf-Dateinamen fragen. Sie können einige interne Einstellungen für diesen Lauf ändern, indem Sie einen Schrägstrich an den Dateinamen anhängen. Dann wird Sie GFtoDVI zur Ersetzung spezieller Zeichensätze auffordern, das heißt zur Einstellung eines geräteabhängigen ’gray‘ oder ’black‘ Zeichensatzes. (Siehe hierzu das ’ book‘ [4].) Wie die meisten anderen Programme, kann auch GFtoDVI Aufrufargumente direkt aus der Kommandozeile übernehmen, so daß Sie auch einfach

   > GFtoDVI cmr10.2602gf/

eingeben können und anschließend weitere Eingaben angefordert werden.

5.5 Ausdruck von Zeichensatzprogrammen mit MFT

Eine andere Besonderheit dieser Implementierung ist das Programm MFT, das gewöhnliche Programmquellen in TEX Eingabedateien umwandelt, um sie anschließend formatiert ausdrucken zu können. Das einzige Aufrufargument ist der Name einer ’mf‘-Datei, die Teile eines -Programmes enthält. Sie können die Arbeitsweise von MFT beeinflussen durch die Angabe eines anderen Formates als plain.mft. Es macht sicher Spaß, mit anderen Einstellungen herumzuspielen.

   > MFT file[.mf] [-cs] [change[.ch]] [style[.mft]]

5.6 Analyse von gf- und pk-Dateien

Die beiden letzten Programme in dieser Verteilung dienen zu Testzwecken. Sie liefern genaue Informationen über den Inhalt der Pixeldateien im ’generischen‘ und im ’komprimierten‘ Format in Textform.

   > GFtype [-m] [-i] gffile
   > PKtype pkfile

Die beiden Optionen für GFtype bedeuten ”Mnemonische Ausgabe“ und ” pIxel Ausgabe“. Ihre Angabe wird weitere Informationen zur Textausgabe hinzufügen, besonders die Darstellung der einzelnen Buchstaben in der Form von ASCII ’Bildern‘ für die eingehende Kontrolle dessen, was produziert.

6 Empfohlene Lektüre

Hier ist eine kurze Liste mit Büchern zu und seinen Kollegen. Sie sollten diese Bücher zu Rate ziehen, wenn Sie eingehende Informationen über die Programmierung mit der -Sprache suchen. Außerdem finden Sie darin interessante Sachen über die Geschichte von TEX und seit 1978, Schriftsatz mit Computern im allgemeinen sowie über das literarische Programmieren, das bei der Entwicklung von ”Computers & Typesetting“ verwendet wurde.

Literatur

[1] Georg Heßmann u. a., ARexx Unterstützung für , Dokumentation zur Version 1.0, Beschreibung des ’CallMF‘-Paketes von Georg Heßmann, Martin Bokämper, Jörg Höhle und Ulrich Wisser zur Verwendung mit dem PasTEX-System, enthalten in dieser Amiga-Implementation.

[2] Donald E. Knuth, Computers & Typesetting A: The TEXbook, Addison-Wesley Publishing Company, 19. Auflage, Juni 1990. Das Referenzhandbuch für alle Benutzer des TEX-Systems. Es beschreibt die TEX-Sprache auf vielschichtige Weise.

[3] Donald E. Knuth, Computers & Typesetting B: TEX: The Program, Addison-Wesley Publishing Company, 4. Auflage, Februar 1991. Dieser 600 Seiten starke Schmöker enthält den ausführlich dokumentierten Quelltext für das TEX-Programm, geschrieben in WEB.

[4] Donald E. Knuth, Computers & Typesetting C: The book, Addison-Wesley Publishing Company, 4. Auflage, Juni 1990. Das Referenzhandbuch für alle Benutzer des -Systems. Es beschreibt die -Sprache auf vielschichtige Weise.

[5] Donald E. Knuth, Computers & Typesetting D: : The Program, Addison-Wesley Publishing Company, 4. Auflage, Februar 1992. Dieser 566 Seiten starke Schmöker enthält den ausführlich dokumentierten Quelltext für das -Programm, geschrieben in WEB.

[6] Donald E. Knuth, Computers & Typesetting E: Computer Modern Typefaces, Addison-Wesley Publishing Company, 1. Auflage, Mai 1986. Dieses Buch enthält Beispiele für alle Buchstaben und Zeichen der Computer Modern Zeichensatzfamilie, die eng verbunden ist mit dem Erscheinungsbild aller TEXnischen Schriftstücke.

[7] Donald E. Knuth, Literate Programming, Center for the Study of Language and Information, 1. Auflage, 1992. Dies ist eine Zusammenstellung von Knuthschen Texten im Zusamenhang mit dem ”literarischen Programmieren“, wie es in höchster Vollendung bei den TEX- und - Programmen angewandt wurde. Außerdem enthält es eine Liste aller Fehler von TEX 82 (bis einschließlich den 20. September 1991).

[8] Helmut Kopka, LaTEX–Eine Einführung, Addison-Wesley Publishing Company, 4. Auflage, 1992. Dies ist der erste von zwei Bänden für deutschsprachige LaTEX-Benutzer. Offenbar ist es beliebter als das Referenzhandbuch von Leslie Lamport.

[9] Helmut Kopka, LaTEX–Erweiterungsmöglichkeiten mit einer Einführung in , Addison-Wesley Publishing Company, 3. Auflage, 1992. Dies ist der zweite Band für deutschsprachige LaTEX-Benutzer. Er enthält eine Einführung in die Programmierung mit und das literarische Programmieren mit WEB und CWEB.

7 Geschichte

Diese Amiga-Umsetzung von 2.71 basiert zum großen Teil auf dem kompletten TEX- und -System von Edmund Mergl, wie es auf den Fish-Disketten 611–616 veröffentlicht wurde. Ausgehend von 2.7 aus dieser Implementierung, habe ich viele Änderungen und Erweiterungen vorgenommen.

Der größte Unterschied zwischen der Version von Edmund Mergl und meiner eigenen ist, daß nun für sich allein stehend konzipiert ist, mit völlig selbständigem Quelltext und Hilfsmitteln. (Siehe Abschnitt 8.)

Von Beginn an habe ich auf dem Amiga mit dem SAS/C-Entwicklungssystem gearbeitet. Die neueste Version 6.3 dieses großartigen Compilers ist völlig kompatibel mit dem ANSI-Standard und hat eine ganze Reihe von Auslassungen bezüglich Stil und Sprache bei dem Versuch festgestellt, den Quelltext neu zu übersetzen. Eine große Aufräumaktion für die Zusatzquellen in C, insbesondere die Einführung der vollständigen Prototypen und die Korrektur einiger fehlender Casts, war deshalb notwendig.

Sobald die selbsterzeugte Version 2.7 sauber lief, wurde sie mit der bekannten Amiga-Umsetzung von Stefan Becker von der Fish-Diskette 486 verglichen und erwies sich als derart langsamer, daß Verbesserungen notwendig waren, um mit diesem System zu wetteifern. Der kritische Kern der ”inneren Schleife“ von wurde in Assembler für den Motorola 68020 umgeschrieben. Dies ergab eine Beschleunigung des Laufzeitverhaltens um etwa zwanzig bis dreißig Prozent im Vergleich zur nichtoptimierten Version und um etwa fünf bis acht Prozent im Vergleich zur optimierten Version von Stefan Becker.

Der glänzend bestandene TRAP-Test bewies die Korrektheit der gemachten Änderungen dieser Implementierung, so daß der schwierigere Teil schnell erledigt war. Die Testroutine von Don Knuth war tatsächlich geeignet, den letzten bösen Fehler meiner eigenen Umsetzung zu finden (der ausgerechnet etwas mit der Variablen ’be_careful‘ zu tun hatte). Jedoch zeigte der Augenschein, daß sowohl mein eigenes als auch das von Stefan Becker Probleme mit der Bildschirmanzeige hatten. Weder die Implementierung von Stefan Becker noch die von Edmund Mergl arbeiteten so, wie im ’ book‘ [4] beschrieben. Besonders die Testroutine 6test.mf für die Computer Modern Zeichensätze machte dies deutlich. (Ein Beispiel für diesen Test findet man auf Seite 192 von [4].) Mit einer geänderten Version von amiga.c, die gleichzeitig einige fortgeschrittene Funktionen für die Ausgabe verwendet und deshalb auch die Version 2 des Amiga Betriebssystems benötigt, lief es besser.

Unter Anwendung einiger Ideen von David Crooke aus seiner Amiga-Umset-zung von TEX 3.141, baute ich eine geänderte Pfadsuche sowie die Möglichkeit der Speicherkonfiguration in ein. (Siehe Abschnitt 4.2 zu Einzelheiten darüber.)

Im September 1993 wurde dann der erste Schritt in Richtung Version 2.71 getan mit Hilfe der Fehlerbeschreibungen des Addison-Wesley-Verlages. Alle Änderungen, die die neue Version betrafen, wurden in die Change-Datei eingebaut.

Schließlich erhielt ich im Oktober 1993 die offizielle Version 2.71^{3}, die das alte System vollständig ersetzt. Sie enthält ein neues plain.mf base-Programm und einen völlig neuen TRAP-Test. Die letzte große Änderung dieser Implementation war die Bereitstellung einer wirklich GROSSEN Version von (und von TEX 3.1415), indem max quarterword auf 32.767 (32 Kilo Viertelworte) und max halfword auf 1.073.741.823 (1 Giga Halbworte) erweitert wurde, so daß nun wirklich niemand mehr an die maximal mögliche Einstellung stoßen wird (Sie bräuchten schon mehr als 8 Giga Byte freien Speicher!). Dabei scheint jeder zu glauben, daß ’262.142‘ als maximaler Wert von memmax festgelegt sei, nur weil es so in [3] und [5] angegeben ist. Dieser Wert gilt jedoch nur für 36 Bit Worte. Die vorliegende C-Implementation arbeitet aber auf der Basis von ”64 Bit Worten“, das heißt ein Halbwort ist als long int definiert, so daß die viel größeren Werte verwendet werden können.

3vom Stuttgarter ftp-Server ftp.uni-stuttgart.de (129.69.8.13)

8 Quelltext

Bei diesem Paket handelt es sich um den ” Benutzerbausatz“, der keinerlei Quelltext für die eigentlichen Programme enthält (es gibt aber ein ganzes Verzeichnis für die Computer Modern Zeichensatzbibliothek, doch das ist eine andere Art von Quelltext). Auf Anfrage ist beim Implementierer ein ”Entwicklerbausatz“ erhältlich. Wenn Sie den haben wollen, brauchen Sie nur einen Rückumschlag mit 10 Deutschen Mark (oder 10 US Dollar) an die Adresse zu schicken, die auf der ersten Seite dieser Dokumentation angegeben ist, und Sie werden die neueste Version mit allen notwendigen Hilfsmitteln für die Neuübersetzung und alle zukünftigen Fehlerbeseitigungen auf Diskette erhalten.