DE3382752T2 - Verfahren zur Umwandlung einer ersten editierbaren Dokumentenform, vorbereitet von einem Stapeltextverarbeitungssystem, in eine zweite editierbare Dokumentenform, die für ein Interaktiv- oder Stapeltextverarbeitungssystem brauchbar ist. - Google Patents

Description

Hintergrund der Erfindung 1. Technisches Gebiet
• Diese Erfindung befaßt sich mit einem Verfahren zur Umwandlung editierbarer Dokumente, die in einem ersten Format von einem Stapeltextverarbeitungssystem erstellt worden sind und für dieses verwendet werden, in ein zweites editierbares Format, das in und von einem anderen Textverarbeitungssystem - entweder vom interaktiven Typ oder vom Typ Stapelverarbeitung - verwendet werden kann und das sonst inkompatibel zum ersten Dokumentenformat ist. Insbesondere soll diese Erfindung die erforderliche Umwandlung zwischen verschiedenen Formaten eines editierbaren Dokuments mittels eines Verfahrens erzielen, das die Umwandlung einer Abfolge von Eingabeobjekten von der Stapelverarbeitungs- Quellform in einen ganz bestimmten Satz von Ausgabeobjekten für die editierbare Form des Zieldokuments auf der Grundlage geeignet gewählter Statusvariablen, die die Abfolge der Eingangsobjekte darstellen, bewirkt.
2. Stand der Technik
• Zur Darstellung editierbarer bzw. überarbeitungsfähiger Dokumente in Datenverarbeitungssystemen sind mehrere verschiedene Formate bekannt und allgemein gebräuchlich. Ein paar Beispiele sind OIIA L3, die von Displaywriter und 5520-Systemen verwendet wird, sowie ein Format, das häufig "Two-Baker genannt und vom System 3790 und DOSF/DPCX/8100 verwendet wird, und das DCF-Eingabeformat, das vom Document Composition Facility und vom Professional Office System verwendet wird. Displaywriter ist eine Textverarbeitung, die in erster Linie für den Einzelbetrieb gedacht und geeignet ist und von International Business Machines Corporation (IBM Corporation) hergestellt und verkauft wird. Dieser Typ von Textverarbeitungen ist allgemein als "WYSIWYG"- oder als interaktives System bekannt. Das System 5520 ist ein Mehrplatz-Textverarbeitungs- und -Bürokommunikationssystem mit gemeinsamer Logik und wird ebenfalls von der IBM Corporation verkauft. Das System 3790 kann als Minicomputer eingestuft werden und ist ein intelligentes Textverarbeitungssystem. Das System 8100, das ebenfalls als Minicomputer eingestuft werden kann, ist dazu ausgelegt, mittels DOSF, einem Textverarbeitungspaket, und DPCX, einem speziellen Betriebssystem, als Textverarbeitungssystem zu arbeiten. Sowohl das System 3790 als auch das System 8100 werden von der IBM Corporation hergestellt und verkauft. Das Produkt Document Composition Facility bzw. SCRIPT/VS ist ein von der IBM Corporation verkauftes Textverarbeitungsprogramm. Das Professional Office System oder PROFS ist ein menügesteuertes Programm, das von der IBM Corporation verkauft wird und insbesondere zur Bearbeitung eines breiten Spektrums bürobezogener Aufgaben ausgelegt und geeignet ist. Es enthält Einrichtungen zur Textverarbeitung, welche das DcF-Format editierbarer Textdarstellungen verwenden. Bei dieser Art von Textverarbeitungssystemen bettet der Benutzer Text in das Dokument ein, der danach als ein oder mehrere Formatbefehle interpretiert wird und im editierbaren Dokument als Text verbleibt. Diese Dokumentenform wird bei der anschließenden Interpretation als ganzes Dokument formatiert oder stapelverarbeitet.
• Dies sind mehrere der verfügbaren Textverarbeitungssysteme der IBM Corporation, die zur Erstellung, Bearbeitung und Formatierung editierbarer Dokumente verwendet werden können. Es gibt aber auch viele andere gute Textverarbeitungssysteme und die dazugehörige Software von anderen Lieferanten. Aufgrund der überwältigenden Anzahl heute verfügbarer Textverarbeitungssysteme ist die gleichzeitige Installation verschiedener Textverarbeitungen durchaus gebräuchlich (vergleiche z. B. GB-A- 1 537 429). Aufgrund der Inkompatibilität der verschiedenen Textverarbeitungssysteme und der mit ihnen erstellten editierbaren Dokumente ist es aber äußerst schwierig, verschiedenen Personen, die bei dem Erstellung und Bearbeitung eines bestimmten Dokuments zusammenarbeiten müssen, eine Einrichtung zur Umwandlung von Dokumentenformaten zur Verfügung zu stellen. Außerdem erfordert dies, daß jede an der Bearbeitung des Dokuments beteiligte Partei dazu mehrere Möglichkeiten hat. Dieses Bedürfnis kann von einer Betriebsumgebung mit unüberwindbaren Systemgrenzen nicht effizient bzw. effektiv unterstützt werden.
• Aus der Umwandlung von Dokumenten, die mit einem ersten Textverarbeitungssystem in einem bekannten Format erstellt worden sind, in ein anderes Format, das in einem anderen Textverarbeitungssystem verwendet und vollständig editiert werden kann, leiten sich klar zu erkennende und wichtige Vorteile ab. Ohne diese Umwandlungseinrichtung sind Dokumente, die auf irgendeinem bekannten System erstellt worden sind, für Benutzer anderer Systeme wertlos und können nicht überarbeitet werden. Es ist jedoch kein einfaches oder leichtes Unterfangen, eine Umwandlungseinrichtung zur Verfügung zu stellen. Dem Fachmann wird es einleuchten, daß die erforderliche Umwandlungseinrichtung zur Umwandlung eines ersten Dokumentenformats in ein zweites Dokumentenformat, das in einem anderen und sonst inkompatiblen Textverarbeitungssystem editiert werden kann, mehr als eine bloße Eins-zu-Eins-Substitutionsformel verwendet.
• Ein bekanntes Umwandlungsverfahren nach dem Stand der Technik bietet die Document Interchange Facility oder DIF. Dieses Programm der IBM Corporation dient dazu, editierbare Dateien im "Two-Baker"-Format in Dateien im DCF-Format mittels eindeutig definierter SCRIPT-Makros umzuwandeln. Diese Makros rufen im wesentlichen für jeden angetroffenen "Two-Baker" -Befehl einen Datenblock auf, aber das ersetzte Material ist kein gleichbedeutender DCF-Befehl. Dieser DIF-konvertierte Datenstrom gestattet zwar, daß eine endformatierte Version des ursprünglichen "Two-Baker"-Dokuments mit Hilfe der übersetzten Datei, die diese Makros enthält, in einem DCF-Textverarbeitungssystem erstellt werden kann, allerdings kann er nicht leicht editiert oder wirksam bearbeitet werden, da dieser Datenstrom atypisch, d. h. keine normale DcF-Datei ist. Dieser Lösungsansatz erlaubt die Formatierung eines Dokuments, das in einem ersten editierbaren Format erstellt worden ist, in einer Textverarbeitung, die für Dokumente eines zweiten Formats ausgelegt ist, aber er gestattet nicht das Editieren des "umgewandelten" Dokuments zu einem früheren Zeitpunkt.
Aufgaben und Zusammenfassung der Erfindung
• Dementsprechend besteht eine Hauptaufgabe der vorliegenden Erfindung darin, ein Verfahren zur Umwandlung eines Dokuments, das mit einem Stapeltextverarbeitungssystem in einem editierbaren Quellformat erstellt worden ist, wobei dieses Format nur mit diesem Stapeltextverarbeitungssystem editiert oder formatiert werden kann, in ein anderes editierbares Format bzw. ein Zielformat, das zum Editieren und Formatieren in einem entsprechenden Typ von Ziel-Textverarbeitungssystem vollständig geeignet ist, zur Verfügung zu stellen.
• Eine weitere Hauptaufgabe der vorliegenden Erfindung ist es, ein Verfahren zur Verfügung zu stellen, bei dem diese Umwandlung für die Benutzer des Textverarbeitungssystems transparent ist und nicht deren Eingreifen bedarf, um die Umwandlung zu bewirken.
• Eine weitere Aufgabe der vorliegenden Erfindung besteht darin, Verfahren zur Umwandlung eines Datenstroms aus einem Dokumentenformat in ein anderes zur Verfügung zu stellen, das schnell und effizient arbeitet und nicht mehr Systemressourcen als nötig bindet.
• Es ist noch eine weitere Aufgabe der vorliegenden Erfindung, Verfahren zur Verfügung zu stellen, bei denen das durch die Umwandlung erzeugte Dokumentenformat eindeutig und klar ist und einen Benutzer des Ziel-Textverarbeitungssystems hinsichtlich der Editierfähigkeit nicht beschränkt.
• Diese und andere Aufgaben der vorliegenden Erfindung werden anspruchsgemäß durch ein Umwandlungsverfahren erreicht, bei dem als erster Schritt der vorliegenden Erfindung eine feste Anzahl von Schlüssel-Statusvariablen definiert wird. Diese Schlüssel- Statusvariablen enthalten Steuerzeichen hinsichtlich des Quelldokuments, die aus diesem sequentiell eingelesen werden. Der nächste Schritt erfordert es, die Kompatibilität der Steuerzeichen zu definieren, d. h. zu entscheiden, welche Steuerzeichen des Quelldokuments zu anderen Quellsteuerzeichen kompatibel sind, die in Statusvariablen, die in der Abfolge gesetzt worden sind, gespeichert sind. Nach dem Festlegen der Kompatibilität der Steuerzeichen müssen alle Ausgabeobjekte definiert werden, die möglicherweise als Teil der Umwandlung einer beliebigen Eingabesequenz für das Zieldokument geschrieben werden müssen. Bezüglich der so definierten Ausgabeobjekte ist eine Reihenfolge dieser Objekte zu erstellen, so daß sie bei der Umformung gleichartig behandelt werden. Für jedes mögliche Ausgabeobjekt ist dann ein Satz von Regeln zu erstellen, die als Reaktion auf eine spezielle Sequenz von Eingabeobjekten, die aus dem Quelldokument eingelesen worden sind, auf der Grundlage des Werts der Statusvariablen darüber bestimmen, wann und ob dieses Ausgabeobjekt in das Zieldokument geschrieben wird. Falls irgendeine oder mehrere der Regeln erfüllt sind, wird das Ausgabeobjekt geschrieben. Definitionsgemäß beendet angetroffener Text stets eine Sequenz und leitet, falls erforderlich, einen Schreibvorgang im Zieldokument ein.
Kurzbeschreibung der Abbildungen
• Die Erfindung wird ferner mit Hilfe eines bevorzugten Beispiels von ihr unter Bezugnahme auf die anliegenden Abbildungen beschrieben, in denen zur Beschreibung gleicher Elemente in den verschiedenen Ansichten gleiche Bezugsnummern verwendet worden sind, wobei:
• Fig. 1 schematisch eine vereinfachte Darstellung einer vereinten, jedoch separierbaren Konfiguration zweier Textverarbeitungssysteme zeigt, die dazu geeignet sind, editierbare Dokumente erfindungsgemäß von einem Textverarbeitungssystem in das andere umzuwandeln und dann zu übertragen;
• Fig. 2 in Tabellenform eine Erklärung für jede der Statusvariablen gibt, die beim Lesen einer DcF-Steuerzeichensequenz erfindungsgemäß gesetzt werden;
• Fig. 3A bis 3C die Auswirkung bestimmter DcF-Steuerzeichen auf die in Fig. 2 vorgestellten Statusvariablen zusammenfaßt;
• Fig. 4 die Abkürzungen bestimmter L3-Steuerzeichen und deren Bedeutung, die erfindungsgemäß sortiert sind, zusammenfaßt;
• Fig. 5 eine Entscheidungstabelle darstellt, die die Regeln zeigt, die die Reihenfolge in der Tabelle in Fig. 4 bestimmen, wobei diese Regeln durch die Spalten dieser Tabellen dargestellt sind;
• Fig. 6 und 7 die übrigen Regeln zeigen, die die Reihenfolge in der Tabelle in Fig. 4 bestimmen, wobei diese Regeln wiederum durch die Spalten dieser Tabellen dargestellt sind;
• Fig. 8 die Entscheidungstabelle für die Verknüpfung zwischen den in den Tabellen von Fig. 5, 6 und 7 betrachteten L3-Steuerzeichen zeigt;
• Fig. 9A und 9B Entscheidungstabellen von tabellarischen Zusammenfassungen der Umwandlung in das L3-Steuerzeichen CRE zeigen;
• Fig. 10 eine Entscheidungstabelle einer tabellarischen Zusammenfassung der Umwandlung in das L3-Steuerzeichen RCR darstellt;
• Fig. 11 eine Entscheidungstabelle einer tabellarischen Zusammenfassung der Umwandlung in den aus mehreren CREs bestehenden L3- Steuerzeichensatz zeigt;
• Fig. 12 eine Entscheidungstabelle einer tabellarischen Zusammenfassung der Umwandlung in die aus mehreren Wiederholungen des Paars (RSP CRE) bestehenden L3-Steuerzeichen darstellt;
• Fig. 13 eine Entscheidungstabelle einer tabellarischen Zusammenfassung der Umwandlung in die aus mehreren Wiederholungen des Paars (CRE RSP) bestehenden L3-Steuerzeichen zeigt;
• Fig. 14 eine Entscheidungstabelle einer tabellarischen Zusammenfassung der Umwandlung in das L3-Steuerzeichen EUS darstellt;
• Fig. 15 eine Entscheidungstabelle einer tabellarischen Zusammenfassung der Umwandlung in das L3-Steuerzeichen RPE zeigt;
• Fig. 16 eine Entscheidungstabelle einer tabellarischen Zusammenfassung der Umwandlung in das L3-Steuerzeichen LFC darstellt;
• Fig. 17 eine Entscheidungstabelle einer tabellarischen Zusammenfassung der Umwandlung in das L3-Steuerzeichen ZICR zeigt;
• Fig. 18 eine Entscheidungstabelle darstellt, die die Beziehung zwischen L3-Objekten, die einen Absatz beenden, und den DCF- Steuerzeichen, die in diese L3-Objekte umgewandelt werden, zeigt;
• Fig. 19 eine Entscheidungstabelle einer tabellarischen Zusammenfassung der Umwandlung in das L3-Steuerzeichen PE darstellt;
• Fig. 20 eine Entscheidungstabelle einer tabellarischen Zusammenfassung der Umwandlung in das L3-Steuerzeichen TUP zeigt;
• Fig. 21 eine Entscheidungstabelle einer tabellarischen Zusammenfassung der Umwandlung in das L3-Steuerzeichen TUFC darstellt;
• Fig. 22 eine Entscheidungstabelle einer tabellarischen Zusammenfassung der Umwandlung in die L3-Steuerzeichen für Top MP und Top MT darstellt;
• Fig. 23 eine Entscheidungstabelle einer tabellarischen Zusammenfassung der Umwandlung in die L3-Steuerzeichen für Bottom MP und Bottom MT zeigt;
• Fig. 24 eine Entscheidungstabelle einer tabellarischen Zusammenfassung der Umwandlung in das L3-Steuerzeichen BT darstellt;
• Fig. 25 eine Entscheidungstabelle einer tabellarischen Zusammenfassung der Umwandlung in die L3-Steuerzeichen mehrerer SPs und ATF darstellt;
• Fig. 26 eine Entscheidungstabelle einer tabellarischen Zusammenfassung der Umwandlung in das L3-Steuerzeichen mehrerer ITs zeigt;
• Fig. 27 eine tabellarische Zusammenfassung der DcF-Steuerzeichen, die das Einfügen von ITs in das L3-Dokument erfordern, in einer gegebenen Reihenfolge zeigt;
• Fig. 28 eine Entscheidungstabelle einer tabellarischen Zusammenfassung der Umwandlung in das L3-Steuerzeichen für BUS darstellt;
• Fig. 29 eine Entscheidungstabelle einer tabellarischen Zusammenfassung, die das Schlüsselvariablen-Steuerzeichen CURHW setzt, zeigt;
• Fig. 30 eine Entscheidungstabelle einer tabellarischen Zusammenfassung der Umwandlung in das L3-Steuerzeichen SPECIAL PE darstellt; und
• Fig. 31 eine Entscheidungstabelle einer tabellarischen Zusammenfassung der Umwandlung in das L3-Steuerzeichen EU zeigt.
Beschreibung des bevorzugten Ausführungsbeispiels
• In der hier verwendeten Form bezeichnet "Umwandlungsmechanismus" eine Ansammlung von Software und Hardware, die zusammen genommen eine "State Machine" darstellt, die ihre Eingaben einem Quelldokumentformat entnimmt und diese Eingaben gemäß vordefinierter Statusübergangsdiagramme und -tabellen in ein ganz bestimmtes Zieldokumentformat umwandelt. Sowohl das Quell- als auch das Zielformat des Dokuments sind zwar vollständig editierbar, aber untereinander inkompatibel, was das Bedürfnis nach einer Umwandlung begründet. Darüber hinaus bezeichnen die Begriffe "DCF- Dokumentenformat" und "L3-Dokumentenformat" zwei Datenströme, die editierbare Formate oder Versionen eines bestimmten Dokuments, so wie es auf der Platte eines Benutzers oder bei der Übertragung zwischen zwei Textverarbeitungssystemen vorliegt, darstellen. Ein Eingabeobjekt in einem Quelldokument bedeutet entweder ein Textzeichen oder ein Steuerzeichenfolge.
• Wie bereits erwähnt, werden mehrere verschiedene und untereinander inkompatible Formate zur Darstellung editierbarer Dokumente benutzt. Aufgrund der systembedingten Unterschiede zwischen den Formaten ist es jedoch nicht leicht möglich, zu Editierzwecken Datenströme aus editierbaren Dokumenten von einer Textverarbeitung zur anderen zu übertragen, auch wenn sich dabei wichtige Vorteile ergäben. Selbst bei einer kleineren DV-Anlage machen die typische Mischung aus untereinander inkompatiblen Textverarbeitungssystemen und deren Anschaffungskosten eine derartige Umwandlungseinrichtung wichtig. Es wäre besonders vorteilhaft, wenn man ein Dokument von einem ersten Textverarbeitungssystem zu einem zweiten und wieder zurück oder sogar zu einer dritten oder vierten Textverarbeitung so oft wie nötig übertragen könnte, um das Erstellen und vollständige Editieren des Dokuments zu erreichen, ohne sich um die Inkompatibilität der entsprechenden Dokumentenformate kümmern zu müssen.
• Die Zahl der Vorgesetzten, die für viele Aufgaben - insbesondere für Textverarbeitung - Datenverarbeitungsstationen wie die der 3270-Reihe der IBM Corporation einsetzen, ist groß und nimmt weiter zu. Eine entsprechende Anzahl von Sekretärinnen verwendet zur Textverarbeitung Displaywriter (DW). Wenn man DW-Stationen mit zentralen Datenverarbeitungssystemen verbindet, können Vorgesetzte und Sekretärinnen gemeinsam Textdokumente erstellen, editieren und verteilen. Diese Verbindung muß eine Einrichtung enthalten, die das Format, in dem Datenverarbeitungssysteme Dokumente darstellen, in das Format, in dem DW Dokumente darstellt, umwandeln kann. Wie später noch erklärt werden wird, ist diese Umwandlung äußerst schwierig, da sie nicht Zeichen für Zeichen durchgeführt werden kann.
• Das von Displaywriter (DW) der IBM Corporation verwendete Format ist OIIA L3 oder Office Interchange Architecture Level 3, eine Bezeichnung der IBM Corporation, ein bereits zuvor erwähntes Datenstromformat für Dokumente. Es wird ab hier als L3 bezeichnet. DCF oder Document Composition Facility, eine weitere Bezeichnung der IBM Corporation, ist ein zweites Datenstromformat für Dokumente und wurde ebenfalls bereits zuvor erwähnt. Dieses Format wird beispielsweise in einer VM-Umgebung auf einer DV-Anlage IBM Corporation System/370 mittels SCRIPT/VS zur Darstellung editierbarer Dokumente verwendet.
• Fig. 1 zeigt eine mögliche Anordnung, die zur Verbindung eines Zentralrechners - ein in einer VM-Umgebung arbeitender System/370 - mit einem eigenständigen Displaywriter (DW) verwendet werden kann. Typischerweise besitzt der Vorgesetzte eine an den Zentralrechner angeschlossene Datenstation mit Bildschirm 20 und Tastatur 22. In dieser Beispielkonstellation besitzt der Vorgesetzte auch andere Systemeinrichtungen wie eine Platte 24, einen Editor 26 und in diesem Fall einen auf DCF (SCRIPT/VS) basierendes Formatierungsprogramm 28. Durch das Spoolen auf den Systemdrucker 30 können Hardcopys erstellt werden. Falls es erforderlich wird, kann der Vorgesetzte außerdem auf die Systembibliothek 32 zugreifen und beliebige benötigte Dateien auf die Benutzerplatte 24 übertragen. Die Bibliothek 32 steht dem Vorgesetzten zur Archivierung im Speicher zur Verfügung. Der Vorgesetzte erstellt oder editiert normalerweise ein Dokument durch Kommunikation über den Bildschirm 20 und die Tastatur 22 und verwendet dabei, wenn nötig, beliebige zusätzliche Hilfsmittel.
• Die Sekretärin dagegen verwendet zum Erstellen und Editieren von Texten oder Dokumenten einen Displaywriter. DW besitzt einen eigenen Bildschirm 34 und eine eigene Tastatur 36. Es ist sehr leicht zu bedienen, da man auf dem Bildschirm sieht, was man hinterher auf dem Drucker erhält. Die Einrichtung für die Umwandlung von DCF in L3 gestattet Sekretärinnen und Vorgesetzen, ihre jeweiligen Einrichtungen zur Textverarbeitung und zum Editieren vollkommen gemeinsam zu verwenden. Eine Sekretärin kann vom Vorgesetzten eingegebene oder editierte Dokumente einsehen und editieren. Die entsprechende Umwandlung von L3 in DCF, die jedoch ganz andere Verfahren verwendet, sowie eine Vorrichtung, die dem Zentralrechner die Kontrolle über die DW- Diskettendateien gibt, ermöglicht es, daß der Vorgesetzte von der Sekretärin eingegebene und editierte Dokumente einsehen und editieren kann. Bezüglich der Übertragung von Dokumenten und der Umwandlung von Dokumentendateien bezeichnet "HOCH" eine Übertragung von L3 nach DCF und "HERUNTER" steht für eine Übertragung von DCF nach L3. Der Begriff "hochladen" gibt an, daß der Datentransfer von DW zum Zentralrechner stattfindet. Der Begriff "herunterladen" gibt an, daß der Datentransfer vom Zentralrechner an DW erfolgt. Weitere Einzelheiten der Umwandlung von L3 nach DCF und der Vorrichtung, die dem Zentralrechner Kontrolle über die DW-Diskette gibt, finden sich in den mitanhängigen europäischen Patentanmeldungen 83111221.4 und 83111223.0.
• Sowohl L3 als auch DCF sind editierbare Dokumentenformate. Ungefähr an dieser Stelle enden aber auch ihre Gemeinsamkeiten. Beide können in etwa die gleichen Textformatierungen darstellen, wie z. B. Zeilenende, Absatzende, Größe des Einzugs, Ende eines Einzugs, Seitenende, Anfang bzw. Ende von doppeltem Zeilenabstand oder Anfang bzw. Ende der Formatierung. Es gibt aber keinen Fall, in dem ein Steuerzeichen, das irgendeinen gegebenen Satz aus einer oder mehrerer dieser Formatierungen im DCF-Format darstellt, mit einem Steuerzeichen übereinstimmt, das den gleichen Satz von Formatierungen im L3-Format darstellt.
• Beispielsweise schließt das Steuerzeichen "BREAK" (Umbruch) in DCF, das als ".BR" geschrieben wird, einen Absatz ab. Das heißt, es verhindert, daß das DCF-Formatierungsprogramm nachfolgenden Text an den Text davor hängt und somit eine Zeile weiterführen würde. Das Steuerzeichen "Required Carrier Return" oder RCR (unveränderliche Zeilenschaltung) in L3, das im Datenstrom als der nichtdruckbare hexadezimale Wert > 06< erscheint, schließt auch einen Absatz ab, indem es die Verkettung unterbricht. Das Steuerzeichen RCR bewirkt jedoch noch andere Dinge. RCR beendet auch einen Einzug, d. h. es setzt den temporären linken Rand auf den permanenten linken Rand zurück. Dann verschiebt es die aktuelle Position auf diese permanente Position in der nächsten Zeile. Beispielsweise lassen vier RCRs zwischen zwei Textzeichenketten drei Leerzeilen zwischen den Textzeilen, während vier ".BRs" zwischen zwei Textzeichenketten gar keine Leerzeilen lassen.
• Ein weiteres Beispiel ist das Steuerzeichen "Tab" (Tabulator) in DCF, das als ".TB a b c . . . " geschrieben wird und an den angegebenen Zeichenpositionen a, b, c usw. Tabulatorstops setzt. Das übliche Verfahren, um in L3 Tabulatoren zu setzen, verwendet die vier "Mehrbyte"-Steuerzeichen "Begin Line Format Change" (Anfang der Zeilenformatänderung), "Set Line Parameters" (Zeilenparameter setzen), "Set Tabs" (Tabulatoren setzen) und "End Line Format Change" (Ende der Zeilenformatänderung). Jedes besitzt einen eigenen nichtdruckbaren hexadezimalen Wert im L3-Datenstrom. Keines kann ohne die anderen drei im Datenstrom vorliegen. Die vier Mehrbyte-Steuerzeichen in der Abfolge "Set Line Parameters" (Zeilenparameter setzen) umfassen zusammen über 30 Byte und müssen auch noch andere Informationen wie Zeichenbreite, linker und rechter Rand, Zeilenabstand, Justierung und Ausrichtung enthalten. Es sind keine Standardeinstellungen möglich, und bei keiner dieser Informationen besteht die Möglichkeit, zu sagen "lasse den bestehenden Wert unverändert".
• Als drittes Beispiel kann das DCF-Steuerzeichen ".IN h" den Einzug an einer beliebigen horizontalen Zeichenposition "h" angeben, die links oder rechts von der vorherigen Einzugsposition sein kann. In L3 dagegen sind alle Einzüge mit Tabulatorstopppositionen verknüpft. Außerdem besteht die einzige Möglichkeit, den Einzug zu vergrößern, darin, den temporären linken Rand mittels des Einzugtabulators (indent tab, IT) um eine Tabulatorposition nach rechts zu verschieben. Die einzige Möglichkeit, den Einzug zu verringern, besteht darin, zunächst eines der verschiedenen verfügbaren Steuerzeichen wie z. B. Required Carrier Return (unveränderliche Zeilenschaltung) zu benutzen, das den temporären linken Rand ganz nach links bis zum permanenten linken Rand zurücksetzt. Die Umwandlung von DCF in L3 ist daher schwierig, da die beiden Formate die gleiche Information auf so unterschiedliche Weise darstellen. Die Schwierigkeit dieser Umwandlung ist mit einem noch grundlegenderen Grund verknüpft.
• Mit Ausnahme einiger weniger trivialer und spezieller Fälle, kann ein DCF-Objekt, nur für sich allein, nicht in eines oder mehrere L3-Objekte umgewandelt werden, ohne dabei die es umgebenden anderen DCF-Objekte zu berücksichtigen. Beispielsweise muß ein End Of Record (EOR, Ende des Datensatzes) zwischen zwei Textdatensätzen in ein Carrier Return (CRE, Zeilenschaltung) umgewandelt werden. Dagegen muß das Paar aus EOR und einem ".IN 0"-Steuerzeichen, das den Einzug zurücksetzt, in ein Required Carrier Return (RCR, unveränderliche Zeilenschaltung) umgewandelt werden. Es wäre falsch, das EOR in ein CRE und dann das ".IN 0" in ein RCR umzuwandeln, da dies im Text eine falsche Leerzeile zurückläßt. Außerdem muß das Tripel aus EOR, einem ".IN 0"-Steuerzeichen und einem ".PA"-Steuerzeichen, das eine neue Seite beginnt, in das Steuerzeichen Page End (PE, Seitenende) sowie in null oder mehr Steuerzeichen Indent Tab (IT) umgewandelt werden, um das vorhergehende Einzugsmaß wiederherzustellen. Dagegen beendet das Paar aus den DCF-Steuerzeichen ".PA" und ".IN 0" zusammen - egal in welcher Reihenfolge - die Seite und setzt auch den Einzug zurück. Daher können beide in ein einziges L3-Objekt Required Page End (RPE, unveränderliches Seitenende) umgewandelt werden. Es wäre ein Fehler, das ".PA" in ein RPE und ein paar ITs umzuwandeln und dann zu versuchen, das ".IN 0" in etwas umzuwandeln, das den Einzug zurücksetzt. In L3 gibt es nichts, das den Einzug zurücksetzen kann, ohne dabei eine falsche Leerzeile zu hinterlassen.
• In anderen Fällen wäre es zwar nicht falsch, ein DCF-Objekt umzuwandeln, ohne dabei den Kontext des Objekts zu berücksichtigen, aber dies wäre sehr ungeschickt. Die Befehlsfolge Line Format Change (LFC, Zeilenformatänderung) aus Mehrbyte- Steuerzeichen kann in L3 die Funktion von mindestens vier DCF- Steuerzeichen wie z. B. den folgenden besitzen:
• .FO OFF Schaltet die Formatierung aus
• IN 0 Kein Einzug
• .TB 5 10 15 20 25 Setzt ein Tabulatorgitter
• .DS Schaltet doppelten Zeilenabstand ein
• Es wäre zwar möglich, eine Befehlsfolge aus vier dieser DCF- Steuerzeichen in vier einzelne LFC-Befehlsfolgen umzuwandeln. Es ist jedoch vielmehr vorzuziehen, die vier DCF-Steuerzeichen in einer Gruppe zusammenzufassen und die ganze Gruppe in eine einzige LFC-Befehlsfolge umzuwandeln.
• Aus diesem Grund ist es erforderlich, daß bei der Umwandlung eines DCF-Dokuments in ein gleichwertiges L3-Dokument Muster im DCF-Dokument erkannt werden. Die Anzahl möglicher Muster ist astronomisch hoch. Die Anzahl der Befehlsfolgen, die jeweils die 17 gebräuchlichsten DCF-Steuerzeichen enthalten, d. h. die Anzahl der Permutationen von X aus X Gegenständen übertrifft die Anzahl der Sekunden des Alters des Universums etwa um den Faktor 5.000. Nicht alle Befehlsfolgen sind nur 17 Zeichen lang, und nichts besagt, daß ein gegebenes DCF-Steuerzeichen nur einmal in einer Befehlsfolge vorkommt, so daß die Anzahl möglicher Befehlsfolgen insgesamt sogar noch größer als die kleinste Anzahl ist. Allein schon das bloße Erkennen jeder möglichen Befehlsfolge stellt ein Aufgabe dar, die eine Lösung mit roher Gewalt nicht zuläßt. Die Definition eines geeigneten Umwandlungsverfahrens in L3 für jede Befehlsfolge verlangt eine subtilere Vorgehensweise.
• Das hier beschriebene Umwandlungsverfahren besitzt drei Hauptteile. Der erste Teil beinhaltet das Lesen einer DCF-Steuerzeichensequenz, das Setzen entsprechender Statusbits und -werte für jedes angetroffene Steuerzeichen, das Prüfen, ob Text - der stets eine Sequenz beendet - vorliegt, und das Prüfen, ob bestimmte Kombinationen aus Steuerzeichen vorliegen, die ebenfalls am Ende einer Sequenz stehen müssen. Der Schlüssel zur Umwandlung des DCF-Formats in das L3-Format liegt im zweiten Teil des erfindungsgemäßen Verfahrens. Dieser Schlüssel ist die Erkenntnis, daß eine Reihenfolge des Satzes möglicher L3- Objekte, die möglicherweise als Umwandlungsergebnis einer beliebigen DCF-Sequenz geschrieben werden müssen, definiert werden kann. Muß ein L3-Objekt als Teil des Umwandlungsergebnisses einer beliebigen DCF-Steuerzeichensequenz geschrieben werden - egal in welcher Reihenfolge die DCF-Steuerzeichen aufgetreten sind -, dann muß dieses L3-Objekt möglicherweise an einer bestimmten Stelle relativ zu anderen zu schreibenden L3- Objekten geschrieben werden. Der dritte Teil des Verfahrens beinhaltet das Verwenden der Statusbits und -werte, die das darstellen, was in einer abgeschlossenen Sequenz vorlag, sowie das Schreiben der entsprechenden umgewandelten L3-Objekte. Die Entscheidungen darüber, ob das jeweilige mögliche Objekt geschrieben wird oder nicht, werden in der Reihenfolge, die im zweiten Teil des Umwandlungsverfahrens ermittelt worden ist, getroffen. Daher besteht der dritte Teil der Umwandlung darin, einen großen Satz von Entscheidungstabellen in einer sorgfältig gewählten, aber festen Reihenfolge zu verwenden. Jede Entscheidungstabelle bestimmt darüber, ob ein gegebenes L3-Objekt geschrieben wird oder nicht.
• Die folgende Beschreibung des bevorzugten Ausführungsbeispiels der vorliegenden Erfindung enthält die Einzelheiten der drei Hauptteile des hier offenbarten Umwandlungsverfahrens. Der erste Teil der Beschreibung stellt die Einzelheiten der Verarbeitung vor, die beim Lesen der DCF-Steuerzeichen, die eine gegebene Sequenz ausmachen, erfolgen. In diesem ersten Teil werden die entsprechenden Statusbits und -variablen gesetzt. Der zweite Teil dieser Beschreibung gibt Auskunft über die Reihenfolge der L3-Objekte, die als Umwandlungsergebnis einer beliebigen Befehlssequenz von DCF-Steuerzeichen möglicherweise zu schreiben sind. Die Reihenfolge ist unabhängig davon, welche Steuerzeichen die Sequenz enthielt. Der dritte und letzte Teil dieser Beschreibung gibt Einzelheiten über das Wesen der Verarbeitung, die stattfindet, wenn das Ende einer gegebenen Sequenz erreicht wird. Dazu gehört die Entscheidung, ob die jeweiligen L3-Objekte als Umwandlungsergebnis dieser gegebenen Sequenz geschrieben werden oder nicht, was von den Statusbits und -variablen, die beim Lesen der Sequenz gesetzt worden sind, abhängt.
• Die Bits und Werte, die beim Lesen einer Befehlssequenz von DCF- Steuerzeichen gesetzt werden, werden in der Tabelle in Fig. 2 gezeigt. Mehrere dieser Statusvariablen wie z. B. "VALTP" besitzen entsprechende ständige Statusvariablen wie z. B. "CURTP". Die Verarbeitung, die beim Lesen einer DCF-Steuerzeichensequenz stattfindet, besteht im Setzen und manchmal auch im Rücksetzen der obigen Statusbits und -variablen, wie dies die Fig. 3A bis 3C zeigen.
• Es folgt nun die Reihenfolge der b3-Objekte, die als Teil der Umwandlung einer gegebenen Befehlssequenz von DCF-Steuerzeichen möglicherweise zu schreiben sind oder nicht. Das bedeutet, der zweite Teil dieses Umwandlungsverfahrens besteht darin, diese jeweiligen Objekte in der Reihenfolge der Tabelle in Fig. 4 zu schreiben oder nicht.
• Die obige Reihenfolge ist alles andere als willkürlich. Sie ist der Schlüssel des Umwandlungsverfahrens. Sie beruht auf den Daten der Tabellen in Fig. 5 bis 7 und deren zugehörigen Erklärungen. In jeder Regel oder Tabellenspalte muß ein mit "1" markiertes Objekt vor einem mit einer "2" markierten Objekt stehen. Die Objekte sind so sortiert, daß in allen Regeln die Zahlen nur nach unten zunehmen.
• Im folgenden wird eine Erklärung der in Fig. 5 bis 7 gezeigten Entscheidungstabellen für die Reihenfolge der Objekte gegeben. Die Nummer der "Regel" steht dabei vor dem jeweiligen erklärenden Kommentar.
• 1. Ein ZICR (Zero Index Carriage Return, Zeilenanfang ohne Zeilenschaltung) wird nur mit CRE zusammen benutzt, um einen Absatz zu beenden, d. h. die Zeilenjustierung wird unterbrochen und die Justierung der vorhergehenden Zeile wird verhindert, oder es wird zusammen mit LFC benutzt, um zu erzwingen, daß die Änderungen sofort wirksam werden und nicht erst in der nächsten Zeile. Wenn also CRE und ZICR bzw. LFC und ZICR vorliegen, dann in dieser Reihenfolge. Beide Zwecke benötigen kein ZICR, da ein LFC einen Absatz beendet.
• 2. Leerzeilen, die als Teil der Umwandlung einer DCF-Steuerzeichensequenz, die eine Seite beendet, erzeugt werden, werden stets der zu Ende gehenden Seite zugeordnet. Eventuelle Leerzeilen auf der folgenden Seite müssen die Steuerzeichensequenz abschließen, da eine einzelne Leerzeile nicht die gesamte Bedeutung der Befehlsfolge wiedergeben kann.
• 3. Eine gegebene Sequenz erzeugt möglicherweise aus einem ".PA"-Steuerzeichen bzw. einem PE-Byte sowohl ein RPE als auch ein PE, allerdings nur in dieser Reihenfolge. Die andere Reihenfolge ergibt eine leere Seite und würde die DCF-Steuerzeichensequenz vor dem Steuerzeichen ".PA" beenden.
• 4. Die L3-Syntaxregeln verlangen, daß einem PE ein TUP folgt.
• 5. Die L3-Syntaxregeln verlangen, daß einem TUP ein TUFC folgt.
• 6. Die L3-Syntaxregeln verlangen, daß einem TUFC ein MP folgt.
• 7. Die L3-Syntaxregeln verlangen, daß einem MP ein MT folgt.
• Dabei ist zu beachten, daß sowohl Text am oberen Rand als auch Text am unteren Rand in einer gegebenen Steuerzeichensequenz auftreten können. Treten beide auf, müssen MP und MT des Textes am oberen Rand (Kopfzeile) vor MP und MT des Textes am unteren Rand (Fußzeile) stehen.
• 8. Die L3-Syntaxregeln verlangen, daß einem TUP ein BT folgt. Es wird jedoch kein zusätzlicher Algorithmus benötigt, um zu entscheiden, ob ein BT geschrieben wird oder nicht, da ein TUP ein anschließendes BT bedingt.
• 9. Ein End UnderScore (Ende Unterstreichen), sofern vorhanden, muß vor den Leerzeichen stehen, die ein Align Text Field (Textausrichtungsfeld) positionieren, um das Unterstreichen dieser Leerzeichen zu vermeiden.
• 10. Ein eventuelles End UnderScore (Ende Unterstreichen) muß vor Leerzeichen im durch INDENT TAB erzeugten Datenstrom stehen, um das Unterstreichen dieser Leerzeichen zu vermeiden.
• 11. Ein eventuelles Begin UnderScore (Anfang Unterstreichen) muß nach den 33 Leerzeichen, die ein Align Text Field (Textausrichtungsfeld) positionieren, und der Einfachkeit halber daher nach dem ATF selbst stehen, um das Unterstreichen dieser Leerzeichen zu vermeiden.
• 12. Ein eventuelles Begin UnderScore (Anfang Unterstreichen) muß nach Leerzeichen im durch INDEX TAB erzeugten Datenstrom stehen, um das Unterstreichen dieser Leerzeichen zu vermeiden.
• 13. Ein eventueller Indent Tab (Einzugtabulator), der dazu verwendet wird, den Einzug zu vergrößern, indem der temporäre linke nach rechts verschoben wird, muß nach sämtlichen L3- Steuerzeichen stehen, die den temporären linken Rand auf den permanenten linken Rand zurücksetzen.
• 14. Ein eventueller Indent Tab (Einzugtabulator) im letzten Datensatz, der als Teil einer Befehlssequenz von DCF-Steuerzeichen, die ein ".CE"-Steuerzeichen enthalten, verarbeitet worden ist, muß als erster Teil des zu zentrierenden Textes nach dem ATF stehen.
• 15. Bei einem End Of File (Dateiende) im DCF-Dokument muß das aktuelle BT mit einem PE beendet und ein End Unit, d. h. ein End Unit Prefix und ein neuer, nur ein Page End (Seitenende) enthaltender Body Text (Haupttextteil) geschrieben werden.
• 16. Diese Regel bleibt unabsichtlich leer.
• 17. Wenn RCR CRE aufhebt, muß RCR vor dem ersten RSP in einer Sequenz aus einem oder mehreren Paaren aus RSP-CRE stehen, die eine oder mehrere erforderliche Leerzeilen ergeben. Sonst ginge das erste RSP ans Ende einer Textzeile anstatt an den Anfang seiner eigenen erforderlichen Leerzeile.
• 18. Wenn RPE CRE aufhebt, muß das RPE vor einem LFC - sofern vorhanden - stehen, so daß das LFC nach einem gültigen, die Zeile beendenden Steuerzeichen aus einem Byte steht.
• Eine gewisse Ordnung wird durch Beziehungen der Form "jedesmal, wenn Objekt A geschrieben wird, muß auch irgendwann Objekt B geschrieben werden" zwischen den Objekten bewirkt. Die Tabelle in Fig. 8 gibt eine solche Beziehung als Spalte wieder, in der A ein "Y" (was Ja bedeutet) und B ein "-Y" (was ein bedingtes Ja bedeutet) hat. Dies ist eine Entscheidungstabelle für Beziehungen zwischen den Ausgabeobjekten. Die Nummer der "Regel" steht vor dem jeweiligen erklärenden Kommentar.
• 1. Ein Text Unit Format Change kann nur zu Beginn einer neuen logischen Seite stehen, so daß TUFC Page End, Text Unit Prefix und Body Text bedingt.
• 2. Margin Text kann sich nur zu Beginn einer neuen logischen Seite ändern, auf der es ein Text Unit Format Change gibt, so daß Margin Text Parameters Page End, Text Unit Prefix, TUFC, Margin Text, von dem man gleichermaßen sagen könnte, daß es Margin Text Parameters und den Rest bedingt, und BT bedingt. Dabei ist zu beachten, daß es sich beim Vorliegen von Texten am oberen und unteren Rand um unabhängige Entscheidungen handelt.
• In der sortierten Liste steht PE vor TUFC und MP, allerdings bedingen entweder TUFC oder MP die Notwendigkeit eines PE. Zudem steht TUFC vor MP, allerdings bedingt MP die Notwendigkeit eines TUFC.
• Die in Fig. 9 bis 31 gezeigten Entscheidungstabellen und die zugehörigen Erklärungen geben für jeden möglichen Status der beim Lesen einer DCF-Steuerzeichenfolge gesetzten Variablen an, ob die möglichen L3-Objekte geschrieben werden oder nicht. Jede Tabelle gibt an, ob das entsprechende Objekt geschrieben wird oder nicht. Jede Spalte in den Tabellen ist eine "Regel", d. h. eine Bedingung, unter der das betreffende Objekt geschrieben werden muß. In der Regel können am Ende des Lesens einer gegebenen DCF-Steuerzeichensequenz keine, eine, ein paar oder sogar alle Regeln zutreffen. Das Objekt muß geschrieben werden, wenn irgendeine oder mehrere der Regeln einer Entscheidungstabelle "erfüllt" sind. Eine Regel ist dann erfüllt, wenn jede der in dieser Spalte mit einem "Y" markierten Variablen ungleich null ist und wenn jede mit einem "N" markierte Variable null ist.
• Am Ende einer DCF-Steuerzeichensequenz sind die Bits und Werte so gesetzt, daß sie den Inhalt der Sequenz angeben. Der übrige Teil des Umwandlungsverfahrens besteht darin, die Entscheidungstabellen in einer festgelegten Reihenfolge anzuwenden, um zu entscheiden, ob das jeweilige mögliche L3-Objekt geschrieben wird oder nicht. Jede Entscheidungstabelle gilt für ein L3- Objekt. Dieses L3-Objekt muß geschrieben werden, wenn irgendeine Regel (Spalte) der entsprechenden Entscheidungstabelle erfüllt ist, d. h. "Y"s und ,'N"s hat, die mit den aktuellen Werten der Variablen übereinstimmen.
• Fig. 9A und 9B zeigen die Entscheidungstabelle für CRE (Zeilenschaltung). Carrier REturn oder CRE dient dazu, die aktuelle Position des nächsten Zeichens so zu verschieben, daß es am temporären linken Rand der nächsten Zeile gedruckt wird. In einer DCF-Steuerzeichensequenz kann es viele Eingabeobjekte geben, die es erfordern, daß DOWN (herunter) ein CRE in den L3- Datenstrom schreibt, da DOWN (herunter) die Umwandlung einer angeschlossenen DCF-Steuerzeichensequenz einleitet. Die Hierarchie dieser DCF-Objekte ist wie folgt:
• a) Ein DCF-Eingabeobjekt wird direkt in ein CRE umgewandelt, sofern es nicht durch ein RCR oder RPE aufgehoben ist:
• - EOR
• b) Ein DCF-Eingabeobjekt wird direkt in die Kombination CRE ZICR umgewandelt, die mit CRE beginnt, sofern die Kombination nicht durch ein RCR oder RPE aufgehoben ist:
• - alle Steuerzeichen, die einen Umbruch bewirken
• c) Einige DCF-Eingabeobjekte werden in L3-Ausgabeobjekte umgewandelt, die nach einem Zeilenende-Steuerzeichen und somit nach einem CRE stehen müssen, sofern das CRE nicht durch ein RCR oder RPE aufgehoben ist:
• - .FO, .JU, .TB, .SS oder .DS, das in ein LFC umgewandelt wird, sofern nicht etwas anderes ein TUFC benötigt
• d) Einige DCF-Eingabeobjekte werden in L3-Ausgabeobjekte umgewandelt, die nach einem PE stehen müssen, welches wiederum nach einem Zeilenende-Steuerzeichen und somit nach einem CRE stehen muß, sofern das CRE nicht durch ein RCR oder RPE aufgehoben ist:
• - . RH wird in TUFC umgewandelt
• - . RF wird in TUFC umgewandelt
• - . CM DRAWER wird in TUFC umgewandelt
• - . EOF wird in EU umgewandelt
• Um es nochmals zu sagen: die folgenden DCF-Eingabeobjekte werden in L3-Ausgabeobjekte umgewandelt, die mit CRE beginnen, sofern kein RCR von .IN h mit h < CURINC oder RPE von .PA das CRE aufheben. Mit Regel 1 wird EOR in CRE umgewandelt. Mit Regel 2 werden sämtliche Steuerzeichen, die einen Umbruch verursachen, in CRE ZICR umgewandelt, wenn es kein anderes Umbruch-Steuerzeichen gibt. Mit Regel 3 wird das PE-Byte in CRE PE umgewandelt. Bei den Regeln 4, 5 und 6 werden die Eingabeobjekte .FO, .JU, .TB, .55 und .DS in CRE LFC oder sonst in CRE PE TUP TUFC, eventuell MP MT, und BT umgewandelt. Die Regeln 7, 8 und 9 wandeln die DCF-Eingabeobjekte .RH, .RF und CM DRAWER in CRE PE TUP TUFC, eventuell MP MT, und BT um. Schließlich besagt Regel 10, daß EOF in CRE PE EU, das heißt, in CRE PE EUP CRE und PE umgewandelt wird.
• Dies ergibt 10 Regeln in der Entscheidungstabelle. Scheinbar läßt sie mehrere Steuerzeichen aus, nämlich .SK, .SP und .CE, die ganz klar von einem CRE aufgebaut werden müssen. Tatsächlich sind diese Steuerzeichen alle in Regel 2 enthalten, da jede von ihnen ein BREAK (Umbruch) bewirkt und somit GOTBR (Umbruch vorhanden) setzt. Es ist zu beachten, daß sich die Regeln für das Schreiben eines CRE keineswegs gegenseitig ausschließen. Die Anzahl von Umbruchsituationen, die ein CRE erfordern, beträgt mindestens 211. In einer gegebenen Sequenz, die zu Beginn ihrer Umwandlung in L3 ein CRE erfordert, können mindestens elf verschiedene DCF-Steuerzeichen vorkommen oder auch nicht. Die Fig. 9A und 9B zeigen die Entscheidungstabelle für CRE.
• Ein Required Carrier Return (unveränderliche Zeilenschaltung) oder RCR wird in zwei Fällen zum Aufheben des Einzugs verwendet, das heißt, um den temporären linken Rand zurück auf den permanenten linken Rand zu verschieben. Der erste Fall tritt auf, wenn im letzten ".IN h"-Steuerzeichen einer Sequenz h=0 ist, was das Aufheben des Einzugs angibt, das heißt, wenn CNTINC null ist. Der zweite Fall tritt auf, wenn im letzten "IN h"-Steuerzeichen einer Sequenz h kleiner als der aktuelle temporäre linke Rand ist, das heißt, wenn CNTINC kleiner (less than, abgekürzt als LT) als CURINC ist.
• Der letztgenannte Fall ist ein notwendiger, vorausgehender Schritt bei der Umwandlung eines DCF-Steuerzeichens, das den temporären linken Rand zwar nach links, aber nicht ganz bis zum permanenten linken Rand verschiebt. Das vorausgehende RCR (unveränderliche Zeilenschaltung) verschiebt ihn zuerst ganz nach links, und dann verschieben ihn ein oder mehrere Indent Tabs (Einzugtabulatoren) an die gewünschte Position. L3 hat kein Steuerzeichen Unindent Tab (Rücksetzen des Einzugstabulators); daher wird statt dessen die Befehlsfolge RCR ITs verwendet. Es ist zu beachten, daß der erstgenannte Fall eine Untermenge des zweiten Falls ist. Daher erfordert die Bedingung CNTINC LT CURINC (d. h. CNTINC < CURINC) in beiden Fällen das Rücksetzen des Einzugs.
• In L3 ist RCR jedoch nicht das einzige Steuerzeichen, das den Einzug zurücksetzt. Die anderen sind: IRT, das gleichwertig mit RCR ist und das DOWN (herunter) nie schreibt; RPE, das DOWN als Reaktion auf das Steuerzeichen ".PA" schreibt; LFC, das DOWN manchmal als Reaktion auf ".FO", ".JU", ".SS", ".DS" oder ".TB" schreibt; RMLF, APM, AAM und RTMF, die DOWN nie schreibt, da dies das Erkennen eines komplexen Musters erfordern würde; und
• TUFC, das DOWN als Reaktion zur Bearbeitung von ".FO", "JU", ".SS", ".DS" oder ".TB" schreibt.
• Wenn eine Abfolge von DCF-Steuerzeichen Steuerzeichen enthält, die in Ausgabeobjekte umgewandelt werden, welche den Einzug rücksetzen, dann schreibt DOWN kein RCR. Dies ist insbesondere dann erforderlich, wenn eine Sequenz ein ".IN 0" und ein ".PA" enthält. Schriebe DOWN sowohl ein RCR als auch ein RPE, so hinterließe dies unrichtigerweise eine zusätzliche Leerzeile. DCF- Steuerzeichen erzeugen niemals eine Leerzeile. Dagegen erzeugen beide entsprechenden L3-Steuerzeichen - sofern sie nach einem Zeilenende-Steuerzeichen auftreten - eine Leerzeile. Deshalb müssen beide L3-Steuerzeichen das anfängliche CRE aufheben. Das Schreiben aller drei - CRE, RCR und RPE - würde zwei unrichtige Leerzeilen lassen.
• Analog schreibt DOWN kein RCR, wenn es eine Befehlsfolge von DCF-Steuerzeichen umwandelt, die entweder die Erzeugung eines LFC oder die Erzeugung eines TUFC erfordert. In diesen Fällen wäre das Schreiben eines RCR anstelle des einzelnen CRE am Anfang lediglich überflüssig, aber nicht falsch. Die einzige lebensfähige Regel in der Entscheidungstabelle für RCR - siehe Fig. 10 - besagt, daß DOWN ein RCR schreibt, wenn eine DCF- steuerzeichenfolge befiehlt, den temporären linken Rand nach links zu schieben, aber nicht andere Dinge befiehlt, die den Einzug rücksetzen würden.
• CREs steht für ein oder mehrere Ein-Byte-Steuerzeichen Carrier Return (Zeilenschaltung), die dazu verwendet werden, das DCF- Steuerzeichen ".SK v" in Leerzeilen in L3 umzuwandeln. Die Entscheidungstabelle für dieses DCF-Eingabeobjekt befindet sich in Fig. 11. Die Zahl der CREs ist CNTBL, die Summe alle Parameter (v) in allen ".SK v"-Steuerzeichen in der gerade beendeten Sequenz. Ist CNTBL null, wird kein CRE-Steuerzeichen geschrieben, und die obige Entscheidungstabelle ist nicht erfüllt. Dies ist die Bedeutung von "Y" (JA) in der Reihe, die den Namen einer Statusvariablen enthält. Es ist zu beachten, daß das Steuerzeichen ".SK 0" allein keine Leerzeilen zurückläßt, aber einen Umbruch bewirkt. Wenn es zudem auf das Steuerzeichen ".PA NOSTART" folgt, beginnt ".SK 0" eine neue Seite. Dies liegt an anderen Bits, die gesetzt werden, wenn ".SK" in einer Sequenz vorkommt. Die Variable CNTBL muß am Ende der Verarbeitung der Steuerzeichenfolge auf Null zurückgesetzt werden.
• Es ist zu beachten, daß ein ".PA" in der Sequenz ein RPE erfordert, das Vorrang vor dem Schreiben eines einzelnen CREs hat. Beispielsweise wird die DCF-Sequenz
• TEXT1 EOR
• .SK 3 EOR
• .PA EOR
• TEXT2
• in L3 umgewandelt in
• TEXT1 CRE CRE CRE RPE TEXT2,
• wobei alle drei CREs von ".SK 3" stammen. Das erste CRE beendet nur die aus TEXT1 bestehende Zeile. Die beiden nächsten CREs bewirken Leerzeilen. Das RPE verursacht die dritte Leerzeile. Es ist zu beachten, daß DOWN Null-DCF-Datensätze, d. h. aufeinanderfolgende EORs (End Of Record = Ende des Datensatzes), nicht beachtet. DOWN stellt keinen Null-Datensatz fest und erhöht auch nicht die Zahl der Leerzeilen.
• Die Entscheidungstabelle für (RSP CRE)s ist in Fig. 12 abgebildet. (RSP CRE)s bedeutet ein oder mehrere Paare aus Required Space (unveränderliches Leerzeichen) und Carrier Return (Zeilenschaltung), die verwendet werden, um ".SP v"-Steuerzeichen in unveränderliche Leerzeilen umzuwandeln, die am Anfang oder Ende einer Seite nicht gelöscht werden können. Dies ist nicht mit den "bedingten" Leerzeilen durch das Steuerzeichen ".SK v", zu verwechseln. CNTRBL enthält die Anzahl der Paare aus RSP und CRE, d. h. die Summe der Parameter (v) in allen ".SP v"-Steuerzeichen in der gerade beendeten Sequenz. Ist CNTRBL null, so werden keine Paare geschrieben, aber die anderen Funktionen von ".SP 0" werden so ausgeführt, wie dies für CREs beschrieben worden ist. Die transiente Statusvariable CNTRBL muß am Ende der Umwandlung der DCF-Steuerzeichenfolge in L3 auf Null zurückgesetzt werden.
• (CRE RSP)s bedeutet die gleiche Art von Steuerzeichen-Paaren wie die vorige Ausgabe, allerdings in umgekehrter Reihenfolge. Die Entscheidungstabelle für diese DCF-Eingabeobjekte ist in Fig. 13 wiedergegeben. Wie zu erkennen war, gibt es Situationen, in denen das erste einzelne CRE nicht geschrieben wird, weil ein ".PA" in der DCF-Sequenz das Schreiben eines RPE in den L3- Datenstrom verlangt. In dieser Situation ist es falsch, die durch CNTRBL gegebene Anzahl von Paaren aus RSP und CRE zu schreiben. Das erste RSP ginge ans Ende einer Textzeile anstatt an den Anfang einer Leerzeile. Beispielsweise würde die DCF- Sequenz
• TEXT1 EOR
• .SP 3 EOR
• TEXT2
• in L3 in
• TEXT1 RSP CRE RSP CRE RSP CRE RPE TEXT2
• umgewandelt werden, das eine Leerzeile ausläßt und eine Textzeile verlängert.
• Es wäre aber auch falsch, das RPE vor das RSP zu stellen, da dies die Leerzeilen auf die folgende Seite stellen würde. Daher muß geprüft werden, ob entweder GOTPA oder GOTPAN (oder beide) auf eins gesetzt sind, und falls dem so ist, muß das erste CRE vor dem ersten RSP geschrieben werden. Das heißt, daß DOWN in diesem Fall CRE-RSP-Paare anstelle von RSP-CRE-Paaren schreibt. Die Zahl der Paare ist wie bei der vorigen Ausgabe CNTRBL, nur die Reihenfolge ist anders. Es ist zu beachten, daß das RPE nach einem RSP die letzte unveränderliche Leerzeile bewirkt.
• DOWN schreibt als Teil der Umwandlung einer DCF-Sequenz, die ein ".US OFF"-Steuerzeichen enthält, ein aus mehreren Bytes bestehendes Steuerzeichen End Underscore (Ende Unterstreichen) in den L3-Datenstrom. Die Entscheidungstabelle für dieses spezielle L3- Ausgabeobjekt zeigt Fig. 14.
• DOWN schreibt als Teil der Umwandlung einer beliebigen DCF- Sequenz, die ein ".PA"-Steuerzeichen enthält, in L3 ein Ein- Byte-Steuerzeichen Required Page End oder RPE (unveränderliches Seitenende). Die Entscheidungstabelle für RPE ist Fig. 15 zu entnehmen. Je nachdem, ob dieses Steuerzeichen den Parameter NOBREAK enthält oder nicht, wird dies entweder durch GOTPA oder durch GOTPAN signalisiert. Es ist niemals notwendig, bei der Umwandlung einer DCF-Steuerzeichensequenz in L3 mehr als ein Ein-Byte-Steuerzeichen RPE zu schreiben. Ein zweites ".PA"-Steuerzeichen beginnt stets eine neue Sequenz.
• Die Befehlsfolge Line Format Change (Zeilenformatänderung) aus Mehrbyte-Steuerzeichen, nämlich die aus mehreren Bytes bestehenden Steuerzeichen BLFC, SLP, STAB und ELFC, wird in den L3- Datenstrom als Teil der Umwandlung einer DCF-Steuerzeichenfolge geschrieben, die eines der Steuerzeichen enthält, das entweder in ein LFC oder in ein TUFC umgewandelt werden kann, nämlich
• .FO
• .JU
• .TB
• .SS
• .DS ,
• die aber keines der DCF-Steuerzeichen enthält, die nur in ein TUFC umgewandelt werden können, nämlich
• .RH
• .RF
• .CM DRAWER
• Dies liegt daran, daß ein TUFC alle Informationen enthalten kann, die auch ein LFC enthalten kann, so daß niemals ein LUFC und ein TUFC gleichzeitig geschrieben werden müssen. Siehe die Entscheidungstabelle für LFC in Fig. 16.
• Die meisten der L3-Ausgabeobjekte kann DOWN sehr leicht schreiben, sobald eine Entscheidungstabelle DOWN mitgeteilt hat, ob sie zu schreiben sind oder nicht. Ein LFC ist nicht so einfach. Es besitzt Parameter, die von Informationen, die aus DCF-Steuerzeichen in der gerade beendeten Sequenz zusammengetragen werden, oder von unveränderten Informationen abhängen, die noch vom letzten Status stammen. Es muß insbesondere Informationen in VALADJ, VALAL, VALTP und VALSSDS verwenden. Außerdem muß DOWN in die entsprechenden ständigen Statusvariablen CURADJ, CURAL, CURTP und CURSSDS die neuen Werte einsetzen.
• DOWN schreibt aus zwei Gründen ein Ein-Byte-Steuerzeichen Zero Index Carriage Return (Zeilenanfang ohne Zeilenschaltung). Erstens - Regel 1 - beendet ein ZICR nach einem CRE einen Absatz, ohne den Einzug zurückzusetzen. Dieses Paar ist das Ergebnis der Umwandlung des DCF-Steuerzeichens BREAK (Umbruch). Zweitens - Regeln 2, 3 und 4 - stellt ein ZICR nach einem LFC sicher, daß die durch das LFC angegebenen Änderungen sofort in Kraft treten. Aus beiden Gründen-wird das ZICR nach einem Zeilenende-Steuerzeichen geschrieben. Daher verändert es in keiner Weise die aktuelle Position. Wenn es auf ein Zeilenende-Steuerzeichen folgt, dient es der Konvention, nicht der Bewegung. Die Entscheidungstabelle für ZICR ist in Fig. 17 abgebildet.
• Der erste Grund, aus dem ZICR von DOWN geschrieben wird, gilt nicht für alle Sequenzen, die ein BREAK (Umbruch) enthalten, nämlich entweder ein ".BR"-Steuerzeichen oder irgendeines der anderen 51 Steuerzeichen, die beim Aneinanderfügen von Zeilen ein BREAK (Umbruch) bewirken. Der L3 -Begriff "end of paragraph" (Absatzende) entspricht dem DCF-Begriff BREAK. Eine DCF-Steuerzeichenfolge kann andere Steuerzeichen enthalten, die in L3- Objekte umgewandelt werden, die einen Absatz beenden. Die L3- Objekte, die einen Absatz beenden, und die DCF-Steuerzeichen, die von DOWN in diese L3-Objekte umgewandelt werden, sind in der Fig. 18 gezeigten Tabelle zusammengefaßt.
• Wenn DOWN ein DCF-Steuerzeichenfolge, die irgendeines der Steuerzeichen auf der rechten Seite von Fig. 18 enthält, umwandelt, braucht DOWN kein ZICR zu schreiben, um einen Absatz zu beenden, weil das entsprechende L3-Objekt selbst einen Absatz beendet. Die Tabelle enthält alle unterstützten DCF-Steuerzeichen, die einen Umbruch bewirken, außer ".BR" selbst. Daher dient der erste Zweck von ZICR nur der Umwandlung von ".BR" und von nicht unterstützten Steuerzeichen, die einen Umbruch bewirken.
• Es ist zu beachten, daß etwa 8 Ein-Byte-Steuerzeichen in L3 alle nur dann einen Absatz beenden, wenn sie auf ein CRE oder ein PE folgen. DOWN versucht nicht, über eine DCF-Steuerzeichenfolge hinaus nach vorne zu schauen, um zu prüfen, ob die nächste Zeile mit einem dieser Ein-Byte-Steuerzeichen wie SP, RSP, BS oder sogar IT anfängt. Dies führt dazu, daß DOWN gelegentlich ein ZICR schreibt, das nicht unbedingt nötig ist. Das zusätzliche ZICR verursacht keinen Schaden und garantiert, daß ein Umbruch weiterhin in Kraft bleibt, selbst wenn ein nachfolgendes Editieren das darauffolgende Ein-Byte-Steuerzeichen, das ZICR überflüssig gemacht hatte, entfernt.
• Hinsichtlich des Beendens eines Absatzes ist zu beachten, daß sich CRE und ZICR auf eine ziemlich komplizierte Art und Weise gegenseitig beeinflussen, und daß sie in einer ziemlich komplizierten Art und Weise auch andere Eingabeobjekte beeinflussen, die DOWN möglicherweise in den L3-Datenstrom schreiben muß. Siehe dazu Regel 2 für CRE (Fig. 9A) und Regel 1 für ZICR. Regel 2 für CRE besagt, daß entweder GOTPA, das anzeigt, daß ein ".PA"-Steuerzeichens in der Sequenz vorhanden ist und in ein RPE umgewandelt wird, oder CNTINC LT CURINC, das anzeigt, daß zur Verschiebung des temporären linken Rands nach links ein RCR benötigt wird, Vorrang vor dem Schreiben eines CRE hat, auch wenn ein Absatzende nötig ist. Regel 1 für ZICR besagt, daß diese beiden und auch viele andere Dinge das Schreiben eines ZICR verhindern.
• DOWN kann drei Gründe haben, um ein Ein-Byte-Steuerzeichen PAGE END (Seitenende) zu schreiben; vgl. die Entscheidungstabelle in Fig. 19. Erstens - Regel 1 - enthält eine DCF-Steuerzeichenfolge möglicherweise ein PE-Byte, die UP dort hineingestellt hat, um den Seitenumbruch bei der Umwandlung eines L3-Dokuments nach DCF zu bewahren. Zweitens - Regeln 2, 3 und 4 - enthält eine Sequenz möglicherweise eines der DCF-Steuerzeichen, das in ein TUFC umgewandelt wird, welches wiederum auf ein PE und ein TUP folgen muß. Drittens - Regel 5 - enthält eine Sequenz möglicherweise ein EOF, das in ein End Unit umgewandelt wird, welches wiederum auf ein PE folgen muß. Es ist zu beachten, daß sich diese fünf Regeln nicht gegenseitig ausschließen. In der Tat können die fünf Steuerzeichen einschließlich des PE-Bytes und einschließlich EOF in beliebiger Kombination vorkommen. Eine Entscheidungstabelle, die nur unabhängige Regeln enthält, bräuchte 31 Regeln.
• Eine gegebene Sequenz kann sowohl Randtextdefinitionen als auch EOF enthalten. Ein früher Entwurf eines DCF-Dokuments kann mit Randtext enden, der für später hinzuzufügenden Text gelten soll. Derartiger Text kann hinzugefügt werden, nachdem das Dokument von DOWN nach L3 transformiert worden ist.
• Ein Text Unit Prefix (TUP)-Vektor ersten Grads ist erforderlich, wenn die DCF-Steuerzeichenfolge das Ende der vorigen Text Unit sowie den Beginn einer neuen Text Unit erfordert. Siehe dazu die Entscheidungstabelle für TUP in Fig. 20. Regel 1 prüft, ob in der Sequenz ein PE-Byte vorhanden ist, damit DOWN die vorige Text Unit beendet muß. Es ist jedoch erforderlich, daß DOWN auch nur dann eine neue Text Unit beginnt, wenn die Sequenz kein End Of File (Dateiende) enthielt. Die Regeln 2, 3 und 4 arbeiten folgendermaßen. Das Vorliegen irgendeines DCF-Steuerzeichens, das ein TUFC benötigt, in der DCF-Sequenz erfordert wiederum, daß DOWN die vorige Text Unit beendet und auch eine neue Text Unit beginnt. Dies ist unabhängig davon, ob die Sequenz ein EOF enthielt oder nicht. Ein EOF bedeutet, daß es keinen weiteren echten Grundtext gibt, aber eine weitere Text Unit nötig ist, die das TUFC und eventuell das MP und MT enthält. Die DCF- Steuerzeichen, die ein TUFC und somit eine neue Text Unit erfordern, egal, ob die Sequenz ein EOF enthielt oder nicht, sind entweder ".CM DRAWER", welches selbst in ein TUFC umgewandelt wird, oder ".RH" oder ".RF", die in MP und MT umgewandelt werden, die wiederum auf ein TUFC folgen müssen.
• Die Regeln 5, 6 und 7 decken eine einmalige Situation ab, die in der letzten Sequenz eines Dokuments auftreten kann, das heißt, in der Sequenz, die das End Of File des Dokuments enthält. Diese einmalige Situation beinhaltet die Tatsache, daß einige DCF- Steuerzeichen in L3-Steuerzeichen umgewandelt werden, die vor einem PE geschrieben werden, während andere DCF-Steuerzeichen in L3-Steuerzeichen umgewandelt werden, die nach einem PE geschrieben werden. Treten in der gleichen Steuerzeichenfolge ein EOF und irgendein Steuerzeichen des letzteren Typs gleichzeitig auf, wird ein PE geschrieben, und dann werden andere L3-Steuerzeichen geschrieben, die nach dem letzten PE stehen müssen. Daher muß in dieser einmaligen Situation das Schreiben eines weiteren PEs zu einem späteren Zeitpunkt vorbereitet werden. Die DCF-Steuerzeichen, die zum Auftreten dieser einmaligen Situation führen, sind ".IN", ".US ON" und ".CE". Das Steuerzeichen ".HW" wäre auch in diese Gruppe einzuordnen, wenn es bewirken würde, daß irgendetwas in den L3-Strom geschrieben wird, bevor irgendwelcher Text geschrieben wird, was aber nicht der Fall ist. Das Problem ergibt sich, da ein EOF in einer Sequenz das Schreiben eines PE verlangt. Das Schreiben eines PE beendet jedoch den aktuellen Body-Text-Vektor und die aktuelle Text Unit. Dies läßt keinen Body-Text-Vektor übrig, in den DOWN die Umwandlungen von ".IN", ".US ON" und ".CE" stellen kann. Diese Umwandlungen sind ITs, BUS bzw. SPs ATF. Es wäre sehr schwierig, diese Steuerzeichen bloß für die einmalige Situation, in der die DCF-Steuerzeichen, die sie notwendig machen, in der letzten Sequenz erscheinen, in der Ausgabereihenfolge vor PE zu schieben. Daher wird die einmalige Situation so gehandhabt, daß mit einem TUP eine neue Text Unit begonnen wird, um irgendwelche erforderlichen ITs, BUS oder SPs ATF aufzunehmen.
• Diese Behandlung der einmaligen Situation entspricht der Behandlung von ".RH", ".RF" oder ".CM DRAWER" in der letzten Sequenz. Jedes von ihnen beginnt eine neue Text Unit, um die Umwandlungen einiger weniger Steuerzeichen aufzunehmen, die nicht in die letzte, wirklich Text enthaltende Text Unit gehen können. Ein Dokument, das diese Behandlung vollständig gebraucht, hat folgende letzte Sequenz:
• TEXT
• CM DRAWER '''
• .RH ON ''' .RH OFF
• .RF ON ''' .RF OFF
• .IN 5
• .CE
• EOF
• Ein solches Dokument muß als nicht ganz regulär, aber sicher nicht als unmöglich angesehen werden. Solche Steuerzeichen am Ende eines DCF-Dokuments, das dann nach L3 heruntertransformiert wird, implizieren die Absicht, mit Displaywriter mehr Text hinzuzufügen. DOWN beginnt eine neue Text Unit, um die L3-Objekte und später hinzugefügten Text aufzunehmen.
• Es ist nicht wünschenswert, eine neue Text Unit zu beginnen, nur um ein paar IT-Steuerzeichen auf zunehmen, die eine Einzugsstufe wiederherstellen, die zufällig am Ende des Dokuments vorhanden war und die zufällig durch irgendetwas in der letzten Steuerzeichenfolge auf den permanenten linken Rand zurückgesetzt worden ist. Regel 6 soll diesen Fall ausschließen. Damit Regel 6 erfüllt ist, müssen die ITs ausdrücklich von einem ".IN h"-Steuerzeichen in der letzten Sequenz verlangt werden, d. h. GOTIN muß wahr sein, und der Wert von h in diesem Steuerzeichen muß ungleich null sein, d. h. CNTINC GT ZERO (d. h. CNTINC > 0) muß wahr sein.
• Es ist zu beachten, daß diese Behandlung vor allem eine neue Text Unit beginnt, damit DOWN sechs Steuerzeichen umwandeln kann, die in der gleichen Sequenz wie ein EOF vorkommen. Nachdem DOWN die einem oder mehreren dieser Steuerzeichen entsprechenden L3-Objekte geschrieben hat, muß DOWN ein spezielles PE schreiben, um diese Text Unit zu beenden. Dies ist die Erklärung für die Entscheidungstabelle "Special PE" in Fig. 30, die hier ebenfalls dargestellt ist, damit der ziemlich komplizierte Zusammenhang nicht doppelt dargestellt werden muß.
• Als Antwort auf eines oder mehrere der Steuerzeichen ".RH", ".RF" oder ".CM DRAWER" in einer DCF-Sequenz schreibt DOWN ein Text Unit Format Change (TUFC). Das letztgenannte Steuerzeichen fügt den Parametern von TUFC tatsächlich neue Informationen hinzu, die den Einzugsschacht eines Druckers angeben. Die Steuerzeichen ".RH" und ".RF" definieren Randtext, der nur nach einem TUFC nach L3 umgewandelt werden kann. Glücklicherweise können die anderen Parameter von TUFC neue, von anderen DCF- Steuerzeichen angegebene Informationen enthalten, sofern es irgendwelche in der gleichen Sequenz gibt.
• Wie LFC ist das Schreiben von TUFC nicht einfach, selbst nachdem eine Entscheidungstabelle - vgl. Fig. 21 - DOWN mitgeteilt hat, ob es geschrieben werden muß oder nicht. TUFC besitzt Parameter, die von Informationen, die aus DCF-Steuerzeichen in der gerade beendeten Sequenz stammen, oder von unveränderten Informationen, die noch vom letzten Status stammen, abhängen. Insbesondere muß es Informationen aus VALADJ, VALAL, VALTP, VALSSDS und VALCMDR verwenden. Außerdem muß DOWN die neuen Werte in die entsprechenden ständigen Statusvariablen CURADJ, CURAL, CURTP, CURSSDS und CURCMDR einsetzen.
• DOWN schreibt die Margin Text Parameters und den Aufbau von Margin Text in der ersten Stufe als Teil der Umwandlung einer DCF-Sequenz, die außer anderen, möglichen Dingen folgendes enthält:
• .RH ON
• Text und nahezu beliebige Steuerzeichen
• .RH OFF
• Die Verarbeitung von Text am oberen Rand am Ende einer DCF-Steuerzeichensequenz ist einfach, da die Vektoren MP und MT während des Einlesens der DCF-Sequenz als Antwort auf das ".RH ON" usw. vorbereitet worden sind. Sie befinden sich im Puffer namens Top Margin Text (TMT). Das Statusbit GOTRHON ist nur dann eins, wenn es etwas in TMT gibt, das an dieser Stelle in den L3-Datenstrom geschrieben werden muß. Die Entscheidungstabelle für MP und MT zeigt Fig. 22.
• Die Bottom Margin Parameters und Bottom Margin Text sind ähnlich wie Top MP und Top MT definiert. Vgl. die in Fig. 23 gezeigte Entscheidungstabelle. Als Antwort auf die DCF-Eingabe
• .RF ON
• Text und nahezu beliebige Steuerzeichen
• .RF OFF
• schreibt DOWN die Definition in den Puffer BMT, während es eine Steuerzeichenfolge liest. DOWN schreibt den Puffer in den L3- Datenstrom, wenn es eine abgeschlossene DCF-Steuerzeichensequenz nach L3 umwandelt.
• DOWN schreibt an dieser Stelle der Umwandlung einer DCF-Steuerzeichenfolge nach L3 nur dann den Kopf eines neuen Body-Text- Vektors (BT-Vektor), wenn es zuvor ein Text Unit Prefix geschrieben hat. Jede Text Unit beginnt mit einem TUP und endet mit einem BT. Daher sind die Entscheidungstabellen für diese beiden L3-Objekte identisch. Näheres darüber zeigt Fig. 24. Es ist zu beachten, daß der BT-Vektor hier beginnt, aber nicht endet. Im allgemeinen wandelt DOWN Text, in den viele DCF-Steuerzeichensequenzen eingestreut sind, nach L3 und schreibt L3 in diesen Body-Text-Vektor. DOWN beendet den BT-Vektor nur dann, wenn etwas in das Ein-Byte-Steuerzeichen Page End umgewandelt wird.
• Das Ergebnis der Umwandlung des Steuerzeichens ".CE" von DCF nach L3 sind dreiunddreißig SPace Characters (Leerzeichen) und ein aus mehreren Bytes bestehendes Steuerzeichen Align Text Field. Die SPs stehen stets nach einem Absatzende-Steuerzeichen. Das liegt daran, daß das Steuerzeichen ".CE" ein BREAK (Umbruch) bewirkt, so daß irgendeine DCF-Steuerzeichenfolge, die ein Steuerzeichen ".CE" enthält, nach der Umwandlung nach L3 zumindest CRE ZICR und eventuell etwas noch wirkungsvolleres wie ein RCR oder ein RPE enthält. Diese Umwandlung ergibt sich aus der Entscheidungstabelle in Fig. 25.
• DOWN schreibt Indent-Tab-Steuerzeichen (ITs), um für spätere Zeilen einen gewünschten temporären linken Rand zu erzeugen oder wiederherzustellen und um die Funktion horizontaler Tabulatorzeichen (Horizontal Tab Characters) in der aktuellen Zeile zu haben. Falls die aktuelle Zeile noch nicht angefangen hat, geben diese effektiven HT-Zeichen der aktuellen Zeile den gleichen effektiven temporären linken Rand wie spätere Zeilen; andernfalls ergeben sie einen hängenden Einzug.
• Beim Vorliegen zweier Objekte in einer DCF-Steuerzeichenfolge muß DOWN ITs in das Ergebnis der Umwandlung dieser Steuerzeichenfolge nach L3 schreiben. Zum einen kann ein Einzugssteuerzeichen ".IN h" einen neuen temporären linken Rand angeben. Zweitens kann es ein anderes Steuerzeichen in der DCF-Sequenz erforderlich machen, daß DOWN einen zuvor bestehenden temporären linken Rand wiederherstellt.
• Der erste Anwendungsfall für IT verschiebt den temporären linken Rand entweder von seiner alten Position in die neu angegebene Position oder vom permanenten linken Rand zur angegebenen neuen Position. Daher hat der erste Gebrauch von ITs zwei Unterfälle. Im ersten Unterfall befindet sich der neue temporäre linke Rand rechts vom permanenten linken Rand, und kein anderes Steuerzeichen in der gleichen Sequenz wird in ein L3-Objekt umgewandelt, das den temporären linken Rand auf den permanenten linken Rand zurücksetzt. In diesem Unterfall schreibt DOWN lediglich genügend ITs, um den temporären linken Rand auf seine neue Position zu verschieben.
• Im zweiten Unterfall des ersten Anwendungsfalls befindet sich entweder der neue temporäre linke Rand links vom alten temporären linken Rand, was nur dadurch nach L3 umgewandelt werden kann, daß der temporäre linke Rand auf den permanenten linken Rand zurückgesetzt wird und von dort aus ITs verwendet werden, um ihn nach rechts zu verschieben, oder ein anderes Steuerzeichen in der Sequenz wird in ein L3-Objekt umgewandelt, das zufälligerweise den temporären linken Rand auf den permanenten linken Rand zurückgesetzt hat, was wiederum genügend ITs erfordert, um den temporären linken Rand vom permanenten linken Rand auf den angegebenen neuen temporären linken Rand zu verschieben. Der zweite Hauptanwendungsfalls für ITs besteht darin, den temporären linken Rand wiederherzustellen, der galt, bevor die aktuelle DCF-Steuerzeichenfolge begann, und der durch nichts in der aktuellen Steuerzeichenfolge verändert wird. Beispielsweise läßt eine Sequenz, die nur das Steuerzeichen ".FO OFF" enthält, den temporären linken Rand unverändert. Das Steuerzeichen ".FO OFF" muß jedoch in L3 in die Sequenz Line Format Change (LFC) umgewandelt werden, die aus Steuerzeichen besteht, die wiederum aus mehreren Bytes bestehen. Ein LFC setzt den temporären linken Rand auf den permanenten linken Rand zurück. Daher muß eine Sequenz, die nur aus ".FO OFF" besteht, in ein LFC und null oder mehrere folgende ITs umgewandelt werden, um den gerade gültigen temporären linken Rand wiederherzustellen.
• Dieser zweite Hauptanwendungsfall für ITs besitzt eine größere Bedeutung, wenn eine DCF-Steuerzeichenfolge ein Steuerzeichen ".TB" enthält, das die Tabulatorpositionen ändert. Ein ".TB"- Steuerzeichen wird entweder in ein LFC oder in ein TUFC umgewandelt. LFC oder TUFC setzen den temporären linken Rand zurück, so daß DOWN im ersten Anwendungsfall den temporären linken Rand wiederherstellen oder einen gewünschten neuen temporären linken Rand setzen muß. Die für das Wiederherstellen bzw. das Setzen des temporären linken Rands erforderliche Zahl von ITs hängt von den Einstellungen im neuen Tabulatorgitter ab. Es ist nicht nötig, zu wissen, wieviele ITs vor der Änderung des Tabulatorgitters gesetzt waren. Es reicht aus, wenn man die Zeichenposition des gewünschten temporären linken Rands kennt, ob sich dieser nun geändert hat oder nicht.
• Ob DOWN ITs schreiben muß und wieviele ITs es schreiben muß, hängt von den folgenden Informationen ab:
• - den Tabulatorpositionen, die nach Abschluß der Umwandlung der aktuellen Sequenz gesetzt sind (VALTP),
• - der Zeichenposition nach Abschluß der Umwandlung des gewünschten temporären linken Rands, ob die aktuelle Sequenz diesen Wert (CNTINC) nun ändert oder nicht,
• - der Zeichenposition des temporären linken Rands vor Beginn der aktuellen DCF-Steuerzeichenfolge (CURINC), und
• - ob irgendein L3-Objekt, das als Teil der Umwandlung dieser DCF-Steuerzeichenfolge den temporären linken Rand auf den permanenten linken Rand zurücksetzt oder nicht.
• Die L3-Objekte, die den temporären linken Rand zurücksetzen, und die DCF-Steuerzeichen, die in diese L3-Objekte umgewandelt werden, werden in der in Fig. 27 dargestellten Tabelle verglichen. Das erste Objekt in der Tabelle bedarf eines Kommentars. Es ist unwichtig, ob in irgendeinem ".IN h"-Steuerzeichen h kleiner als CURINC war. Wichtig ist, ob h im letzten ".IN h"-Steuerzeichen in der Sequenz kleiner als CURINC war. Daher prüft DOWN die Bedingung CNTINC LT CURINC.
• Regel 1 in der Tabelle in Fig. 26 schreibt vor, daß, wenn die gerade abgeschlossene Sequenz keines dieser Steuerzeichen und kein EOF enthält, DOWN nur dann ein oder mehrere ITs schreibt, wenn CNTINC größer als CURINC ist. Die Zahl der geschriebenen ITs ist um eins größer als die Zahl der Tabulatorpositionen, dessen Zeichenpositionen stets größer als CURINC und stets kleiner als CNTINC sind.
• Regeln 2 bis 9 besagen, daß, wenn die gerade abgeschlossene Sequenz irgendeines oder irgendwelche dieser Steuerzeichen, aber kein EOF enthält, DOWN nur dann ein oder mehrere ITs schreibt, wenn CNTINC größer als null ist. Die Zahl der geschriebenen ITs ist um eins größer als die Zahl der Tabulatorpositionen, dessen Zeichenpositionen stets kleiner als CNTINC sind.
• Die Regeln 1 bis 9 besagen, daß keine ITs geschrieben werden, falls die Sequenz ein EOF enthält. Es gibt einen Fall, in dem DOWN bei der Umwandlung der letzten DCF-Steuerzeichenfolge, d. h. der Sequenz, die ein EOF enthält, ITs schreibt. Siehe Regel 6 der Entscheidungstabelle für TUP (Fig. 20). Regel 10 für das Rücksetzen des temporären linken Rands leitet sich aus dieser Bedingung ab. Dies ist der Fall, in dem DOWN eine neue Text Unit angefangen hat, um darin ITs und/oder einige wenige andere L3-Objekte aufzunehmen, die ein gerade in Arbeit befindliches Dokument beenden können und die für später hinzuzufügenden Text gelten. Dies ist der Fall, bei dem h in einem eventuell vorkommenden ".IN h"-Steuerzeichen in der letzten Sequenz größer als null ist.
• Am Ende des Schreibens der ITs setzt DOWN die Zeichenposition des neuen temporären linken Rands sowohl in CNTINC als auch in CURINC ein. Dieser Status ist zur korrekten Verarbeitung der nächsten DCF-Steuerzeichenfolge unbedingt erforderlich. Dabei ist besonders zu beachten, daß dies zum Erhöhen des Werts in CNTINC führen kann. Der Wert in CNTINC war der Wert von h im letzten ".IN h"-Steuerzeichen in der gerade abgeschlossenen DCF- Steuerzeichenfolge. Stimmt dieser Wert nicht mit einer Tabulatorposition im aktuellen Tabulatorgitter überein, dann ist der endgültige Wert sowohl von CNTINC als auch von CURINC die Zeichenposition der neuen höheren Tabulatorposition, d. h. der sich für den wahren temporären linken Rand ergebende Wert.
• DOWN schreibt das aus mehreren Bytes bestehende Steuerzeichen Begin UnderScore (BUS) als Teil der Umwandlung einer DCF- Steuerzeichenfolge nur dann, wenn diese Steuerzeichenfolge ".US ON" enthält. Die dazugehörige Entscheidungstabelle befindet sich in Fig. 28.
• DOWN setzt das ständige Statusbit CURHW als Teil der Verarbeitung des Endes einer DCF-Steuerzeichensequenz nur dann, wenn diese Sequenz ein ".HW"-Steuerzeichen enthielt. Das Setzen von CURHW weist das Programm an, sämtliche Bindestriche im folgenden Wort durch das L3-Ein-Byte-Steuerzeichen Syllable HYphen (Silbentrennstrich) zu ersetzen. Das Steuerzeichen ".HW" besitzt keinen unmittelbaren Einfluß mehr auf den L3-Datenstrom. Die Entscheidungstabelle für CURHW zeigt Fig. 29.
• Ein spezielles PE beendet eine Text Unit und dessen Body-Text- Vektor, ohne irgendeinen wirklichen Text darin geschrieben zu haben. DOWN besitzt eine einmalige Situation, die als Teil der Beschreibung der Entscheidungstabelle für TUP näher beschrieben ist, wenn die letzte Sequenz eines Dokuments Steuerzeichen enthält, die für später hinzugefügten Text gedacht sind. Siehe die Entscheidungstabelle für das spezielle PE in Fig. 30.
• Die Regeln 2, 3 und 4 für TUP (Fig. 20) können erfüllt sein, egal ob die Sequenz ein EOF enthält oder nicht. Enthält die Sequenz ein EOF und ist eine dieser Regeln erfüllt, dann beginnt DOWN eine Text Unit und danach einen Body-Text-Vektor, die zu einem anständigen Abschluß gebracht werden müssen, obwohl in keines der beiden jemals Text geschrieben wird. Die gleichen Regeln treffen hier nur zu, falls die Sequenz wirklich ein EOF enthält, da DOWN nur in diesem Fall eine besondere Handlung braucht, um die Text Unit und den Body-Text-Vektor, die durch diese Regeln angefangen worden sind, zu beenden.
• Die Regeln 5, 6 und 7 für TUP treffen nur zu, wenn die umzuwandelnde Sequenz die letzte Sequenz im Dokument ist. Daher kommen hier identische Regeln mit den gleichen Nummern vor, um DOWN anzuweisen, wann die Text Unit und der Body-Text-Vektor, die sie angefangen haben, zu beenden sind. Regel 1 bleibt hier leer, damit sie den entsprechenden Regeln in den Ausgabeentscheidungstabellen für TUP und BT entspricht.
• DOWN schreibt als letzten Teil der Umwandlung der letzten Sequenz eines DCF-Dokuments nach L3 ein End Unit (EU), d. h. ein End Unit Prefix, einen Body-Text-Vektor und ein Page End in diesen BT-Vektor. Die letzte Sequenz wird durch GOTEOF signalisiert, was bedeutet, daß ein End Of File Bestandteil der DCF- Steuerzeichenfolge war. Die Entscheidungstabelle für EU zeigt
• Fig. 31.
• Wenngleich die vorliegende Erfindung im Zusammenhang mit einem bevorzugten Ausführungsbeispiel beschrieben worden ist, wird der einschlägige Fachmann leicht einsehen, daß daran Modifizierungen und Änderungen vorgenommen werden können, ohne den Erfindungsbereich zu verlassen. Dementsprechende ist nicht beabsichtigt, daß die vorliegende Erfindung auf die Einzelheiten der vorangegangenen Beschreibung des bevorzugten Ausführungsbeispiels eingegrenzt wird. Vielmehr sollte die vorliegende Erfindung als nur durch die anliegenden Ansprüche eingegrenzt betrachtet werden, die allein dazu gedacht sind, den Erfindungsbereich zu definieren.

Claims (7)

1. Verfahren zur Umwandlung von Text,

der in Form digitaler Daten dargestellt ist,

wobei ein Quelldokument, das in einem ersten editierbaren Format, welches eine Vielzahl von Eingabesteuerobjekten enthält, erstellt worden ist, in ein Zieldokument umgewandelt wird, das ein zweites editierbares Format besitzt, welches eine Vielzahl dazu kompatibler Ausgabesteuerobjekte enthält,

wobei das Verfahren folgende Schritten umfaßt:

a) Bestimmen (Fig. 2) eines Satzes von Schlüsselstatusvariablen aus allen möglichen Statusvariablen, die Informationen hinsichtlich des Vorhandenseins von Eingabesteuerobjekten, die in einer Eingabesequenz aus dem Quelldokument eingelesen werden, widerspiegeln und gemeinsam identifizieren;

b) Bestimmen von Kriterien für die Kompatibilität der einzulesenden Eingabesteuerobjekte mit den Eingabesteuerobjekten, die in der Eingabesequenz eingelesen worden sind und durch die Schlüsselstatusvariablen widergespiegelt werden;

c) Aufbauen (Fig. 4-8) einer festen Ordnung für alle möglichen Ausgabesteuerobjekte in Verbindung mit den Schlüsselstatusvariablen, um einen gegebenen Teil der Eingabesteuerobjekte enthaltenden Eingabesequenz umzuwandeln;

d) Bestimmen eines Satzes von Regeln (Fig. 9-31) für jedes mögliche Ausgabesteuerobjekt, die darüber bestimmen, ob das jeweilige mögliche Ausgabesteuerobjekt als Funktion des Status der Statusvariablen in das Zieldokument hineingeschrieben wird; und

digitales Verarbeiten des Texts durch

e) Einlesen einer gegebenen Eingabesequenz von Eingabesteuerobjekten aus dem Quelldokument gemäß den erwähnten Kompatibilitätskriterien; und

f) Schreiben aller passenden Ausgabesteuerobjekte in das Zieldokument in der festgelegten Reihenfolge als Ergebnis der Umwandlung der gegebenen Eingabesequenz.

2. Verfahren gemäß Anspruch 1, das den zusätzlichen Schritt enthält, daß eine Sequenz aus Eingabesteuerobjekten beendet wird, wenn darin ein Texteingabeobjekt vorgefunden wird.

3. Verfahren gemäß Anspruch 1 oder 2, das den zusätzlichen Schritt enthält, daß eine Sequenz aus Eingabesteuerobjekten beendet wird, wenn darin ein inkompatibles Eingabesteuerobjekt vorgefunden wird.

4. Verfahren gemäß einem der vorhergehenden Ansprüche, das den zusätzlichen Schritt enthält, daß das Vorliegen von Unterdokumenten im Quelldokument ermittelt wird und danach dieselben in einem Puffer bewahrt werden, um nach der Umwandlung der Eingabesequenz bis zu dieser Stelle verwendet zu werden.

5. Verfahren gemäß einem der vorhergehenden Ansprüche, das den zusätzlichen Schritt enthält, daß die Anzahl der Schlüsselstatusvariablen auf höchstens 24 begrenzt wird.

6. Verfahren gemäß einem der vorhergehenden Ansprüche, das den zusätzlichen Schritt enthält, daß bei der Umwandlung einer beliebigen gegebenen Sequenz aus Eingabesteuerobjekten Paare von sich gegenseitig ausschließenden Ausgabesteuerobjekten ermittelt werden.

7. Verfahren gemäß einem der vorhergehenden Ansprüche, wobei der erwähnte Schritt des Aufbaus einer festen Reihenfolge aller möglichen Ausgabesteuerobjekte bewerkstelligt wird, indem für bestimmte Paare von Ausgabesteuerobjekten eine hierarchische Regeln enthaltende Entscheidungstabelle geschrieben wird und dann die Spalten so sortiert werden, daß die die Hierarchie bildenden Nummern in der Tabelle nur von oben nach unten zunehmen.