Der klassische Weg, in \TeX-Dokumente Bilder einzubinden, ist die Verwendung des
{\em special\/}-Kommandos. Dieses wird nicht von \TeX\ selbst, sondern
ausschlie"slich vom DVI-Treiber abgearbeitet. Ich selbst habe in den vergangenen
Jahren einige DVI-Treiber f"ur verschiedene Drucker geschrieben, um Grafiken
benutzen zu k"onnen. Nach meinem Daf"urhalten kranken aber alle L"osungen, die sich
auf eine {\em special\/}-L"osung abst"utzen, in zweierlei Hinsicht.
Wie sein Name schon andeutet, ist die Bedeutung des {\em special\/}-Kommando in
keiner Weise festgelegt. Jeder Treiber, der ein solches Kommando implementiert,
kann sowohl Syntax als auch Semantik selbst festlegen. Hiervon wird von den
Entwicklern der DVI-Treiber ungehemmt Gebrauch gemacht. Auch die momentanen
Normierungsbestrebungen werden an dieser Situation kaum etwas "andern. Jeder so
entwickelte Vorschlag hat n"amlich nicht den bindenden Charakter eines
\TeX-Kom\-man\-dos, sondern ist als Empfehlung zu verstehen, die man befolgen,
aber auch verwerfen kann. Die einzige allgemein anerkannte Autorit"at in der
\TeX-Gemeinde, die hier etwas "andern k"onnte, ist Donald Knuth selbst. W"urde er
\TeX\ mit Gra\-fik\-ele\-men\-ten versehen, so w"are die Frage der
Implementierung jeder Diskussion entzogen. Ich pers"onlich w"urde mir eine solche
Erweiterung w"unschen.
Der zweite Gesichtspunkt, der die Verwendung des {\em special\/}-Kommandos
unhandlich macht, ist seine Nichtbeachtung durch \TeX. \TeX\ hat keine
Vorstellungen "uber die Abmessungen einer Grafik, die durch einen solchen Befehl
in ein Dokument aufgenommen wird. F"ur den Benutzer bedeutet dies, da"s er das
Bild in eine Schale (z.B. {\em picture\/}-Umgebung) einbetten mu"s, um \TeX\
indirekt die M"oglichkeit zu geben, das grafische Element zu ber"ucksichtigen.
Dieses Verfahren schafft neue Fehlerquellen und zus"atzlichen Pf"|legeaufwand. So
k"onnen z.B. die Abmessungen eines Bildes falsch eingesch"atzt werden, und auf
eine "Anderung der Grafik mu"s mit einer "Anderung der Parameter f"ur die Schale aus
\TeX-Kommandos reagiert werden.
Beide Hindernisse haben mich schon vor einiger Zeit dazu veranla"st, L"osungen mit
dem {\em special\/}-Kommando nicht weiter zu verfolgen. Ich habe f"ur meine
Belange stattdessen einen anderen Weg realisiert. Ausgangspunkt war die
Feststellung, da"s \TeX\ standardgem"a"s mit "`Grafiken"' umzugehen wei"s, n"amlich
mit den Zeichen seiner Zeichens"atze. Aus diesem Blickwinkel betrachtet, h"alt
\TeX\ f"ur jede dieser "`Grafiken"' ein Rechteck auf der Seite frei, in das
dann der Dvi-Treiber das "`Bild"' des Zeichens hineinmalt. Die Zeichen werden
dabei f"ur Pixel-orientierte Drucker als Bitmap vorgehalten, f"ur
PostScript-f"ahige Drucker z.B. auch als das Aussehen beschreibende Algorithmen.
Ich habe mich bei meinen Entwicklungen auf Pixel-orientierte Drucker beschr"ankt.
Damit reduziert sich die Aufgabe, Bilder f"ur \TeX\ aufzubereiten auf die
Umwandlung von Grafik-File-Formaten in eines der von \TeX\ unterst"utzten
Zeichensatzformate \PXL\ oder {\sf PK}. Der Standardweg, solche Zeichens"atze
zu erzeugen, f"uhrt "uber \METAFONT\ und {\sf GFtoPX}. L"osungen, die hier
ansetzen und z.B. HPGL-Files in {\em mf\/}-Files umsetzen, sind bereits als
kommerzielle Produkte verf"ugbar. Allerdings liegen viele Grafiken nicht in
Vektor-Form (wie HPGL) vor, sondern als Pixel-Files. Insbesondere "uber einen
Scanner gewonnene Bilder werden fast immer in einem \PCX-, {\sf TIFF}- oder
{\sf GIF}-File abgelegt. Ich habe deshalb dem direkten Weg zur Erzeugung der
Zeichens"atze den Vorzug gegeben. Das unten vorgestellt Programm \RUMgraph\
wandelt \ADI- und \PCX-Grafik-Files in \TeX-\PXL-Files um. Die
Implementierung des \ADI-Formats ist als Abdeckung meines pers"onlichen
Bedarfs zu sehen: ich benutze bevorzugt {\sf AutoCAD} zur Erzeugung meiner
Bilder. Die gr"o"sere Bedeutung kommt aber sicherlich dem weit verbreiteten
\PCX-Format der Firma ZSoft zu. Auf die Implementierung anderer Grafikformate
habe ich verzichtet, da es sowohl im kommerziellen als auch im
Public-Domain-Bereich Programme gibt, die nahezu jedes Grafikformat -- sowohl
Pixel- als auch Vektor-orientiert -- nach \PCX\ umwandeln. Ich selbst habe
bereits erfolgreich {\sf GIF-, MSP-, TIFF-, HPGL-, PCL-, EPS-, WPG-, IGES- und
DXF-}Formate verwendet.
\section{Aufgabe des Programms}
\markboth{Aufgabe des Programms}
{Aufgabe des Programms}
Das Programm \RUMgraph\ wandelt Pixel-Bilder im \ADI- oder \PCX-Format in
\TeX-PXL-Zeichens"atze um. F"ur jeden Buchstaben des neu zu schaffenden
Zeichensatzes wird dabei ein eigener Grafik-File verwendet.
Eingabe f"ur das Programm sind dementsprechend neben einer Reihe von Angaben, die
den Zeichensatz beschreiben, ein oder mehrere Grafik-Files f"ur die
Buchstaben. Als Ergebnis wird ein \PXL-File mit zugeh"origem \TFM-File erzeugt.
Au"serdem wird ein sogenannter {\em Log-File\/} geschrieben, der ausf"uhrliche
Information "uber den jeweiligen Programmlauf enth"alt. Auf Anforderung hin kann
ein \TeX-Input-File bereitgestellt werden, der den Zugriff auf den Zeichensatz
und seine Zeichen erleichtert.
Es werden zwei Pixel-orientierte Grafikformate unterst"utzt:
das \ADI-Format der Firma AutoDesk und das \PCX-Format der Firma ZSoft.
Das Programm ist ablauf"|f"ahig auf IBM-kompatiblen Rechnern. Es l"auft unter den
Betriebssystemen {\sf MS-DOS} und {\sf OS/2}.
\section[Der Aufruf von \RUMgraph\ ]{Der Aufruf von \RUMo{\sf graph}}
\markboth{Der Aufruf von \RUMgraph}
{Der Aufruf von \RUMgraph}
Das Programm \RUMgraph\ wird in der "ublichen Weise durch eine Eingabe der
folgenden
Form aufgerufen:
{\sf \hspace*{.5in} RUMgraf\ \ option\ \ ...}
Die Optionen beginnen dabei mit den Zeichen / oder --. Unmittelbar danach folgt
ein einzelner Buchstabe: die Optionskennung. Welche Buchstaben zul"assig sind und
welche Bedeutung sie haben, wird weiter unten erl"autert. Gro"s- und
Kleinbuchstaben werden {\it nicht} unterschieden. An die Optionskennung schlie"st
sich der Wert der Option an. Zwischen Optionskennung und Wert kann als Trenner
eines der Zeichen : oder = eingeschoben werden. Leerzeichen sind als Trenner
nicht zul"assig. Enth"alt der Wert der Option ein Leerzeichen, so ist er in
Hochkommata\ ''\ einzuschlie"sen. Alle Angaben, die nicht mit / oder -- beginnen,
werden als Kommentar betrachtet und dementsprechend ignoriert.
Die Optionen gliedern sich in drei Gruppen:
\begin{itemize}
\item Die erste Gruppe spezifiziert die Parameter, die f"ur den gesamten
Zeichensatz gelten (z.B. Auf"|l"osung). Sie k"onnen sinnvollerweise nur
einmal angegeben werden. Erfolgt eine mehrfache Angabe, so hat nur der
letzte Wert G"ultigkeit.
\item Die zweite Gruppe beschreibt die einzelnen Zeichen (z.B.
metrische Angaben). Eine einem Zeichen zugeordnete Gruppe von Optionen
wird eingeleitet durch die c-Option (character number), die ein
bestimmtes Zeichen festlegt. Alle Angaben bis zur n"achsten c-Option
werden diesem Zeichen zugeordnet. Bei Mehrfachangaben beh"alt wieder nur
die letzte Angabe einer Gruppe ihre G"ultigkeit.
\item Die dritte Gruppe enth"alt nur eine einzelne Option, und zwar die m-Option.
"Uber sie wird der Name eines sogenannten {\em makefiles\/} angegeben. In ihm
k"onnen beliebige Optionen abgelegt sein. Die Angabe einer m-Option bewirkt, da"s
die in dem {\em makefile\/} enthaltenen Optionsangaben in die Reihe der Optionen
der Kommandozeile eingeschoben und abgearbeitet werden. Alle Optionen k"onnen in
einem {\em makefile\/} verwendet werden; insbesondere auch Kommentare.
\end{itemize}
\subsection*{Optionen der Gruppe 1: Angaben zum Zeichensatz}
\marginlabel{\bf /P} {\sf /P:}{\em Picture\/}
Mit der p-Option wird eine Kennung f"ur das zu erzeugende Bild
festgelegt. Sie wird benutzt f"ur:
\begin{itemize}
\item den Namen des \PXL-Files ({\sf ident.PXL}),
\item den Namen des TFM-Files ({\sf ident.TFM}),
\item den Namen des \TeX-Input-Files ({\sf ident.TEX}) und
\item den Namen des Log-Files ({\sf ident.RGL}).
\end{itemize}
Die Kennung mu"s aus 1 - 8 Buchstaben bestehen.
Beispiel: {\sf /P:SINGA}
\vspace*{.1in}
\marginlabel{\bf /R} {\sf /R:}{\em Resolution\/}
Die r-Option gibt die verwendete Auf"|l"osung der Bitmap an.
Ma"seinheit: dpi (= dot per inch)
Beispiel: {\sf /R:300}
\subsection*{Optionen der Gruppe 2: Angaben zu den einzelnen Zeichen}
\marginlabel{\bf /C} {\sf /C:}{\em Character\/}
Mit der c-Option wird der Beginn eines Parametersatzes f"ur das angegebene
Zeichen festgelegt. Alle Optionen der Gruppe 2 werden bis zur n"achsten c-Option
auf dieses Zeichen bezogen. Als Wert kann entweder ein Buchstabe oder eine Zahl
von 0 bis 127 angegeben werden.
Beispiele: {\sf /C:A} oder {\sf /C:65}
\vspace*{.1in}
\marginlabel{\bf /N} {\sf /N:}{\em Name\/}
Jedem Buchstaben kann "uber die n-Option ein Name zugeordnet werden. Der Name
dient zur Generierung eines \TeX-Kommandos im \TeX-Input-File. Wird der
Input-File benutzt, so kann der Buchstabe -- und somit auch das Bild -- durch
Angabe dieses Kommandos in das Dokument eingef"ugt werden. Fehlt die n-Option, so
wird f"ur diesen Buchstaben kein Kommando erzeugt. Wird f"ur keinen der Buchstaben
ein Name angegeben, so wird die Erzeugung des \TeX-Input-Files g"anzlich
unterdr"uckt. Ein Name kann aus einer beliebigen Anzahl von Buchstaben
zusammengestzt sein.
Beispiel: {\sf /N:Aleph}
\vspace*{.1in}
\marginlabel{\bf /T} {\sf /T:}{\em Type\/}
Die t-Option bezeichnet das Format des zu dem Buchstaben geh"orenden
Grafik-Files. Als Werte k"onnen die Kennungen \ADI\ und \PCX\ angegeben
werden. F"ur jeden Buchstaben kann ein anderer File-Typ angegeben werden.
Beispiel: {\sf /T:PCX}
\vspace*{.1in}
\marginlabel{\bf /F} {\sf /F:}{\em Filename\/}
"Uber die f-Option wird der Name des Grafik-Files angegeben, der f"ur die
Erzeugung der Bitmap des Zeichens verwendet werden soll. Es kann ein beliebiger
Pfadname angegeben werden.
Die metrischen Angaben f"ur den \TFM-File werden "uber die d-Option ({\em depth\/}),
h-Option ({\em height\/}) und w-Option ({\em width\/}) spezifiziert. Die Bedeutung
dieser und der anderen metrischen Werte wird weiter unten erl"autert. Fehlen die
Optionen, so wird {\em width\/} gleich der Breite {\em x size\/} der Bitmap, {\em
height} gleich der H"ohe {\em y size\/} der Bitmap und {\em depth\/} gleich Null
gesetzt. Alle Angaben sind in Pica-Punkten {\em pt\/} zu machen.
"Uber die x-Option ({\em x offset\/}) und die y-Option ({\em y offset\/}) k"onnen die
metrischen Angaben f"ur den \PXL-File festgelegt werden.
Die Gr"o"sen {\em x size\/} und {\em y size\/} entnimmt \RUMgraph\ direkt dem
"uber die f-Option bestimmten Grafik-File. Fehlen die Angaben, so wird {\em x
offset\/} gleich 0 und {\em y offset\/} gleich {\em y size\/} gesetzt.
Ma"seinheit: pixel
Beispiel: {\sf /X:--5 /Y:22}
\vspace*{.1in}
\marginlabel{\bf /S} {\sf /S:}{\em Splitcount\/}
Werden Bilder in Buchstaben umgewandelt, so entstehen h"aufig "au"serst gro"se
Buchstaben. Eine Zeichnung, die eine ganze DIN A4-Seite einnimmt ist keine
Besonderheit. Viele Treiber (und auch viele {\sf PXTOPK}-Implementierungen)
k"onnen so gro"se Zeichen nicht handhaben. Deshalb besteht "uber die s-Option die
M"oglichkeit, das Bild in mehrere Teilbilder in Form von vertikalen Streifen zu
zerschneiden. Diese Streifen werden dann einzeln in Buchstaben umgewandelt und
unbelegten Codes des Zeichensatzes zugewiesen. Die metrischen Angaben im \TFM-
und \PXL-File werden dabei so angepa"st, da"s alle Buchstaben, wenn sie
unmittelbar
aufeinander folgen, wieder das Gesamtbild ergeben.
Ma"seinheit: Bytes
Beispiel: {\sf /S:20}
\vspace*{.1in}
\marginlabel{\bf /I} {\sf /I}
Mit Hilfe der i-Option kann ein Bild invertiert werden.
Beispiel: {\sf /I}
\vspace*{.1in}
\marginlabel{\bf Anmerkung} Die Standardwerte der metrischen Angaben sind so
gew"ahlt, da"s sowohl aus der Sicht von \TeX\ als auch aus der des DVI-Treibers
der Referenzpunkt des Zeichens stets in der linken unteren Ecke liegt und da"s um
die Bitmap herum keinerlei Rand bleibt. Wird \RUMgraph\ zur Einbindung von
Bildern
in ein Dokument genutzt, so ist diese Setzung naheliegend.
\subsection*{Optionen der Gruppe 3: Umlenken der Eingabe auf einen {\em
makefile\/}}
\marginlabel{\bf /M} {\sf /M:}{\em Makefile\/}
"Uber die m-Option kann \RUMgraph\ angewiesen werden, seine Optionen aus einer
Datei zu lesen. Insbesondere wenn ein zu erzeugender Zeichensatz mehrere
Buchstaben umfa"st, ist die Einf"uhrung eines {\em makefiles\/} unumg"anglich. Die
Anzahl der Optionen, die in der Kommandozeile m"oglich sind, ist eben deutlich
beschr"ankt. Ein {\em makefile\/} kann alle Optionen enthalten. Wird allerdings in
einem {\em makefile\/} eine m-option angegeben, so werden alle folgenden Optionen
ignoriert. Ein {\em makefile\/} kann deshalb innerhalb eines {\em makefiles\/}
sinnvoll nur mit der letzten Option angegeben werden.
Beispiel: {\sf /M:Singa}
\section{Die Verwaltung von Zeichens"atzen durch \TeX}
\markboth{Die Verwaltung von Zeichens"atzen durch \TeX}
{Die Verwaltung von Zeichens"atzen durch \TeX}
Ein Zeichensatz, wie er von \TeX\ verwendet wird, enth"alt grunds"atzlich zwei
Arten von Angaben:
\begin{itemize}
\item metrische Angaben wie Breite und H"ohe der Zeichen und
\item die grafische Beschreibung des Zeichens selbst -- meistens wie bei \PXL-
und PK-Files in Form einer Bitmap.
\end{itemize}
Die Angaben f"ur jeden Zeichensatz sind auf zwei Dateien verteilt: den \TFM-File
und den \PXL-File. Die Angaben in beiden Files sind teilweise redundant. Etwas
vereinfacht kann man aber sagen, da"s der \TFM-File metrische Angaben enth"alt,
die
den Platz beschreiben, der f"ur das Zeichen auf der Seite reserviert werden soll,
und da"s der \PXL-File die Bitmap beinhaltet, die zur eigentlichen Darstellung
des
Zeichens benutzt wird. Entsprechend dieser Aufteilung werden bei der Erstellung
eines Dokuments mit \TeX\ die Angaben eines Zeichensatzes von unterschiedlichen
Programmen ausgewertet.
{\small
\input{la}
}
Das eigentliche \TeX-Programm benutzt nur die metrischen Angaben aus dem
TFM-File. Aus der Sicht von \TeX\ sind Buchstaben einfach Rechtecke. Zur
Positionierung dieser Rechtecke wird eine fiktive {\em Schreiblinie\/} und auf
dieser ein fiktiver {\em Schreibpunkt\/} verwaltet. Die Buchstabenrechtecke
werden auf dieser Schreiblinie so positioniert, da"s zum einen ihr linker Rand
durch den Schreibpunkt hindurch geht und da"s sie zum anderen eine vorgegebene
H"ohe ({\em height\/}) "uber der Linie und eine vorgegebene Tiefe ({\em depth\/})
unter der Linie hinaus ragen. Die Schreibstelle wird von \TeX\ nach der
Positionierung des Zeichens um die Breite {\em width\/} des Zeichens verschoben.
Man kann auch sagen, da"s die Angaben von {\em height\/} und {\em depth\/} auf dem
linken Rand des Zeichens einen {\em Referenzpunkt\/} festlegen, der von \TeX\ mit
dem Schreibpunkt zur Deckung gebracht wird. \TeX\ ber"ucksichtigt in keiner
Weise das durch die Bitmap festgelegte grafische Ausssehen eines Zeichens. Es
h"alt nur den Platz f"ur diese Bitmap frei. Das {\em Ausmalen\/} dieses Platzes ist
Aufgabe des DVI-Treibers.
Ein DVI-Treiber "ubertr"agt also die im \PXL-File (oder auch {sf PK}-File)
enthaltene Bitmap auf die Seite. Dabei werden auch von ihm metrische Angaben,
die sich aber auf die Abmessungen der Bitmap beziehen, ausgewertet. Konkret
sind dies vier Werte. Zum einen existieren auch hier Angaben zur H"ohe ({\em y
size\/}) und Breite ({\em x size\/}) eines jeden Zeichens. Sie spiegeln
das engste
Rechteck wieder, das um die Bitmap gezogen werden kann. Zum anderen wird mit
einem horizontalen ({\em x offset\/}) und vertikalen ({\em y offset\/}) Versatz
ebenfalls ein Referenzpunkt definiert. Da beide Offset-Angaben auch negativ
sein k"onnen, kann der Referenzpunkt beliebig au"serhalb der Bitmap liegen. Ein
DVI-Treiber verwaltet -- wie das \TeX-Progamm selbst -- Schreiblinie und
Schreibpunkt und positioniert Zeichen, indem Schreibpunkt und Referenzpunkt der
Bitmap zur Deckung gebracht werden. Bei Verschiebung der Schreibstelle wird
allerdings der gleiche Wert f"ur die Breite des Zeichens verwendet wie vom
\TeX-Programm.
Prinzipiell sind die Angaben im \TFM- und \PXL-File unabh"angig voneinander. In
der
Praxis werden die Angaben aber nat"urlich aufeinander abgestimmt verwendet. Der
von \TeX\ reservierte Platz ist meistens so gew"ahlt, da"s um den gedruckten
Buchstaben herum ein ausreichender Abstand zu benachbarten Zeichen entsteht.
Erforderlich ist dies allerdings nicht; so kann die vom DVI-Treiber auf die
Seite "ubertragene Bitmap durchaus au"serhalb des von \TeX\ freigehaltenen Platzes
zu liegen kommen.
\section[Die Arbeitsweise von \RUMgraph\ ]{Arbeitsweise von \RUMo{\sf graph}}
\markboth{Die Arbeitsweise von \RUMgraph}
{Die Arbeitsweise von \RUMgraph}
Bei der Erzeugung von Zeichen mit dem Programm \RUMgraph\ k"onnen die Angaben
{\em width\/}, {\em height\/} und {\em depth\/} f"ur den \TFM-File und {\em x offset\/}
und {\em y offset\/} f"ur den \PXL-File vom Benutzer festgelegt werden. Die
fehlenden Gr"o"sen {\em x size\/} und {\em y size\/} f"ur den \PXL-File entnimmt
\RUMgraph\ direkt dem Ursprungs-Grafik-File.
Die oben beschriebene M"oglichkeit, Bitmaps auch au"serhalb des von \TeX\
freigehaltenen Platzes zu positionieren, wird genutzt, wenn ein gro"ses
Bild in mehrere Buchstaben zerlegt werden mu"s. Dabei wird n"amlich der
Referenzpunkt f"ur jeden Teilbuchstaben an die Stelle gelegt, die durch den
Referenzpunkt des Gesamtbildes bestimmt ist. Die Breiten der ersten Teilbilder
werden s"amtlich auf Null gesetzt und nur die Breite des letzten Teilbuchstabens
wird gleich der Weite des Gesamtbildes gew"ahlt. Zur Erl"auterung werde das
folgende Bild betrachtet.
\input{lb}
Der Referenzpunkt des Bildes ist die linke untere Ecke. Wird es mit einer
Setzung {\sf /S:3} in einen \PXL-File umgewandelt, so entstehen drei
Teilbuchstaben mit folgenden Referenzpunkten:
\input{lc}
Werden die drei Buchstaben unmittelbar nacheinander ausgegeben, so entsteht
wieder das obige Bild.
Nat"urlich h"atte auch die M"oglichkeit bestanden, f"ur die Teilbuchstaben den
Referenzpunkt stets auf die jeweilige linke untere Ecke zu legen und die Breite
gleich der jeweiligen Pixel-Ausdehnung zu w"ahlen. Diese L"osung birgt aber eine
Gefahr in sich. F"ur die Positionierung seiner Buchstaben auf der Schreiblinie
verwaltet ein {\sf DVI}-Treiber zwei Koordinatenwerte: zum einen die idealen
hochgenauen \TeX-Koordinaten und zum anderen die realen durch die Auf"|l"osung
bestimmten Pixel-Koordinaten. Durch Rundungsfehler driften diese beiden Werte
auseinander. Deswegen "uberpr"uft der Treiber bei jeder Positionierung, ob die
Differenz eine vorgegebene Schwelle (Stichwort: {\em max drift\/}) "uberschreitet.
Ist dies der Fall, so wird die Position um ein oder mehrere Pixel korrigiert.
F"allt nun diese Korrektur zwischen zwei zu einem Bild geh"orenden
Teilbuchstaben, so entstehen entweder wei"se Streifen im Bild oder zwei
Teilbilder "uberlappen sich. Beides ist nicht tolerierbar. Die L"osung mit der
Breite von Null f"ur die ersten Buchstaben vermeidet dieses Problem.
\subsection*{Anmerkungen}
\marginlabel{ADI-Format}
ADI ist ein Grafikformat, das von der Firma AutoDesk definiert wurde, um
Herstellern von Hardware-Komponenten den Anschlu"s ihrer Ger"ate an die von
AutoDesk angebotenen Programme zu erm"oglichen. F"ur verschiedene Ger"ate -- wie
Bildschirm, Drucker, Plotter oder Digitizer -- sind verschiedene Formate
festgelegt. Das von \RUMgraph\ verwendete \ADI-Format dient dazu, einfache
Grafikdrucker -- {\em printer/plotter\/} im Jargon von AutoDesk -- zu betreiben.
\marginlabel{\PCX-Format}
\PCX\ ist das Grafik-Format der Firma ZSoft. Es geh"ort wohl zu den verbreitetsten
Grafik-Formaten "uberhaupt. Fast alle Pixel-orientiert arbeitenden Programme
unterst"utzen es. Auch Bilder, die "uber einen Scanner gewonnen werden, k"onnen
meistens (neben TIFF) auch im \PCX-Format abgelegt werden. \PCX\ umfa"st neben
monochromen Bildern auch Graustufen- und Farbgrafiken. \RUMgraph\ bearbeitet nur
monochrome \PCX-Files. Farb- bzw. Graustufenbilder m"ussen also vorher in
monochrome Bilder umgewandelt werden. Auf dem Markt (auch im
Public-Domain-Bereich) existiert eine gro"se Anzahl von Programmen, die diese
Umwandlung vornehmen. Entsprechendes gilt auch f"ur die Umwandlung anderer
Grafikformate nach \PCX.
\marginlabel{Entfernen von Leerraum}
Das Programm \RUMgraph\ entfernt s"amtlichen Leerraum rund um das Bild. "Ubrig
bleibt ein Rechteck, das auf jeder Seite mit wenigstens einem schwarzen Punkt
besetzt ist. Soll um das Bild herum Leerraum vorgesehen werden, um Platz zu den
Nachbarzeichen zu gewinnen, so ist dies "uber die Optionen f"ur die metrischen
Werte (x, y, w, h und d) zu erreichen.
\marginlabel{Zuordnung von Zeichen zu Teilbildern}
Wird ein gro"ses Bild in Teilbilder zerlegt, so werden diese fortlaufend freien
Zeichen zugeordnet. Die Zuordnung beginnt mit der in der c-Option angegebenen
Zeichennummer. Wird ein Zeichen erreicht, das bereits belegt ist, so wird es
"ubersprungen. Wird das Zeichen mit der Nummer 127 erreicht, so wird anschlie"send
mit dem Zeichen mit der Nummer 0 fortgefahren. Die von \RUMgraph\ vorgenommene
Zuordnung kann sowohl dem Log-File (Erweiterung: {\sf RGL}) als auch dem
\TeX-Input-File entnommen werden.
Ich m"ochte im folgenden einige Wege zur Gewinnung von Bildern aus verschiedenen
Quellen aufzeigen, die sich f"ur meine Arbeiten als Standard herausgebildet
haben. Wenn man sich, so wie ich, nur sporadisch mit der Einbindung von Grafik
besch"aftigt, so ist das Herausarbeiten von Standardwegen, die man ohne gro"se
Vorkehrungen nutzen kann, "au"serst wichtig. Denn, das soll nicht verschwiegen
werden, die Aufbereitung von Bildern und ihre Einbindung in ein Dokument kann
m"uhsam und auch sehr zeitaufwendig sein. Dies gilt besonders dann, wenn man sich
die Methoden erst erarbeiten oder auch nur wieder ins Ged"achnis rufen mu"s.
\subsection{Anmerkungen zur Erzeugung der Bilder}
\markboth{Anmerkungen zur Erzeugung der Bilder}
{Anmerkungen zur Erzeugung der Bilder}
Quellen f"ur die Gewinnung von Bildern sind neben Scannern und
Bildschirmmitschnitten vor allem spezielle Programme, die zu diesem Zweck
entworfen wurden. Ich selbst nutze zur Zeit die Programme AutoCAD f"ur technische
Zeichnungen, CorelDraw f"ur Pr"asentationsgrafiken, PC Paintbrush f"ur Pixelbilder
und Framework f"ur Diagramme. Aber auch mit OrCAD entworfene Schaltpl"ane, Bilder
vom Apple MacIntosh oder Darstellungen statistischer Daten von StatGraphics sind
von mir schon genutzt worden.
Die Programme legen ihre Bilder im allgemeinen in einem Programm-spezifischen
Format ab. Nur einige wenige gestatten es, direkt die Formate \ADI\ bzw.
\PCX\ zu erzeugen. Allerdings stellt die gro"se Uneinheitlichkeit der
Grafikformate kein wirkliches Hindernis f"ur unser Vorhaben dar. Denn es gibt
heute sowohl im kommerziellen wie auch im Public-Domain- und Shareware-Bereich
gen"ugend Programme, die beinahe jedes Format in jedes umwandeln. Ich benutze
manchmal z.B. das Programm HiJaak, das die Formate PXL (ZSoft), FAX (CCITT), GIF
(CompuServ), TIFF, DXF (AutoDesk), IFF (Amiga), IMG (Digital Research), CUT
(Halo), PCL (HP Drucker), HPGL (HP Plotter), PIX (North American Software), PIC
(Lotus), MAC (Apple), MSP (Microsoft), WPG (WordPerfect) usw. ineinander
umwandelt. Auch wenn Programme wie dieses eine gute Basis darstellen, bevorzuge
ich jedoch meistens einen anderen Weg. Alle Programme k"onnen n"amlich
selbstverst"andlich einen Drucker ansteuern, und meistens kann die Druckausgabe
auch in einer Datei abgelegt werden. Ist letzteres nicht der Fall, so mu"s man
sich eines Drucker-Spoolers oder anderer Spezialprogramme bedienen. Die
Druckausgabe ist wohl die universellste Quelle zur Gewinnung von Bildern. Ich
benutze Ausgaben f"ur den HP LaserJet (PCL-Format) und f"ur PostScript-Drucker
(PS-Format); seltener auch Ausgaben f"ur einen HP-Plotter (HPGL-Format). Ich
kenne eigentlich kein wesentliches Programm, das nicht wenigstens eines dieser
Formate erzeugen kann.
Ein besonders zu behandelndes Problem ist die Festlegung der Bildabmessungen,
insbesondere wenn das gleiche Bild f"ur verschiedene Drucker mit
unterschiedlichen Auf"|l"osungen erzeugt werden soll. Am Rechenzentrum betreiben
wir z.B. neben den "ublichen Laserdruckern mit 300-dpi-Auf"|l"osung auch einen
Drucker der Firma Agfa mit einer Auf"|l"osung von 406 dpi. Hier liegt eine der
St"arken von Programmen wie AutoCAD. Bei der Erzeugung eines \ADI-Files kann
jede gew"unschte Abmessung und jede Auf"|l"osung exakt spezifiziert werden.
Schwieriger ist dagegen die Anpassung von Druckausgaben, die typischerweise in
einer Auf"|l"osung von 300 dpi erstellt werden. Zwar kann, wie wir unten sehen
werden, die Auf"|l"osung bei der Umwandlung auch in gewissen Grenzen beeinflu"st
werden, aber so exotische Werte wie 406 dpi sind meistens nicht spezifizierbar.
Hier hilft eine Besonderheit der Umwandlung durch \RUMgraph\ weiter. Jeder
Ein\-ga\-be-File wird n"amlich grunds"atzlich nur als Pixel-Quelle verstanden.
Zwar enthalten sowohl \ADI- als auch \PCX-Files eine Auf"|l"osungsangabe,
diese wird jedoch von \RUMgraph\ v"ollig ignoriert. Extrahiert wird nur das in
der jeweiligen Datei enthaltene Bitmuster, und die Gr"o"se eines Bildpunktes wird
ausschlie"slich durch die Angabe im {\em makefile\/} bestimmt. Damit hat man aber
die M"oglichkeit, auch Bilder, die "uber eine 300-dpi-LaserJet-Ausgabe gewonnen
werden, in gewissen Grenzen an andere Auf"|l"osungen anzupassen.
Hat man z.B. ein Bild f"ur eine Auf"|l"osung von 300 dpi erzeugt und m"ochte das
gleiche Bild auch in anderen Auf"|l"osungen, z.B. 100 dpi und 406 dpi, vorhalten,
so mu"s man mit Hilfe des erzeugenden Programms das Ausgangsbild manipulieren.
F"ur die 100-dpi-Auf"|l"osung mu"s man es auf 1/3 verkleinern, f"ur die
406-dpi-Auf"|l"osung mu"s man es um ca. 1/3 (genauer 106/300) vergr"o"sern. Gibt man
diese so manipulierten Bilder als Druckerausgabe aus, so haben sie zwar erst
einmal alle die Auf"|l"osung von 300 dpi; die Gr"o"sen der Bilder verhalten sich aber
wie 1:3:4. Wandelt man diese Bilder nun um in \PXL-Files mit den Auf"|l"osungen
100, 300 und 406 dpi, so haben die drei Bilder bei Ausgabe auf Druckern mit
entsprechender Auf"|l"osung alle drei die gleiche reale Gr"o"se.
Mir ist klar, da"s dieser Vorgehensweise Grenzen gesetzt sind. Vor allem hohe
Auf\-l"o\-sun\-gen (z.B. 2400 dpi) sind auf diese Art nur f"ur sehr kleine Bilder
zu realisieren. F"ur "`unser aller Tagesgesch"aft"' jedoch, das von Druckern mit
Auf"|l"osungen von 300 dpi bestimmt wird, ist der Ansatz gut praktizierbar.
\subsection{Die Einbindung von PostScript-Bildern}
\markboth{Die Einbindung von PostScript-Bildern}
{Die Einbindung von PostScript-Bildern}
Die Nutzung der PostScript-Ausgabe eines Programms ist f"ur mich zum bevorzugten
Weg zur Gewinnung von Bildern geworden. Selbst bei Programmen, wie z.B.
CorelDraw, die eine direkte \PCX-Ausgabe anbieten, lohnt sich h"aufig der
"`Umweg"' "uber PostScript. Denn viele Programme bieten ihren vollen
Leistungsumfang nur dann, wenn eine PostScript-Ausgabe angestrebt wird. Meistens
gibt es drei Varianten f"ur die PostScript-Ausgabe:
\marginlabel{PostScript} Diese Ausgabe ist direkt f"ur einen PostScript
Drucker bestimmt.
\marginlabel{EPS} Die Variante {\em encapsulated PostScript\/} bezeichnet eine
Variante, die dem Austausch mit anderen Programmen dient. Bestimmte
PostScript-Kommandos werden vermieden, und in vorangestellten Kommentaren sind
Zusatzangaben f"ur das Zielprogramm enthalten.
\marginlabel{EPS mit Header-File} Hierbei handelt es sich ebenfalls um eine {\sf
EPS}-Ausgabe, der aber ein {\sf TIFF}-Pixel-File vorangestellt ist. Dieser wird
von manchen weiterverarbeitenden Programmen (z.B. PageMaker oder Ventura
Publisher) genutzt, um ein Pseudo-Preview zu erm"oglichen.
Je nach Programm, das f"ur die Umwandlung verwendet wird, k"onnen ein oder mehrere
dieser Formate genutzt werden. F"ur den von mir beschriebenen Weg ist nur die
Ausgabe "uber den echten PostScript Drucker m"oglich.
Zur Umwandlung von PostScript nach \PCX\ sind mehrere Programme auf dem Markt
verf"ugbar. Ich benutze das Programm {\sf GoScript} der Firma LaserGo. Es bietet
einen echten Preview f"ur PostScript-Files, wird zu einem vern"unftigen Preis
angeboten und kann unter anderem direkt \PCX-Ausgaben erzeugen. Die Auf"|l"osung
kann dabei in engen Grenzen festgelegt werden.
F"ur den Aufruf des Programms ist {\sf GoScript} "uber eine eigene
Umgebungsvariable {\em gs\/} mitzuteilen, wo seine Konfigurationsdaten, seine
Zeichens"atze usw. zu finden sind; z.B.
\hspace*{1in} {\sf set\ \ gs=d:\verb+\+goscript}
Danach kann das Programm gestartet werden mit einem Kommando der Form:
Die Angabe {\sf 300x300} im Beispiel bezeichnet die gew"unschte Auf"|l"osung. F"ur
weitere Auf"|l"osungen und andere Optionen sei auf das {\sf GoScript}-Handbuch
verwiesen. Erzeugt wird ein monochromer \PCX-File, der unter dem Namen {\sf
GSWxxxx.PCX}, wobei {\sf xxxx} eine fortlaufende Nummer ist, auf der Platte
abgelegt wird. Eine sofortige Umbenennung in einen aussagekr"aftigeren Namen ist
zu empfehlen. Die Bilder werden "ubrigens wei"s auf schwarz dargestellt, so da"s
sich eine Umwandlung mit der i-Option anbietet.
Die Clipart-Bilder der Beispiele wurden auf diese Weise gewonnen.
\subsection{Die Einbindung von HP-LaserJet-Ausgaben}
\markboth{Die Einbindung von HP-LaserJet-Ausgaben}
{Die Einbindung von HP-LaserJet-Ausgaben}
Der Weg zu einem Bild "uber eine HP-LaserJet-Ausgabe (PCL-File) ist sozusagen die
{\em ultima ratio\/}. Man kann davon ausgehen, da"s jedes ernstzunehmende Programm
in der PC-Welt zumindest dieses Ausgabeformat anbietet. Ganz ohne Probleme, die
zu beachten sind, geht es aber auch hier nicht ab.
\begin{enumerate}
\item Die von HP definierte Druckersteuersprache PCL hat bereits eine l"angere
Geschichte hinter sich. Sie ist im Laufe der Zeit immer wieder an neuere Drucker
angepa"st worden. HP versucht diese Entwicklung durch die Definition
verschiedener Level in den Griff zu bekommen, allerdings etwas halbherzig, denn
auch innerhalb eines Levels gibt es leider immer wieder Unterschiede. Gerade die
Steuersprache des ansonsten sehr attraktiven HP DeskJet gestattet einige
ansonsten nicht vorhandene Sonderbefehle, die bei der Umwandlung Schwierigkeiten
bereiten k"onnen. Im allgemeinen ist man aber auf der sicheren Seite, wenn man
eine Druckerausgabe f"ur einen HP LaserJet, einen HP LaserJet Plus oder einen HP
LaserJet Serie II aufbereitet.
\item Die Definition von PCL umfa"st neben der Grafiksteuerung auch ein
leistungs\-f"ahi\-ges Font-Management. Befehle, die in den letzteren Rahmen
fallen, werden von manchen Umwandlungsprogrammen nicht bearbeitet. Zwar reicht
dies in der "uberwiegenden Zahl der F"alle v"ollig aus, im Einzelfall k"onnen aber
doch gerade Beschriftungen bei der Umwandlung verloren gehen.
\end{enumerate}
Ich benutze zur Umwandlung von PCL nach \PCX\ das Programm {\sf HP2PCX} der
Firma ZSoft. Es ist Bestandteil des Lieferumfangs des Programms {\em PC
Paintbrush IV Plus\/}. Das Programm behandelt auch Font-Befehle und sieht
zus"atzlich einen Ersetzungsmechanismus f"ur nicht vorhandene Zeichens"atze vor.
Einzelheiten sind dem Handbuch zu entnehmen.
Der Aufruf des Programms erfolgt in der "ublichen Weise durch eine
Kommandoeingabe der wohl nicht weiter erkl"arungsbed"urftigen Form:
Es sei noch darauf hingewiesen, da"s auch das \TeX-Paket em\TeX\ von Eberhard
Mattes ein "ahnliches Programm mit Namen {\sf PCLtoMSP} enth"alt. Es bearbeitet
jedoch keine Zeichensatzbefehle, und als Ausgabe wird ein {\sf MSP}-File des
Windows-Paint-Programms erzeugt, der noch mit einem Programm wie {\em HiJaak\/}
nach \PCX\ umgewandelt werden mu"s.
Ein Farbdrucker wirklich guter Qualit"at ist zur Zeit ein "au"serst selten
verf"ugbares Ausgabeger"at. Den meisten Lesern wird wohl wie mir nur ein
monochromer Drucker zur Verf"ugung stehen. Nun liegen aber viele Bilder,
insbesondere Fotos, in Farbe vor. Dies bedeutet, da"s auch nach Wegen gesucht
werden mu"s, Farbbilder in monochrome Bitmaps umzuwandeln.
Hierzu bedient man sich "ublicherweise eines Farbzerstreuungsverfahrens ({\em
dithering\/}). Dabei wird jeder Farbpunkt nach einem bestimmten Muster in
Grauwerte zerlegt, die dann anteilm"a"sig auf die Nachbarpunkte zerstreut werden.
"Uberschreiten die aufsummierten Grauwerte eines Punktes eine vorgegebene
Schwelle, so wird der Punkt schwarz gesetzt, sonst bleibt er wei"s. So entstehen
Pseudo-Graustufenbilder, die eine durchaus akzeptable Qualit"at erreichen. Das
Shareware-Produkt {\sf GWS} ({\em Grafic Work Shop\/}) bietet hier besonders
vielf"altige und ausgefeilte Verfahren zur Farbverteilung. Leider ist es
unm"oglich, ein Verfahren zu benennen, das in jedem Fall beste Ergebnisse
erzielt. Man wird von Fall zu Fall mehrere Methoden ausprobieren m"ussen. Da aber
gerade die besonders guten Verfahren "au"serst zeitintensiv sind, ist der
erforderliche Zeitaufwand betr"achtlich.
Ich habe mit gutem Erfolg einen anderen Weg beschritten. Zum Lieferumfang des
{\sf GWS} geh"ort auch ein Programm mit Namen {\sf PostGif}. Es wandelt Farb-{\sf
GIF}-Files in Graustufen-PostScript-Files um. Ein Farbbild, das nicht im {\sf
GIF}-Format vorliegt, kann mit dem {\sf GWS}-Hauptprogramm hierhin umgewandelt
werden. Die erzeugten PostScript-Bilder k"onnen dann, wie oben beschrieben,
weiterverarbeitet werden.
Das Beispiel des Clown-Fotos wurde auf diesem Weg gewonnen.
\subsection{Aufbereitung gescannter Bilder mit AutoCAD}
\markboth{Aufbereitung gescannter Bilder mit AutoCAD}
{Aufbereitung gescannter Bilder mit AutoCAD}
Bilder, die "uber einen Scanner gewonnen werden, sind zun"achst in ihrer Gr"o"se
und Auf"|l"osung festgefroren. M"ochte man sie als Basis f"ur eine Reihe von
gleichen Bildern unterschiedlicher Gr"o"se nutzen, so m"ussen sie vektorisiert
werden. Auch zu diesem Zweck existieren Spezialprogramme, wie z.B. ScanPro oder
Streamline, und auch manche Grafikprogramme bieten eine entsprechende
Dienstleistung an. Besonders bei Graustufen- oder Farbbildern "uberzeugen die so
automatisch gewonnenen Bilder nicht immer.
Ich habe mir deshalb eine andere M"oglichkeit zur "`Vektorisierung per Hand"'
geschaffen. Ich "ubernehme die gescannten Bilder nach AutoCAD und zeichne ihre
Konturen mit den dort zur Verf"ugung stehenden Werkzeugen nach. F"ur weniger
komplexe Bilder ist dies mit ertr"aglichem Aufwand zu bewerkstelligen.
Zur "Ubernahme eines \PCX-Files nach AutoCAD dient das von mir geschriebene
Programm {\sf PCXtoDXB}. Es wird aufgerufen durch eine Kommandoeingabe der Form:
Das Ergebnis ist ein sogenannter {\sf DXB}-File. Dies ist ein bin"ares
AutoCAD-spe\-zi\-fi\-sches Austauschformat, das von AutoCAD mit dem Befehl {\sf
DXBIN} eingelesen werden kann. Um die Gr"o"se des {\sf DXB}-Files in Grenzen zu
halten, wird der Eingabe-Pixel-File nicht, wie es sich anbieten w"urde, in eine
Punktwolke umgewandelt, sondern in eine Anh"aufung von waagerechten und
senkrechten Linien. Diese grobe Vorlage lege ich innerhalb von AutoCAD in ein
eigenes {\em layer\/} und w"ahle dabei eine helle Grundfarbe, z.B. gelb; das
Nachzeichnen geschieht dann in einem anderen {\em layer\/} in einer dunkleren
Farbe, z.B. schwarz.
Das Bild des \LaTeX-L"owen ist so entstanden, und ein Institut der Universit"at
hat auf diese Weise "uber den Scanner einen singalesischen Zeichensatz generiert.
Die Ergebnisse meiner Vorgehensweise sind im strengen Sinne {\bf nicht}
ge\-r"a\-te\-un\-ab\-h"an\-gig. \RUMgraph\ geht von Pixel-Quellen aus, und deren
Auf"|l"osung und Abmessung spiegelt sich im \TFM- und \PXL-File wieder. F"ur die
Einbindung von Einzelbildern in ein bestimmtes Dokument, das nur auf einem
Drucker ausgegeben werden soll, st"ort diese Abh"angigkeit in keiner Weise.
Hat man jedoch mit den in diesem Abschnitt beschriebenen Methoden aus einem Bild
mehrere Varianten f"ur Drucker verschiedener Auf"|l"osungen gewonnen, so m"ochte
man f"ur alle Varianten nat"urlich nur einen \TFM-File verwenden.
Entsprechendes gilt auch f"ur das in den Beispielen wiedergegebene singalesische
Alphabet, das in mehreren Vergr"o"serungen erzeugt wurde.
\RUMgraph\ bietet das Handwerkszeug an, um die Ger"ateunabh"angigkeit in diesem
Sinne zu erreichen. Jedes der Bilder und jeder der Zeichens"atze mit
unterschiedlicher Auf"|l"osung bzw. Vergr"o"serung entstehen durch einen eigenen
\RUMgraph-Lauf mit eigenem {\em makefile\/}. Jeder dieser {\em makefiles\/} enth"alt
Angaben, die den \TFM-File beeinflussen. Konkret sind dies die Werte der w-, h-,
d- und s-Option. M"ochte man also aus allen L"aufen einer Serie identische
\TFM-Files gewinnen, so m"ussen in allen {\em makefiles\/} diese Werte gleich
angesetzt werden. Dies ist m"oglich, da genau diese Optionen in absoluten, von
der Pixel-Auf"|l"osung unabh"angigen Ma"seinheiten angegeben werden k"onnen. Die
automatischen Festlegungen dieser Optionen sind jedoch weniger geeignet. Sie
benutzen die in Pixeln gemessenen Abmessungen der Bitmaps, werden demnach also
auch, durch Rundungsfehler bedingt, f"ur jeden Lauf einen anderen \TFM-File
erzeugen. Dies hei"st aber nichts weiter, als da"s der Benutzer diese Optionen
explizit spezifizieren mu"s.
\newpage
Zusammenfassend kann man sagen:
\begin{quote}
{\bf Will man f"ur eine Serie von Bildern, die aus Varianten des gleichen
Bildes mit unterschiedlichen Auf"|l"osungen bzw. Vergr"o"serungen besteht, gleiche
\TFM-Files erhalten, so sind in allen zugeh"origen makefiles die gleichen Werte
f"ur die Optionen w, h, d und s explizit einzutragen.}
