DE3382758T2 - Verfahren zur Umwandlung einer ersten editierbaren Dokumentenform, vorbereitet von einem interaktiven Textverarbeitungssystem, 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 mit einem interaktiven Textverarbeitungssystem 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 eines Eingabeobjekts vom interaktiven Quellformat in einen ganz bestimmten Satz von Ausgabeobjekten für das editierbare Format des Zieldokuments auf der Grundlage geeignet gewählter Statusvariablen, die Zustände der Eingangsobjekte am Umwandlungspunkt 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, das 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. Document Composition Facility (DCF) bzw. SCRIPT/VS ist ein von der IBM Corporation vertriebenes Textverarbeitungsprogramm. Das Professional Office System oder PROFS ist ein menügesteuertes Programm, das von der IBM Corporation vertrieben wird und insbesondere zur Bearbeitung einer breiten Palette 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. Dieses Dokumentenformat 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 der 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, die Textverarbeitungen mit unüberwindbaren Systemgrenzen einsetzt, 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 von ihnen 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-Ersetzungs- bzw. 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 interaktiven Textverarbeitungssystem in einem editierbaren Quellformat erstellt worden ist, wobei dieses Format nur mit diesem interaktiven Textverarbeitungssystem editiert oder formatiert werden kann, in ein anderes editierbares Format bzw. ein Zielformat, das zum Editieren und Formatieren in einem beliebigen anderen 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 weitere Aufgaben der vorliegenden Erfindung werden anspruchsgemäß durch ein Umwandlungsverfahren erreicht, bei dem eine feste Anzahl von Schlüssel-Statusvariablen erkannt wird. Diese Schlüssel-Statusvariablen betreffen den Status eines Quelldokuments entsprechend seines Datenstroms an jeder beliebigen gegebenen Stelle des Umwandlungsverfahrens, und gemeinsam identifizieren sie ihn auch. Dann wird die tatsächliche Anzahl möglicher Zustände bzw. Kombinationen von Schlüsselvariablen ermittelt. Danach wird für jeden möglichen Status und für jedes mögliche Quell-Eingabeobjekt ein ganz bestimmter Satz von Ausgabeobjekten sowie der nächste Status festgelegt. Außerdem muß irgendwann vor der Umwandlung der aktuelle Status ermittelt werden, der am Anfang jedes Quelldokuments vorliegt. Falls nötig, wird schließlich die Verarbeitung von Unterdokumenten wie z. B. Randtext zu Umwandlungszwecken angegeben, was die Erhaltung der Informationen in den Textvariablen vor der Umwandlung des Unterdokuments zur späteren Verwendung nach der Umwandlung einschließt, ohne darauf eingeschränkt zu sein.
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 eine verallgemeinerte Entscheidungstabelle darstellt, die in Tabellenform eine Zusammenfassung der Umwandlung zeigt, die sich aufgrund der Gegenwart eines speziellen Eingabeobjekts in einem ersten editierbaren Dokumentenformat ergibt, wenn diese Umwandlung in ein zweites editierbares Dokumentenformat gemäß eines Satzes von dafür geltenden Regeln stattfindet, die in den Spalten der Tabelle aufgeführt sind, wobei alles mit dem Verfahren der vorliegenden Erfindung vereinbar ist;
• Fig. 2 schematisch eine verallgemeinerte Darstellung der in Fig. 1 gezeigten Tabelle darstellt und ein Statusübergangsdiagramm für die darin zusammengefaßten Eingabeobjekte bildet;
• Fig. 3 schematisch eine vereinfachte Darstellung einer vereinten aber auftrennbaren Konfiguration zweier Textverarbeitungssysteme zeigt, die zur Übertragung und zur anschließenden Umwandlung editierbarer Dokumentenformen von einem Textverarbeitungssystem in das andere gemäß der vorliegenden Erfindung ausgelegt sind;
• Fig. 4 eine Tabelle darstellt, die in Tabellenform eine Zusammenfassung der Zustände mehrerer Schlüsselzustandsvariablen zeigt, welche gemeinsam zur Festlegung der erforderlichen Statusinformationen verwendet werden, die dazu dienen, ein erstes Format eines editierbaren Dokuments in ein zweites, unabhängiges editierbares Format umzuwandeln, wobei Anfangswerte und Werte nach einem Worttrennzeichen (word delimiter, WD) und nach einem Trennzeichen, das kein Wort begrenzt (non-word delimiter, NWD), gezeigt werden, wobei alles mit dem Verfahren der vorliegenden Erfindung vereinbar ist;
• Fig. 5 und 6 in Tabellenform die verschiedenen Auswirkungen und Beziehungen zeigen, die sich aus der Gegenwart und der Bedeutung der Statusvariablen aus Fig. 4 ergeben;
• Fig. 7 schematisch ein Statusübergangsdiagramm für die in den Fig. 5 und 6 gezeigten Tabellen darstellt;
• Fig. 8 eine Entscheidungstabelle darstellt, die in Tabellenform eine Zusammenfassung der Umwandlung aufgrund des Vorliegens des Eingabeobjekts CRE im ersten editierbaren Dokumentenformat zeigt, wenn diese Umwandlung gemäß einem Satz von Regeln in den Spalten der Tabelle in ein zweites Format eines editierbaren Dokuments durchgeführt wird;
• Fig. 9 schematisch die Umwandlung darstellt, die in der in Fig. 8 gezeigten Tabelle beschrieben wird, und ein Statusübergangsdiagramm für das darin zusammengefaßte Eingabeobjekt CRE bildet;
• Fig. 10 eine Entscheidungstabelle darstellt, die in Tabellenform eine Zusammenfassung der Umwandlung aufgrund des Vorliegens der Eingabeobjekte RCR bzw. IRT im ersten editierbaren Dokumentenformat zeigt, wenn diese Umwandlung gemäß einem Satz von Regeln in den Spalten der Tabelle in ein zweites Format eines editierbaren Dokuments durchgeführt wird;
• Fig. 11 schematisch die Umwandlung darstellt, die in der in Fig. 10 gezeigten Tabelle beschrieben wird, und ein Statusübergangsdiagramm für die darin zusammengefaßten Eingabeobjekte RCR bzw. IRT bildet;
• Fig. 12 eine Entscheidungstabelle darstellt, die in Tabellenform eine Zusammenfassung der Umwandlung aufgrund des Vorliegens des Eingabeobjekts ZICR im ersten editierbaren Dokumentenformat zeigt, wenn diese Umwandlung gemäß einem Satz von Regeln in den Spalten der Tabelle in ein zweites Format eines editierbaren Dokuments durchgeführt wird;
• Fig. 13 schematisch die Umwandlung darstellt, die in der in Fig. 12 gezeigten Tabelle beschrieben wird, und ein Statusübergangsdiagramm für das darin zusammengefaßte Eingabeobjekt ZICR bildet;
• Fig. 14 eine Entscheidungstabelle darstellt, die in Tabellenform eine Zusammenfassung der Umwandlung aufgrund des Vorliegens des Eingabeobjekts PE im ersten editierbaren Dokumentenformat zeigt, wenn diese Umwandlung gemäß einem Satz von Regeln in den Spalten der Tabelle in ein zweites Format eines editierbaren Dokuments durchgeführt wird;
• Fig. 15 eine Entscheidungstabelle darstellt, die in Tabellenform eine Zusammenfassung der Umwandlung aufgrund des Vorliegens des Eingabeobjekts RPE im ersten editierbaren Dokumentenformat zeigt, wenn diese Umwandlung gemäß einem Satz von Regeln in den Spalten der Tabelle in ein zweites Format eines editierbaren Dokuments durchgeführt wird;
• Fig. 16 schematisch die Umwandlung darstellt, die in der in Fig. 15 gezeigten Tabelle beschrieben wird, und ein Statusübergangsdiagramm für das darin zusammengefaßte Eingabeobjekt RPE bildet;
• Fig. 17 eine Entscheidungstabelle darstellt, die in Tabellenform eine Zusammenfassung der Umwandlung aufgrund des Vorliegens der Eingabeobjekte LFC bzw. RMLF im ersten editierbaren Dokumentenformat zeigt, wenn diese Umwandlung gemäß einem Satz von Regeln in den Spalten der Tabelle in ein zweites Format eines editierbaren Dokuments durchgeführt wird;
• Fig. 18 schematisch die Umwandlung darstellt, die in der in Fig. 17 gezeigten Tabelle beschrieben wird, und ein Statusübergangsdiagramm für die darin zusammengefaßten Eingabeobjekte LFC bzw. RMLF bildet;
• Fig. 19 eine Entscheidungstabelle darstellt, die in Tabellenform eine Zusammenfassung der Umwandlung aufgrund des Vorliegens der Eingabeobjekte RSP, UBS, NBS bzw. BS im ersten editierbaren Dokumentenformat zeigt, wenn diese Umwandlung gemäß einem Satz von Regeln in den Spalten der Tabelle in ein zweites Format eines editierbaren Dokuments durchgeführt wird;
• Fig. 20 schematisch die Umwandlung darstellt, die in der in Fig. 19 gezeigten Tabelle beschrieben wird, und ein Statusübergangsdiagramm für die darin zusammengefaßten Eingabeobjekte RSP, UBS, NBS bzw. BS bildet;
• Fig. 21 eine Entscheidungstabelle darstellt, die in Tabellenform eine Zusammenfassung der Umwandlung aufgrund des Vorliegens der Eingabeobjekte APM, AAM, TUFC bzw. RTMF im ersten editierbaren Dokumentenformat zeigt, wenn diese Umwandlung gemäß einem Satz von Regeln in den Spalten der Tabelle in ein zweites Format eines editierbaren Dokuments durchgeführt wird;
• Fig. 22 schematisch die Umwandlung darstellt, die in der in Fig. 21 gezeigten Tabelle beschrieben wird und ein Statusübergangsdiagramm für die darin zusammengefaßten Eingabeobjekte APM, AAM, TUFC bzw. RTMF bildet;
• Fig. 23 eine Tabelle darstellt, die in Tabellenform eine Zusammenfassung bestimmter Zustandsvariablen am Schluß der Randtextdefinition zeigt;
• Fig. 24 eine Entscheidungstabelle darstellt, die in Tabellenform eine Zusammenfassung der Umwandlung aufgrund des Vorliegens des Eingabeobjekts ATF im ersten editierbaren Dokumentenformat zeigt, wenn diese Umwandlung gemäß einem Satz von Regeln in den Spalten der Tabelle in ein zweites Format eines editierbaren Dokuments durchgeführt wird; und
• Fig. 25 schematisch die Umwandlung darstellt, die in der in Fig. 24 gezeigten Tabelle beschrieben wird, und ein Statusübergangsdiagramm für das darin zusammengefaßte Eingabeobjekt ATF bildet.
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 "editierbares Dokumentenformat", "DCF-Dokumentenformat", "L3-Dokumentenformat" und "Dokumenten-Datenstrom" gleichwertige Bezeichnungen für die editierbare Version eines speziellen Dokuments in der angezeigten Form, so wie es auf der Platte bzw. Diskette eines Benutzers oder bei der Übertragung zwischen zwei Textverarbeitungssystemen vorliegt.
• 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 bedeutsam. 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 verallgemeinerten Gesichtspunkte des zum Erzielen dieser Vorteile gemäß der vorliegenden Erfindung verwendeten Verfahrens sieht vor, daß jedes Eingabeobjekt der Quelldokumentenform, z. B. ein Textzeichen oder Steuerobjekt zur Formatierung, in Abhängigkeit von der Art des Eingabeobjekts selbst und dem "Status" des Umwandlungsmechanismus, der beim Antreffen des Eingabeobjekts vorgefunden wird, in ein oder mehrere Ausgabeobjekte umgewandelt wird. Das eingesetzte Verfahren ändert durch jedes vorgefundene Eingabeobjekt zudem den Status des Umwandlungsmechanismus, was auch von demjenigen Status abhängt, der bei der Umwandlung eines speziellen Eingabeobjekts vorlag. Eine besondere Anwendung der vorliegenden Erfindung beruht auf der Auswahl eines ausreichenden Satzes von Statusvariablen, um den Status des Quelldokuments überall darzustellen, d. h. vor irgendeinem Eingabeobjekt im Dokument. Die Umwandlung eines jeden Eingabeobjekts darf ausschließlich vom Eingabeobjekt selbst und den Werten dieser Statusvariablen zum Zeitpunkt, an dem das Eingabeobjekt vorgefunden wird, abhängen. Zudem muß es für jede dieser Statusvariablen nach der Umwandlung jedes einzelnen Eingabeobjekts in eines oder mehrere Ausgabeobjekte einen eindeutig festgelegten Wert geben. Dieses Verfahren gestattet eine Umwandlung, die für jedes einzelne Eingabeobjekt durch eine Entscheidungstabelle zu beschreiben ist. Darüber hinaus kann jede Entscheidungstabelle jeweils einem Statusübergangsdiagramm entsprechen, das die gleiche Information in einer Form darstellt, deren Richtigkeit leichter überprüft werden kann. Dieses Konzept, bei dem aus den vielen möglichen Schlüsselvariablen nur einige wenige ausgewählt wird, hält das ganze Verfahren aufrecht. Ohne diese Strategie müßte ein Umwandlungsmechanismus alle vorhergehenden Zeichen im Datenstrom im Auge behalten, was eine mühsame Aufgabe ist.
• Die allgemeine Auslegung der Entscheidungstabelle und eines Statusübergangsdiagramms, die zur Verwendung mit dem offenbarten Verfahren geeignet sind, zeigen die Fig. 1 und 2. Wie dort gezeigt wird, ist es möglich, die Umwandlung eines gegebenen Eingabeobjekts in ein, zwei oder drei Ausgabeobjekte zu beschreiben, wobei die Zahl und Art der Ausgabeobjekte von den Werten der Statusvariablen beim Antreffen des Eingabeobjekts abhängen. In der beispielartigen Entscheidungstabelle in Fig. 1 ist jede der numerierten Spalten eine "Regel". Eine Regel ist dann "erfüllt", wenn die Werte der Statusvariablen mit den Buchstaben im Teil "vorheriger Status" der Tabelle übereinstimmen, d. h. falls jede Variable, zu der der Buchstabe "Y" gehört, wahr ist und falls jede Variable, zu der der Buchstabe "N" gehört, falsch ist. Eine Variable, der in der entsprechenden Spalte das Symbol "-" (Gedankenstrich) zugeordnet ist, kann entweder wahr oder falsch sein. Dies hat keinen Einfluß auf die Gültigkeit der Regel in der Spalte, in der das Symbol erscheint. Der Rest der Entscheidungstabelle gibt an, was zu tun ist, wenn eine Regel erfüllt ist, d. h. welche Ausgabeobjekte (in der Reihenfolge 1, 2, 3 usw.) geschrieben und welche Statusvariablen gesetzt (Y) oder zurückgesetzt (N) werden müssen.
• In dem in Fig. 2 gezeigten Statusübergangsdiagramm ist eine gegebene Statusvariable innerhalb ihres eigenen Rechtecks wahr und außerhalb dieses Rechtecks falsch. Beispielweise ist die durch das Rechteck IJKL festgelegte STATUSVARIABLE C stets dann wahr, wenn die durch das Rechteck MNKO festgelegte STATUSVARIA- BLE D wahr ist. Das Gegenteil ist jedoch nicht stets der Fall, da C außerhalb des Rechtecks MNKO wahr sein kann und D nicht. Um ein Rechteck zu verlassen, das irgendeine der gegebenen Variablen festlegt, muß das implementierte System den angegebenen Umwandlungspfaden folgen. Beispielsweise führt der Pfad von STATUSVARIABLE A über Regel bzw. Bedingung 2' durch die zu den Ausgabeobjekten X und Y führende Umwandlung zur STATUSVARIABLEN D. Das bedeutet, daß das Vorliegen eines gegebenen Eingabeobjekts in einem ersten editierbaren Format eines Dokuments, vorausgesetzt, A ist wahr, B, C und D sind falsch und Bedingung 2' ist erfüllt, zu einer ganz bestimmten Umwandlung und zu einem anderen ganz bestimmten Status führt.
• Im Statusübergangsdiagramm in Fig. 2 ist jede mögliche Umwandlung des gegebenen Eingabeobjekts durch eine gestrichelte Linie dargestellt. Diese Linie beginnt bei einem möglichen vorherigen Status, läuft durch eine Reihe von Ausgabeobjekten, die in das Zielformat zu schreiben sind, wenn das gegebene Eingabeobjekt in diesem Status vorgefunden wird, und endet beim erforderlichen nächsten Status. Mit Hilfe des offenbarten Umwandlungsverfahrens kann der Hauptteil einer Umwandlung durch eine Entscheidungstabelle und/oder ein Statusübergangsdiagramm für jedes einzelne Eingabeobjekt beschrieben werden. In der Praxis sind die Umwandlungen so kompliziert, daß beide Beschreibungsarten gebraucht werden, um die Umwandlung so gut zu verstehen, daß sie überprüft werden kann, selbst wenn die Entscheidungstabelle alleine einem Programmierer zur Programmierung der Umwandlung genügt.
• Dieses Verfahren wurde erfolgreich bei der Umwandlung eines editierbaren Dokuments von OIIA L3 nach DCF angewendet. Daher soll die vorliegende Erfindung mit Hilfe der allgemeinen sowie der betreffenden speziellen Aspekte dieser Umwandlung als Beispiel beschrieben werden. OIIA L3 oder Office Information Interchange Architecture Level 3, ein Handelsname der IBM Corporation, ist eines der zuvor erwähnten Datenstromformate für Dokumente. Sie wird ab hier als L3 bezeichnet. Sie ist das Format, das im Displaywriter der IBM Corporation verwendet wird. DCF oder Document Composition Facility, ein weiterer Handelsname 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. Die tatsächlichen Statusvariablen, Entscheidungstabellen und Statusübergangsdiagramme für diese spezielle Umwandlung werden nachfolgend einzeln beschrieben.
• Fig. 3 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 auch 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. Der Vorgesetzte ist dagegen mit der kostengünstigeren Datenstation 20, die mit dem zentralen Datenverarbeitungssystem verbunden ist, gut bedient. Der Vorgesetzte hat nicht nur auf weitere Programme des Zentralrechners Zugriff, sondern auch auf den zuvor erwähnten Editor 26, das DCF-Formatierungsprogramm 28 und weitere systemunterstützten Zusätze, die zur Leistung beitragen, z. B. PROFS (Professional Office System). Die Einrichtung für die Umwandlung von L3 nach DCF gestattet Sekretärinnen und Vorgesetzten, ihre jeweiligen Einrichtungen zur Textverarbeitung und zum Editieren in vollkommener Zusammenarbeit zu verwenden. Ein Vorgesetzter bzw. eine Vorgesetzte kann von seiner bzw. ihrer Sekretärin eingegebene oder editierte Dokumente einsehen und editieren. Die entsprechende Umwandlung von DCF in L3, die jedoch ganz andere Verfahren verwendet, sowie eine Vorrichtung, die dem Zentralrechner die Kontrolle über die DW-Diskettendateien gibt, ermöglicht es, daß die Sekretärin vom Vorgesetzten eingegebene und editierte Dokumente einsehen und editieren kann. Bezüglich der Übertragung von Dokumenten und der Umwandlung von Dokumentendateien bezeichnet "UP" ("HOCH") eine Übertragung von L3 nach DCF und "DOWN" ("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 DCF nach L3 bzw. der Vorrichtung, die dem Zentralrechner Kontrolle über die DW-Diskette gibt, finden sich in den mitanhängigen europäischen Patentanmeldungen 83111222.2 bzw. 83111223.0.
• Die Umwandlung von L3 nach DCF ist schwierig, da sich die beiden Formate zur Darstellung editierbarer Dokumente stark unterscheiden. Beide stellen zwar Buchstaben, Zahlen und Symbole wenn auch mit gewissen Unterschieden in Codierungspunkten auf ähnliche Weise dar, stellen jedoch auch Informationen darüber dar, wie diese Zeichen zum Drucken auf einer Seite zu formatieren sind. Die Art und Weise, wie die beiden Formate diese Formatierungsdaten darstellen, unterscheidet sich jedoch in nahezu jeder Beziehung. Ein L3-Dokument beispielsweise codiert die Formatierungsdaten in ungefähr 200 verschiedene Objektarten, wobei ein Objekt eine Struktur auf oberster Ebene, eine Struktur auf der zweiten Ebene, ein Parameter von einer dieser Strukturen, ein Steuerzeichen aus mehreren Bytes, ein Parameter eines Steuerzeichens aus mehreren Bytes oder ein Ein-Byte-Steuerzeichen ist. Ein spezielles Beispiel für ein Objekt ist Ein-Byte-Steuerzeichen '3A', ein unveränderliches Seitenende bzw. RPE (Required Page End). Dieses Steuerzeichen befiehlt dem DW-Formatierungsprogramm, einen Absatz zu beenden, den Einzug zu beenden und den folgenden Text auf die nächste Seite zu setzen. Ein DCF-Dokument kann etwa 120 verschiedene Arten von Formatierungssteuerzeichen enthalten. Eines davon ist ".PA", das dem DCF-Formatierungsprogramm angibt, einen Absatz zu beenden und den folgenden Text auf eine neue Seite zu setzen. Dabei ist zu beachten, daß ein RPE nicht in ein ".PA" umgewandelt werden kann, da letzteres nicht den Einzug beendet. Dies veranschaulicht die allgemeine Tatsache, daß keines der wichtigsten L3-Objekte eine direkte Entsprechung in DCF besitzt. In diesem Fall muß zur Umwandlung einfach ein weiteres DCF-Steuerzeichen, nämlich ".IN 0", hinzugefügt werden, um den Einzug zu beenden. In den meisten Fällen ist die Umwandlung eines gegebenen L3-Objekts sehr viel komplizierter, da sie in starkem Maße davon abhängt, welche L3-Objekte vor dem gegebenen Objekt vorkamen.
• Es ist technisch unmöglich, für jedes Objekt eine separate Umwandlung für jeden möglichen Satz von vorhergehenden Objekten aufzustellen. Nehmen wir einmal an, die Umwandlung eines L3- Objekts könne nur von den letzten 6 Objekten abhängen und es möge nur 20 verschiedene Objektarten geben, was eine starke Untertreibung ist. Die Zahl der Möglichkeiten für nur die letzten 6 Objekte, wobei jedes Objekt eines von 20 unterschiedlichen Arten sein kann, beträgt 64 000 000. Eine Definition einer korrekten Umwandlung von jeder der 20 Objektarten für jeden dieser möglichen vorherigen Zustände kommt nicht in Frage. Ein tatsächliches L3-Dokument besitzt weitaus mehr als diese Anzahl möglicher Zustände, die zu dem Zeitpunkt existieren können, an dem das Objekt vorkommt und umgewandelt werden soll.
• Das hier offenbarte Umwandlungsverfahren gibt sieben binäre Statusvariablen an, deren Werte gemeinsam die erforderlichen Statusinformationen zur Umwandlung des Dokuments festlegen. Das bedeutet, daß die Werte dieser sieben Statusvariablen sämtliche Informationen darüber enthalten, was vor einem L3-Objekt vorgekommen ist, die erforderlich sind, um das Objekt in ein oder mehrere DCF-Steuerzeichen umzuwandeln und den nächsten Status zu setzen. Dieser nächste Status ist der Status, den der Umwandlungsmechanismus zur Umwandlung des nächsten Objekts verwendet. Die Erkennung dieser sieben Variablen reduziert die Anzahl möglicher Zustände auf gerade die Anzahl möglicher Zustände der sieben binären Variablen, nämlich 128. Das hier offenbarte Verfahren erkennt zudem Zusammenhänge zwischen den sieben binären Variablen, vgl. Fig. 5. Die Existenz dieser Zusammenhänge reduziert die Anzahl möglicher Zustände auf 11. Dieser Umstand wird in Fig. 6 dargestellt. Folglich ist der Status zu Beginn eines Dokuments einer dieser 11 Zustände, und irgendein L3-Objekt, daß in einem dieser 11 Zustände vorliegt, erzeugt wiederum einen dieser 11 Zustände als "vorherigen Status" für das nächste L3- Objekt. Aufgrund dieser Zusammenhänge kann das Dokument niemals die übrigen 128 minus 11, d. h. 117 Zustände erreichen. Daher ist es unnötig, anzugeben, wie ein L3-Objekt umzuwandeln wäre, wenn es in irgendeinem der 117 unmöglichen Zustände vorläge.
• Die Umwandlung eines L3-Dokuments in ein DCF-Dokument ist durch die Angabe der Umwandlung, die die einzelnen L3-Objekte in jedem der 11 Zustände zu erfahren haben, sowie durch die Angabe der Statusänderung, die stattzufinden hat, wenn das jeweilige Objekt in jedem der möglichen 11 Zustände vorgefunden wird, implementiert. Es muß betont werden, daß nichts in einem L3-Objekt für sich allein genommen diese Statusvariablen, die auf iterative Art und Weise festgelegt worden sind, notwendigerweise identifiziert. Vorläufige Definitionen besaßen zu wenige Statusvariablen und enthielten somit zu wenig Informationen über den vorherigen Status, um die Umwandlung gewisser L3-Objekte zu erlauben. Zudem gab es zu Beginn unnötige Statusvariablen, die später verworfen werden mußten.
• Jede Stufe des iterativen Definitionsverfahrens läuft folgendermaßen ab. Ein hilfreich aussehender Satz von Variablen wurde anhand des Wissens über die Syntax und Semantik des Eingabeformats L3 und des Ausgabeformats DCF ausgewählt. Dann wurden die Anfangswerte, die die Variablen zu Beginn jedes Dokuments annehmen sollten, festgelegt und Beziehungen zwischen den ausgewählten Variablen festgestellt. Schließlich wurde versucht, das Ausgabeobjekt bzw. die Ausgabeobjekte, das bzw. die bei der Umwandlung eines jeden L3-Objekts für alle möglichen Zustände erzeugt werden sollte bzw. sollten, sowie den in diesem Fall zu erzeugenden neuen Status festzulegen. Erwies sich dies als unmöglich, wurden andere Statusvariablen ausgewählt, und die Iteration wurde so lange wiederholt, bis ein abschließbarer Ansatz gefunden wurde.
• Die sieben binären Variablen, die den Status eines L3-Dokuments jederzeit festlegen, werden zusammen mit ihren Werten am Anfang eines beliebigen Dokuments (INIT.), nach einem beliebigen Worttrennzeichen (WD) und nach einem beliebigen, kein Wort trennenden Zeichen (NWD) in der in Fig. 4 gezeigten Tabelle vorgestellt. Die Zusammenhänge zwischen diesen Variablen bedingen sich gegenseitig. Der Wert einer Variable (ja oder nein) bedingt die Werte gewisser anderer Variablen. Diese Verknüpfungen zeigt die Tabelle in Fig. 5; dort ist ein Wert, dem ein Gedankenstrich vorangeht, durch einen anderen Wert bedingt, der ohne Gedankenstrich in der gleichen Spalte steht. Die elf Zustände, die im Hinblick auf die obigen Zusammenhänge möglich sind, sind durch die elf Spalten in der in Fig. 6 abgebildeten Tabelle wiedergegeben. Die Überlappungen der Rechtecke im Statusdiagramm in Fig. 7 enthalten die gleichen Informationen. Eine der Überlappungen bedeutet einen unmöglichen zwölften Status. Dieser ist durch den schraffierten Bereich 50 dargestellt. Die Zahlen in den anderen Überlappungen entsprechen den Spaltennummern in der obigen Tabelle. Die hier offenbarten Statusvariablen und deren Zusammenhänge wurden, wie bereits erwähnt, zur Festlegung der Umwandlung eines L3-Dokuments in ein DCF-Dokument verwendet. Diese Umwandlung wird unten beschrieben und ist durch die anliegenden Entscheidungstabellen und Statusübergangsdiagramme dargestellt, die gemeinsam ein bevorzugtes Ausführungsbeispiel der vorliegenden Erfindung bilden.
• Nehmen wir Bezug auf die Fig. 8 und 9, wo ein Carrier REturn (CRE, Zeilenschaltung) die aktuelle Position des nächsten im formatierten Dokument zu druckenden druckbaren Zeichens um eine Zeile nach unten und nach links zum temporären linken Rand verschiebt. Im Fall der Bedingung 1, wenn CRE nicht nach einem Zeilenende-Zeichen steht, d. h. nach einem Anzeichen dafür, daß das Ende einer Zeile des zu formatierenden Dokuments erreicht ist, befindet sich die DCF-Ausgabedatei nicht am Anfang eines Datensatzes. Die DCF-Ausgabe, die UP aufgrund eines CRE in diesem Fall ausgibt, besteht ausschließlich aus einem End of Record (EOR, Ende des Datensatzes), das heißt, UP beendet den aktuellen DCF-Datensatz. Da dieses CRE nicht hinter einem Zeilenende-Zeichen steht, steht es auch nicht hinter einem CRE oder einem PE und beendet daher auch keinen Absatz.
• Für den Fall der Bedingung 2, wenn CRE nach einem Zeilenende- Zeichen steht, befindet sich die DCF-Ausgabedatei am Anfang eines neuen Datensatzes. In diesem Fall bewirkt ein CRE stets eine Leerzeile, d. h. einen DCF-Datensatz, der ein einziges Leerzeichen enthält. Diese Leerzeile ist ein bedingtes Absatzende in DCF, egal ob dieses CRE nach einem zuvor festgestellten CRE stand. Daher ist es erstaunlicherweise unnötig, in diesem Fall das Statusbit LAST WAS CRE (letztes Zeichen war CRE) zu benutzen, um festzustellen, ob der Absatz zu beenden ist, selbst wenn die Regel, daß "ein CRE nach einem anderen CRE einen Absatz beendet", eine wichtige wahre Aussage über L3 ist. Ein CRE nach einem beliebigen Zeilenende-Zeichen beendet einen Absatz. Da jedes PE nach einem Zeilenende-Zeichen steht, gilt dies auch für den Fall PE + CRE.
• Ein CRE setzt ENDED PAGE (Seitenende) zurück. Dies liegt daran, daß alles außer Page End (Seitenende) in einem Body-Text-Vektor, sogar ein CRE, bedeutet, daß wir uns nicht mehr unmittelbar hinter einem Required Page End (unveränderliches Seitenende) befinden. Beispielsweise dient ENDED PAGE dazu, zu verhindern, daß das APM in der L3-Sequenz " . . . RPE PE TUP APM . . . " ein zweites Steuerzeichen ".PA", d. h. eine neue Seite, und somit fälschlicherweise eine leere Seite erzeugt. Dagegen bedingt die L3-Sequenz " . . . RPE CRE PE TUP APM . . . " eine Leerzeile nach dem RPE. Durch den Seitenumbruch von DW würde ein PE zwischen das RPE und das CRE gesetzt werden. Dies ergäbe auf einem DW-Drucker eine leere Seite. Daher enthält die korrekte Umwandlung der L3- Sequenz " . . . RPE CRE PE TUP APM . . . " zwei Steuerzeichen ".PA". Das APM muß bedingen, daß die letzte Text Unit (Texteinheit) mit einem RPE enden soll, egal, ob sie selbst eines besaß oder nicht. Somit muß die Umwandlung des APM ein Steuerzeichen ".PA" enthalten. Dies ist dann sichergestellt, wenn CRE das Statusbit ENDED PAGE zurücksetzt. In der Tat müssen alle Steuerzeichen, deren Algorithmen folgen, außer ENDED PAGE aus dem gleichen Grund das Statusbit ENDED PAGE zurücksetzen. Fig. 8 zeigt die Entscheidungstabelle für die L3-Eingabe CRE. Das Statusdiagramm für diese Entscheidungstabelle ist in Fig. 9 dargestellt.
• Nehmen wir Bezug auf die Fig. 10 und 11, wo entweder Required Carrier Return (RCR, unveränderliche Zeilenschaltung) oder Index ReTurn (IRT, Zeilenschaltung ohne Zeilenanfang) die Position um eine Zeile nach unten und dann nach links zum permanenten linken Rand verschiebt. Das bedeutet, es beendet eine Zeile, bewirkt in DCF ein EOR, beendet einen Absatz, bewirkt einen Umbruch und setzt den Einzug zurück, d. h. bewirkt ein ".IN 0". Falls einer oder mehrere von ihnen bereits ausgeführt worden sind, sehen RCR bzw. IRT davon ab, überflüssige oder falsche doppelte Steuerzeichen zu schreiben. Falls sie nach einem Zeilenende-Zeichen kommen, verursachen sie eine Leerzeile, indem sie vor dem EOR ein Leerzeichen einfügen. Bei Bedingung 1, falls RCR oder IRT nicht nach einem Zeilenende-Zeichen stehen, muß die Umwandlung den DCF-Datensatz beenden, den Absatz beenden und den Einzug zurücksetzen, da dies nicht bereits erledigt worden wäre, falls ein Datensatz nicht beendet worden wäre. Im Fall der Bedingung 2', falls RCR oder IRT nach einem weiteren Zeilenende-Zeichen stehen, muß diese Umwandlung eine Leerzeile bewirken, einen Absatz beenden und den Einzug zurücksetzen. Bei Bedingung 2'', wo ein RCR oder IRT nach dem Ende eines Absatzes und somit nach einem Zeilenende, nicht jedoch nach dem Rücksetzen des Einzugs vorkommt, muß die Umwandlung eine Leerzeile bewirken und auch den Einzug zurücksetzen. Es ist zu beachten, daß auch das Steuerzeichen ".IN 0", das den Einzug zurücksetzt, einen Absatz beendet bzw. einen Umbruch bewirkt. Daher muß Bedingung 2'' mindestens so viele DCF-Steuerzeichen schreiben, wie Bedingung 2' braucht, und dieselbe Regel in der Entscheidungstabelle kann beide Fälle verarbeiten. Falls jedoch RCR bzw. IRT nach dem Rücksetzen des Einzugs vorkommen, braucht die Umwandlung lediglich eine Leerzeile zu veranlassen, egal, ob RCR bzw. IRT nach einem unveränderlichen Seitenende stehen oder nicht. Fig. 10 zeigt die Entscheidungstabelle für die L3-Eingaben RCR bzw. IRT. Das Statusdiagramm für diese Entscheidungstabelle ist in Fig. 11 dargestellt.
• Nehmen wir Bezug auf die Fig. 12 und 13, wo ein Zero Index Carrier Return (ZICR, Zeilenanfang ohne Zeilenschaltung) die aktuelle Position direkt nach links zum temporären linken Rand verschiebt. Diese Bewegung wird in DCF nur dann unterstützt, falls sich die aktuelle Position bereits am temporären linken Rand befindet; in diesem Fall bewirkt das ZICR gar keine Bewegung. Bei Bedingung 1, wenn ZICR nicht am Ende des Datensatzes vorkommt, wird es wie ein CRE per Voreinstellung umgewandelt, d. h. der DCF-Datensatz wird beendet. ZICR wird jedoch insofern nicht als CRE behandelt, daß ZICR + ZICR einen Absatz beenden. Bei Bedingung 2, den Sonderfällen, daß ein ZICR nach einem CRE oder nach einem PE kommt, bewirkt die Umwandlung ein Absatzende (.BR) ohne Rücksetzen des Einzugs. Dies wird in beiden Fällen unterstützt. Es wird im Fall CRE + ZICR unterstützt, da das CRE die aktuelle Position nach unten und nach links verschiebt und das ZICR daher keine weitere Bewegung bewirkt. Es wird im Fall PE + ZICR unterstützt, da jegliches PE einem gültigen Zeilenende-Steuerzeichen aus einem Byte folgen muß und da das PE die aktuelle Position nicht verschiebt, und somit verschiebt das ZICR die aktuelle Position nicht. Die aus den Steuerzeichen CRE + ZICR bzw. PE + ZICR bestehenden Paare werden in ".BR" umgewandelt, sofern der letzte Absatz nicht bereits beendet worden ist; in diesem Fall wird der Einzug nicht zurückgesetzt. In diesem Fall setzt das Umwandlungsverfahren das Statusbit ENDED PARAGRAPH (Absatzende) und setzt die Statusbits LAST WAS CRE (letztes Zeichen war CRE) bzw. LAST WAS PE (letztes Zeichen war PE) zurück. Es wäre genauso korrekt, die Statusbits LAST WAS CRE bzw. LAST WAS PE in gesetztem Zustand zu lassen, da jedes von mehreren ZICR-Steuerzeichen, die zufällig nach einem von diesen kommen, als Absatzende angesehen werden kann. Dies spielt keine Rolle, da das Umwandlungsverfahren keine überflüssigen Steuerzeichen ausgibt.
• Falls ZICR in irgendeiner anderen Situation vorkommt, wird durch seine Umwandlung lediglich ENDED PAGE zurückgesetzt. Die anderen Situationen sind wie folgt. Ihre Vollständigkeit und Konsistenz läßt sich erkennen, wenn man feststellt, daß jeder Bereich im Zustandsdiagramm von Fig. 13 durch ausschließlich eine Regelnummer abgedeckt ist (dabei sind Farbstifte hilfreich), oder wenn man die Entscheidungstabelle einem Analyseprogramm zuführt. Die Umwandlung für Bedingung 3 betrifft den Fall, wo ZICR nach einem Absatzende steht. In diesem Fall wird, unabhängig davon, ob ZICR nach einem CRE kommt oder nicht, nur ENDED PAGE zurückgesetzt. Bei Bedingung 4, wenn ZICR nach einem Datensatzende steht und das letzte L3-Objekt kein CRE oder PE war, ist lediglich ENDED PAGE zurückzusetzen. Es ist zu beachten, daß der Fall bestehend aus ENDED RECORD=wahr, LAST WAS CRE=falsch und ENDED WORD=falsch unmöglich ist. Um dies zu erkennen, muß zunächst festgestellt werden, daß ENDED WORD=falsch gleichzeitig ENDED PARAGRAPH=falsch bedingt. Nur CRE und ZICR beenden einen Datensatz, ohne gleichzeitig einen Absatz zu beenden. Es sieht zwar so aus, als ob auch PE dies tun könnte, in Wirklichkeit muß ein PE selbst jedoch nach einem Zeilenende-Zeichen stehen. Somit ist ZICR der einzige L3-Code, der ENDED DCF RECORD=wahr, ENDED PARAGRAPH=falsch und LAST WAS CRE=falsch ergibt. ZICR beendet aber tatsächlich ein Wort. Daher ist ENDED WORD nicht zusammen mit ENDED DCF RECORD=wahr, ENDED PARAGRAPH=falsch und LAST WAS CRE=falsch möglich. Daher enthalten viele Statusdiagramme, zum Beispiel das Statusdiagramm in Fig. 13, einen P-förmigen Bereich, der leer sein sollte. Er ist mit *4' bezeichnet und im Statusdiagramm für ZICR schraffiert dargestellt. Wäre dieser Bereich nicht leer, dann bräuchte ZICR eine Regel, die in diesem Fall ENDED WORD setzen müßte. Da er jedoch leer ist, kann er jedoch "ignoriert" und mit dem Rest von Regel 4 behandelt werden. Das heißt, daß der Eintrag unten rechts in der Entscheidungstabelle "-Y" anstelle von "Y" sein kann. Dieser Zusammenhang zwischen Statusvariablen sieht etwas zufällig aus, daher ist die Möglichkeit, daß dieser Bereich nicht leer ist, im Statusdiagramm offengelassen. Keiner der anderen Algorithmen hängt davon ab, ob dieser Bereich leer ist oder nicht. Die Entscheidungstabelle von ZICR ist in Fig. 12 dargestellt.
• Nehmen wir Bezug auf Fig. 14, wo das Ein-Byte-Steuerzeichen Page End (PE, Seitenende) in L3 das Ende einer Text Unit und das optionale Ende einer Einzelseite anzeigt. Es ist deshalb "optional", weil der Paginator grundsätzlich PE-Steuerzeichen zur Verschiebung von Seitenrändern verschieben kann. DW behandelt ein PE als ob es ein CRE wäre, mit der Ausnahme, daß ein PE niemals eine Leerzeile hinterläßt, selbst wenn ein PE stets nach einem gültigen Ein-Byte-Steuerzeichen Zeilenende kommt. In L3 steht nach einem PE stets das Ende des aktuellen Body-Text-Vektors. Sofern dies nicht der letzte Body-Text-Vektor ist, kommt als nächstes ein Text Unit Prefix gefolgt von null oder mehr formatändernden Konstruktionen, die in mehrere DCF-Steuerzeichen umgewandelt werden können.
• Falls der Umwandlungsalgorithmus auf ein PE, hex '0C', im L3- Datenstrom stößt, setzt er ein hex '0C' in den DCF-Datenstrom, so daß eine eventuelle anschließende Umwandlung HERUNTER (DOWN) den vorher bestehenden Seitenumbruch erhalten kann. Diese Umwandlung ist unabhängig vom Anfangsstatus. Bei der Umwandlung HOCH (UP) wird nach dem Byte PE kein Datensatz beendet. Würde dies doch erfolgen, erhielte das DCF-Formatierungsprogramm einen leeren Datensatz. Dies liegt daran, daß das '0C' stets an den Anfang eines Datensatzes geht, da das PE in L3 nach einem Zeilenende-Zeichen stehen muß und außerdem, weil das DCF-Formatierungsprogramm das Byte 0C überhaupt ignoriert, da durch die Umwandlung HOCH (UP) stets das Steuerzeichen ".TS 0C //" am Anfang jedes dabei erzeugten Dokuments steht.
• Das Schreiben des Bytes PE in den DCF-Datenstrom fängt einen DCF-Datensatz mit einem Byte an, das das DCF-Formatierungsprogramm ignorieren soll. Daher braucht das Statusbit ENDED DCF RECORD nicht zurückgesetzt zu werden. Müßte es zurückgesetzt werden, würden auch ENDED PARAGRAPH, UNINDENTED und ENDED PAGE zurückgesetzt. Tatsächlich setzt RPE all diese Statusbits (Fig. 15). Das auf das RPE folgende PE darf diese keinesfalls zurücksetzen. Der neue Status erinnert daran, daß das letzte L3-Objekt ein PE war, so daß das erste Zeichen im Body Text (Textkörper) der Text Unit falls nötig einen neuen Absatz beginnen kann. Der neue Status erinnert auch daran, daß das PE ein Word beendet hat. Es ist nicht möglich, ein Wort über eine physische Seitengrenze zu trennen, was sowohl beim Lesen des Texts als auch den Programmierern von Textverarbeitungen hilft.
• Ein PE bewirkt kein ".PA", da es nicht automatisch eine vom Autor erwünschte neue Seite bedingt. Daher setzt PE kein ENDED PAGE, welches ein unveränderliches Seitenende betrifft. PE setzt jedoch als einziges in einem Body-Text-Vektor ENDED PAGE nicht zurück. In einem in Seiten aufgeteilten Dokument folgt ein PE stets auf ein RPE. Würde PE ENDED PAGE zurücksetzen, würde das Ziel vereitelt, in Erinnerung zu behalten, daß ein RPE als Letztes in einem Body-Text-Vektor stand; aus diesem Grund darf beispielsweise ein AAM nicht das Steuerzeichen ".PA" ausgeben. Für PE steht kein Statusdiagramm zur Verfügung, da ein Statusdiagramm die Umwandlung viel komplexer als die Entscheidungstabelle aussehen läßt. Die Entscheidungstabelle ist in Fig. 14 dargestellt.
• Nehmen wir Bezug auf die Fig. 15 und 16, wo ein Required Page End (RPE, unveränderliches Seitenende) die Absicht des Autors kennzeichnet, eine neue Seite zu beginnen. Außerdem beendet es einen Datensatz sowie einen Absatz und es setzt den Einzug zurück, falls dies nicht bereits erfolgt ist. DW behandelt ein RPE wie ein RCR (Fig. 10 und 11), außer, daß ein RPE normalerweise selbst nach einem Zeilenende-Zeichen keine Leerzeile verursacht. Durch die Umwandlung HOCH (UP) werden RPE-Steuerzeichen in das DCF-Steuerzeichen ".PA" umgewandelt, um die Absicht des Autors zu erhalten, auch wenn DW bei einem RPE keine neue Seite beginnt, es sei denn, der DW-Benutzer hat den Seitenumbruch verlangt. Der Paginator fügt hinter jedes RPE ein PE ein, das wiederum eine neue Seite beginnt.
• UP hängt nur bei der Entscheidung, welche der möglichen Ausgaben überflüssig sein würden und daher nicht in den DCF-Datenstrom gesetzt werden, vom vorherigen Status ab. Im besonderen bewirkt ein RPE ein ".PA", selbst wenn das Statusbit ENDED PAGE bereits gesetzt ist. Dieses Statusbit dient dazu, die Erzeugung eines nicht nur überflüssigen sondern auch fehlerhaften Steuerzeichens ".PA" aufgrund von APM oder einer anderen Struktur, die ein RPE bedingt, aber niemals eine leere Seite erzeugt, zu verhindern. Mehrere auf einanderfolgende RPE-Steuerzeichen drücken die Absicht des Autors aus, Seiten leer zu lassen.
• Es ist zu beachten, daß die L3-Sequenz "Steuerzeichen Zeilenende, RPE, kein PE" zwar in L3, nicht jedoch in dem durch UP erzeugten umgewandelten Dokument eine Leerzeile bewirkt. Dies geschieht nur in einem L3-Dokument ohne Seitenumbrüche und wird nicht als Umwandlungsfehler angesehen. Fig. 15 zeigt die Entscheidungstabelle für die L3-Eingabe RPE, Fig. 16 zeigt das entsprechende Statusdiagramm.
• Nehmen wir Bezug auf die Fig. 17 und 18, wo entweder die aus Mehrbyte-Steuerzeichen, d. h. aus BLFC, SLP, STAB und ELFC bestehende Sequenz Line Format Change (LFC, Zeilenformatsänderung) oder das Mehrbyte-Steuerzeichen Return to Master Line Format (RMLF, Rückkehr zum Standardzeilenformat) nach einem Zeilenende- Zeichen stehen sollten. Bei der Umwandlung HOCH (UP) beenden beide L3-Codes einen DCF-Datensatz, falls sie aus gewissen Gründen nicht hinter einem Zeilenende-Zeichen stehen. Nötigenfalls beenden sie einen Absatz, setzen den Einzug zurück und beenden ein Wort. Bei der Umwandlung von LFC oder RMLF entsteht jedoch niemals eine Leerzeile, selbst wenn sie hinter einem Zeilenende- Steuerzeichen stehen.
• Zu beachten ist, daß die Mehrbyte-Steuerzeichen SLP und STAB in einer LFC-Sequenz oder RTMF selbst zur Erzeugung mehrerer DCF- Steuerzeichen führen können. Wie die Entscheidungstabelle bzw. das Statusdiagramm in den Fig. 17 bzw. 18 zeigen, gehen das Steuerzeichen BREAK, das Steuerzeichen UNINDENT und das Steuerzeichen END OF RECORD, die für das LFC oder RTMF als ganzes erzeugt wurden, diesen "OTHERS REQUIRED" voran.
• Der Gedanke, daß entweder LFC oder RTMF das Statusbit ENDED PAGE gesetzt lassen könnte, falls eines dieser beiden das letzte Code-Objekt in einer Text Unit ist, die andernfalls mit RPE und, bei Seitenumbruch, mit PE endet, ließe sich vernünftig begründen. Dieser Fall ergibt jedoch keinen Sinn, da APM und die anderen Strukturen, die auf ENDED PAGE achtgeben, die Änderungen durch ein LFC oder durch ein RMLF überschreiben. Der Einfachheit halber setzen LFC und RTMF daher das Statusbit ENDED PAGE zurück.
• Nehmen wir Bezug auf die Fig. 19 und 20. Darin beginnen alle L3-Ein-Byte-Steuerzeichen Required SPace, Unit BackSpace, Numeric BackSpace und BackSpace (RSP, UBS, NBS bzw. BS) einen neuen Absatz, falls sie hinter einem CRE oder einem PE stehen. Falls nicht, bewirken sie nicht einmal ein Zeilenende oder ein Wortende. Dies unterscheidet sich stark von anderen Absatzmarken. Alle anderen Absatzmarken beenden den alten Absatz. RSP, UBS, NBS oder BS beginnen einen neuen Absatz, falls eines von ihnen auf CRE oder PE folgt und falls nicht gerade ein Absatz zu Ende war.
• Der Unterschied besteht darin, daß alle Bits des von einem von ihnen erzeugten nächsten Status zurückgesetzt sind. Nachdem einer dieser L3-Codes in den DCF-Ausgabedatenstrom umgewandelt worden ist, befinden wir uns nicht am Ende eines DCF-Datensatzes, weil dieses Zeichen im Datensatz liegt, wir befinden uns nicht am Ende eines Absatzes (stattdessen befinden wir uns am zweiten Zeichen im neuen Absatz), der Einzug ist nicht unbedingt zurückgesetzt, weil der Benutzer hier einen Einzug beliebig eingeben kann, und wir können uns auch nicht an einem unveränderlichen Seitenende befinden. Hier tritt ein ungewöhnlicher Fall ein. Das DCF-Formatierungsprogramm ignoriert ein UBS. Es ist möglich, einen Datensatz zu erzeugen, der bloß das Byte UBS enthält und als leerer Datensatz behandelt wird.
• Durch die Umwandlung HOCH (UP) werden RSP, UBS, NBS und BS in ihre entsprechenden DCF-Zeichen umgewandelt. Das bedeutet, daß das Byte gleich dem Ein-Byte-Steuerzeichen in L3 ist. Falls bei Bedingung 1 eines davon auf ein CRE oder ein PE folgt und ENDED PARAGRAPH nicht bereits gesetzt ist, wird bei der Umwandlung HOCH (UP) das Steuerzeichen ".BR" ausgegeben, der Datensatz beendet, das entsprechende Zeichen in den neuen Datensatz geschrieben und alle Statusbits zurückgesetzt. Falls bei Bedingung 2 keiner von ihnen auf ein CRE oder ein PE folgt oder falls ENDED PARAGRAPH bereits gesetzt ist, wird bei der Umwandlung HOCH (UP) lediglich das entsprechende Zeichen ausgegeben und alle Statusbits zurückgesetzt. Die Tatsache, daß bei der Umwandlung HOCH (UP) für die nachstehenden Bedingungen bzw. Regeln 1 und 2 dieselben einfachen Ausgaben geschrieben werden können, begründet sich folgendermaßen.
• Es ist zu beachten, daß ein RSP, UBS, NBS oder BS, das auf ein PE "folgt", diesem PE mit einem beträchtlichen Abstand folgen kann. PE beendet stets eine Text Unit (TU). Vor dem Body-Text- Vektor einer neuen TU kann ein APM, TUFC, MT, MP oder ein anderes Formatierungszeichen stehen. Ein Formatierungszeichen beendet stets eine Zeile, einen Absatz, setzt den Einzug zurück und beendet folglich eine Seite. Daher kann der Fall, daß RSP, UBS, NBS oder BS einem PE folgen und ENDED PARAGRAPH dennoch falsch ist, nur dann auftreten, wenn der BT-Vektor der Text Unit ohne ein Formatierungszeichen begonnen hat. In diesem Fall besteht die DCF-Ausgabe aus einem Datensatz, der nur das Byte PE enthält.
• Am Anfang jedes von UP erzeugten Dokuments wird stets das Steuerzeichen ".TS 0C //" angenommen. Dieses Steuerzeichen teilt dem DCF-Formatierungsprogramm mit, daß es das Byte PE, hex '0C', ignorieren soll. Falls UP ein EOR und dann ein ".BR" ausgeben würde, bliebe dem DCF-Formatierungsprogramm ein Datensatz, der nur das Byte PE enthält. Das DCF-Formatierungsprogramm würde diesen als leeren Datensatz behandeln, was zu unerwünschten Ergebnissen führen würde. Am Anfang eines neuen Body-Text-Vektors wandelt UP Grafikzeichen um, ohne zuerst einen Datenzusatz zu beenden. UP darf jedoch nicht mit einem EOR für RLM, RSP, UBS, NBS oder BS beginnen, auch wenn das, was es aufgrund des neuen Body-Text-Vektors zuerst ausgibt, ein Steuerzeichen ist. Das DCF-Formatierungsprogramm erkennt das Steuerzeichen als solches, da es das PE-Byte in "Spalte" eins ignoriert und davon ausgeht, daß das ".BR" in "Spalte" eins beginnt.
• Auch einige andere L3-Codes beenden einen Absatz, wenn sie auf ein CRE oder ein PE folgen, erfordern jedoch keine besondere Umwandlung. Auch IT, SP, HT oder NSP beenden einen Absatz, wenn sie auf ein CRE oder PE folgen, brauchen jedoch keine besondere Umwandlung. Ein IT wird in das Steuerzeichen ".IN h" umgewandelt, wenn das IT auf ein CRE folgt. Alle anderen werden in DCF in ein SPACE (Leerzeichen) oder ein TAB (Tabulator) umgewandelt, und ein DCF-Datensatz, der mit einem SPACE oder einem TAB beginnt, wird als automatischer Umbruch behandelt. Auch ein ATF beendet einen Absatz, wenn es auf ein CRE oder ein PE folgt, besitzt für diesen Fall jedoch seine eigene, allerdings unzulängliche Umwandlung (Fig. 24). Auch CRE oder ZICR beenden einen Absatz, wenn sie auf ein CRE oder ein PE folgen, sind jedoch eigenständige Begrenzungszeichen und besitzen eigene Algorithmen (Fig. 8 und 12). Auch Release Left Margin (RLM, Freigabe des linken Rands) beendet einen Absatz, wenn es auf CRE oder PE folgt, kann jedoch in DW nicht erzeugt werden. Fig. 19 zeigt die Entscheidungstabelle der L3-Eingaben RSP, UBS, NBS und BS. Die entsprechenden Statusdiagramme sind in Fig. 20 dargestellt.
• Nehmen wir Bezug auf die Fig. 21 und 22. Dort bedingt jede der Strukturen auf oberster Ebene Activate Primary Master (APM), d. h. die Verwendung von PMF, Activate Alternate Master (AAM), d. h. die Verwendung von AMF, Text Unit Format Change (TUFC), d. h. die Verwendung von in der Struktur selbst gegebener Formatierung, und Return To Master Format (RTMF), d. h. es wird in Abhängigkeit, was zuletzt benutzt worden ist, entweder PMF oder AMF verwendet, ein Required Page End (RPE) in der vorhergehenden Text Unit, gleichgültig, ob dort tatsächlich ein RPE stand oder nicht. Falls nicht und falls es sich nicht um den Anfang des Dokuments handelt, dann hat die Umwandlung HOCH (UP) noch kein ".PA" in den DCF-Datenstrom geschrieben, muß dies aufgrund dieser Struktur aber tun.
• Diese Strukturen können nicht in einem Body-Text-Vektor vorkommen. Sie müssen nach einem PE oder am Anfang eines Dokuments auftreten. Die Architektur von L3 besagt, daß sie einen Absatz beenden, wenn sie auf ein PE folgen. Das ist nicht von Interesse, da das Verlangen eines PE gleichzeitig das Rücksetzen des Einzugs, das Beenden eines Absatzes und das Beenden eines Datensatzes erfordert. UP braucht nicht zu prüfen, ob eine dieser Strukturen auf ein PE folgt, da sie stets entweder einem PE folgen oder am Anfang eines Dokuments auftreten. UP muß aber den vorherigen Status kennen, um die Ausgabe überflüssiger bzw. falscher Steuerzeichen zu vermeiden.
• Insbesondere ist es falsch, aufgrund einer dieser Strukturen, die auf ein RPE-Steuerzeichen folgt, ein zweites darauf folgendes ".PA" zu schreiben, da dies eine leere Seite im DCF-Dokument hinterließe, die es im L3-Dokument nicht gab. Ferner können zwei dieser Strukturen zusammen vorkommen. Aus dem gleichen Grund wie eben darf nur eine davon in das Steuerzeichen ".PA" umgewandelt werden. Der Algorithmus, der dies bewerkstelligt, benutzt das Statusbit ENDED PAGE. RPE und diese Strukturen setzen dieses Bit. Wenn es gesetzt ist, verhindert es, daß diese Strukturen ein ".PA" schreiben, während RPE dies tun darf.
• Das Schreiben von ".IN 0" ist dann überflüssig, wenn dort, wo dieses Steuerzeichen vorkommt, bereits ein Absatz beendet und der Einzug zurückgesetzt worden ist. Falls schon ein Datensatz beendet worden ist, ist das Beenden eines Datensatzes falsch, weil dies einen leeren Datensatz und möglicherweise eine Leerzeile verursacht. Diese Struktur kann direkt nach einem PE-Steuerzeichen, das dann das einzige Objekt im DCF-Datensatz ist, da ein PE einem Zeilenende-Steuerzeichen nachfolgen muß, wodurch ENDED DCF RECORD gesetzt bleibt, oder nach DCF-Steuerzeichen auftreten, die aufgrund einer anderen dieser Strukturen in den Datenstrom geschrieben wurden. Auf jedes dieser DCF-Steuerzeichen folgt ein EOR, und es läßt ENDED DCF RECORD in zurückgesetztem Status und andere wie sie sind. Diese Struktur darf keine Leerzeile oder einen leeren Datensatz verursachen. Daher müssen die sich nach einem PE aus dieser Struktur ergebenden DCF- Steuerzeichen in den gleichen Datensatz geschrieben werden wie das PE selbst. Das ist normal. Die Steuerzeichen in den Entscheidungstabellen geben an, wohin EORs gehen, die dazu neigen, am Ende der Steuerzeichen und nicht vor ihnen zu stehen. Die Entscheidungstabelle der L3-Eingaben APM, AAM, TUFC und RTMF ist in Fig. 21 abgebildet. Das entsprechende Statusdiagramm ist in Fig. 22 dargestellt.
• UP wandelt die anderen L3-Objekte (Ein-Byte-Steuerzeichen, Mehrbyte-Steuerzeichen, Strukturen auf der zweiten Ebene, Strukturen auf der obersten Ebene und Parameter dieser Strukturen) unabhängig von diesen Statusbits um. Viele L3-Objekte müssen jedoch diese Statusbits zurücksetzen. Beispielsweise muß das erste Grafikzeichen nach einem Steuerzeichen RPE all diese Statusbits zurücksetzen, da wir uns nun nicht mehr am Ende des Datensatzes befinden, uns nicht mehr am Ende eines Absatzes befinden, uns nicht mehr an einem unveränderlichen Seitenende befinden, das letzte Steuerzeichen nicht CRE und nicht PE war und weil es nach dem Editieren eine Einzugstabulatorstufe ungleich Null geben kann.
• Weder oben nicht erwähnte Mehrbyte-Steuerzeichen noch Ein-Byte- Steuerzeichen über X'41' noch bisher unerwähnte Strukturen verändern die Statusbits. Zu beachten ist, daß NSP (X'E1') und SHY (X'CA') gesondert behandelt werden.
• Wenden wir uns Fig. 23 zu. Dort kann die Neu-Festlegung von Randtext nur nach einer der Strukturen auf oberster Ebene TUFC, APM, AAM oder RTMF zwischen einem PE und dem Body-Text-Vektor der nächsten Text Unit auftreten. Die Strukturen APM, AAM und RTMF definieren eine Rückkehr zum Randtext, der zuvor von L3 in DCF umgewandelt worden ist, so daß in der Mitte des Dokuments aufgrund einer dieser Strukturen keine Textumwandlung erfolgt. Im Zuge der Umwandlung des den Randtext neu definierenden L3- Objekts brauchen nur sehr wenige Informationen über den Status des vorherigen Body Texts erhalten zu bleiben. Dies liegt daran, daß TUFC, APM, AAM bzw. RTMF automatisch ein unveränderliches Seitenende und somit den Wert aller Statusbits bedingen. Die Umwandlung von Text am Anfang des nächsten Body-Text-Vektors hängt davon ab, ob er der erste Text in einer Text Unit ist, die aber nicht die erste Text Unit des Dokuments ist. Das wird dadurch signalisiert, daß das Bit LAST WAS PE gesetzt ist. UP speichert LAST WAS PE, bevor es mit der Umwandlung von Randtext beginnt, und stellt den ursprünglichen Wert hinterher wieder her.
• Das Vorliegen bzw. das Nicht-Vorliegen eines RPE am Ende des Body-Text-Vektors der vorigen Text Unit, genau vor dem PE, das diese Text Unit beendete, beeinflußt die Umwandlung von Randtext und würde auch die Umwandlung von APM oder AAM oder RTMF oder TUFC beeinflussen, wenn eines von diesen auf die Definition von Randtext folgen könnte. Die Information darüber, ob es ein abschließendes RPE gab oder nicht, enthält das Bit ENDED PAGE. Wiederum speichert UP den Wert von ENDED PAGE, bevor es mit der Umwandlung von Randtext beginnt. Mit diesen Ausnahmen kann UP nach der Umwandlung von Randtext alle Statusbits ganz einfach auf einen gegebenen Status setzen. Letzterer entspricht dem ursprünglichen Status des Dokuments und ist in Fig. 23 tabelliert.
• Somit kann UP zur Umwandlung von Margin-Text-Vektoren (Randtext- Vektoren) die selben Statusbits wie zur Umwandlung von Body- Text-Vektoren benutzen. Bevor UP damit beginnt, einen Margin- Text-Vektor umzuwandeln, setzt es einfach alle Statusbits auf ihre ursprünglichen Werte zurück. Die Umwandlung von Begrenzern verläuft auf die gleiche Weise. UP braucht nicht einmal nach den wenigen, in Randtext erlaubten Steuerzeichen zu suchen, da sie nicht vorkommen.
• Es gibt zwei Situationen, in denen UP zurückgehen muß und DCF- Code, den es bereits erzeugt hat, ändern muß. In keiner der beiden Situationen muß UP jedoch über den Datensatz, den es gerade vorbereitet, hinaus zurückgehen, so daß eine vernünftige Implementierung die Tatsache nutzt, daß UP den letzten Datensatz im Hauptspeicher zwischenpuffert, bevor es ihn auf eine Platte schreibt. Die beiden Situationen, in denen gesichert werden muß, sind Word UnderScore (WUS) und Align Text Field (ATF).
• WUS ist ein Ein-Byte-Steuerzeichen, daß im Body Text steht, damit das vorhergehende Wort unterstrichen wird. UP weiß nicht im voraus, daß dies erforderlich sein wird, wenn es mit der Verarbeitung des zu unterstreichenden Worts beginnt. UP wandelt das WUS selbst in das DCF-Steuerzeichen ".US OFF" um, um das Unterstreichen am Ende des Worts zu beenden. Das ist einfach. Das Schwierigste an dieser Aufgabe besteht darin, mit dem Unterstreichen am Anfang des vorhergehenden Worts zu beginnen.
• Es gibt zwei vernünftige Lösungsansätze für den Beginn des Unterstreichens. Beim ersten legt UP jedes Wort in einem eigenen Puffer ab, bis es erkennt, ob nach dem Wort ein WUS steht. Falls ja, schreibt UP ".US ON" in den DCF-Datenstrom bevor es das Wort in den DCF-Datenstrom schreibt. UP könnte dieses Puffern der Worte entweder im L3-Eingabedatenstrom oder im DCF-Ausgabestrom durchführen. UP hält den gesamten letzten Datensatz der DCF-Ausgabe bereit und ist stets darauf vorbereitet, zurückzuspringen und genau nach dem letzten WUS-Begrenzer ein ".US ON" einzufügen. Beim zweiten Lösungsansatz legt UP einen Zeiger auf die Position des letzten WUS-Begrenzers im Puffer ab, um so zu vermeiden, daß es in Rückwärtsrichtung danach suchen muß.
• Wenden wir uns den Fig. 24 und 25 zu. Dort ist ATF ein L3- Steuerzeichen aus mehreren Bytes, daß ein beliebiges Feld um die Position des ATF-Steuerzeichens zentriert, wohingegen das DCF- Steuerzeichen ".CE" lediglich eine ganze Zeile um die Mitte der aktuellen Eingabezone zentrieren kann. Dementsprechend ist das einzige Anwendungsgebiet von ATF, das UP korrekt umwandeln kann, der Fall, daß L3 ein Zeilenende-Zeichen, ungefähr 33 SP-Zeichen (Leerzeichen), RSP-Zeichen (unveränderliche Leerzeichen) oder die gleichwertigen HT-Zeichen (Horizontal Tab, waagerechter Tabulatur), und dann das ATF enthält. Der zu zentrierende Text steht nach dem ATF und endet am nächsten Zeilenende-Zeichen.
• Der Umwandlungsalgorithmus behandelt diese L3-Sequenz, indem er den Datensatz, der nur Leertext enthält, aussondert und indem er den Datensatz mit dem Steuerzeichen ".CE" und nicht mit einem weiteren EOR neu beginnt. Das Ende des zu zentrierenden Texts ist durch das nächste Zeilenende-Zeichen von allein gegeben.
• Diese Anforderung besitzt nur eine vernünftige Lösung, die als Regel 1 implementiert ist, vgl. das Statusübergangsdiagramm in Fig. 25. UP speichert jeden DCF-Ausgabedatensatz so lange, bis irgendein L3-Objekt in ein End Of Record in DCF umgewandelt wird, und überträgt dann den Datensatz. Wenn UP auf ein ATF stößt, prüft es, ob der Datensatz, den es bis dahin aufgebaut hat, wenigstens ein Leerzeichen und ausschließlich Leerzeichen, unveränderliche Leerzeichen und Tabulatorzeichen enthält. Sind beide Bedingungen erfüllt, kehrt UP an den Anfang dieses Datensatzes zurück, fügt ein ".CE" ein und macht mit der normalen Umwandlung weiter. UP könnte das Suchen nach rückwärts vermeiden, indem es sich merkt, ob es irgend etwas außer Leerzeichen, unveränderliche Leerzeichen oder Tabulatorzeichen in den aktuellen Datensatz geschrieben hat. Irgendwelche anderen Umwandlungsergebnisse von AFT setzen ein Bit, das den Benutzer warnt, daß die Umwandlung nicht einwandfrei abgelaufen ist.
• Die zweite Bedingung hinsichtlich der Ausrichtung von Textfeldern wird auf ähnliche Weise gehandhabt. Wenn UP auf ein ATF stößt und es gerade einen DCF-Datensatz beendet hat, erkennt es, daß der Benutzer versucht, Text um den linken Rand herum zu zentrieren, und versucht daher erst gar nicht, irgend etwas zu zentrieren. Auf diese Weise geht DW vor. Bedingung 3 verlangt jedoch die Kenntnis darüber, ob ein DCF-Datensatz abgeschlossen ist. UP behandelt den Fall, daß ein ATF vorliegt und UP gerade einen DCF-Datensatz abgeschlossen hat, als Sonderfall und folgt der Regel, daß ATF nach einem CRE oder einem PE einen Absatz beendet. UP befolgt stets die Regel, daß ATF ein Word beendet.
• Wenn UP auf ein ATF trifft, nachdem es andere Zeichen als Leerzeichen in den aktuellen DCF-Ausgabedatensatz geschrieben hat, was ein Fall für Bedingung 4 darstellt, beendet UP den Datensatz, erzeugt ein EOR, beginnt den neuen Datensatz mit dem Steuerzeichen ".CE", setzt ein Fehlermeldungsbit und macht weiter. Die ist die effektivste Umwandlung der Zentrierung eines Felds in L3, das nur Teil einer Zeile ist, zu der DCF fähig ist.
• Der letztgenannte Algorithmus behandelt auch die Tatsache, daß ein zweites ATF per se ein Begrenzungszeichen für das durch ein vorhergehendes ATF zentriertes Feld ist. Das zweite ATF tritt auf, wenn ein Datensatz das vorherige ATF und dessen Text enthält. Daher wandelt UP das zweite ATF in ein EOR und ein ".CE" um, das den neuen Datensatz beginnt. Das EOR beendet den durch das vorhergehende ATF zentrierten Text.
• 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. Dementsprechend 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 (3)

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 Schritte umfaßt:

a) Bestimmen (Fig. 4) eines Satzes von Schlüsselstatusvariablen aus allen möglichen Statusvariablen, der den Status des Quelldokuments entsprechend der Eingabesteuerobjekte in einem Datenstrom des Quelldokuments an jeder beliebigen gegebenen Stelle der Umwandlung widerspiegelt und gemeinsam identifiziert;

b) Bestimmen von jenen Kombinationen von Schlüsselzuständen (Fig. 6), die im Hinblick auf Zusammenhänge zwischen den Schlüsselstatusvariablen in Form von Verknüpfungen (Fig. 5) bei einer eventuell möglichen Umwandlung vorkommen können und dafür von Bedeutung sind, auf der Grundlage dieser Zusammenhänge;

c) für jeden Status Festlegen (Fig. 8, 10, 12, 14, 15, 17, 19, 21, 24) in Verbindung mit jedem der Eingabesteuerobjekte eines ganz bestimmten Satzes aus Ausgabesteuerobjekten, die zu dem zweiten editierbaren Dokumentenformat kompatibel sind, der in einen Datenstrom des Zieldokuments eingebracht werden soll; und

d) digitales Verarbeiten des Textes dadurch, daß, nachdem der jeweilige ganz bestimmte Satz aus Ausgabesteuerobjekten in den Datenstrom des Zieldokuments eingebracht worden ist, der nächste Status des Quelldokuments festgelegt wird (Fig. 8, 10, 12, 14, 15, 17, 19, 21, 24), damit dieser nächste Status bei der Umwandlung des nächsten Eingabesteuerobjekts berücksichtigt werden kann.

2. Verfahren gemäß Anspruch 1, das den zusätzlichen Schritt enthält, daß der tatsächliche Anfangsstatus des Quelldokuments bestimmt wird, bevor dessen Umwandlung erlaubt wird.

3. Verfahren gemäß Anspruch 1 oder 2, das den zusätzlichen Schritt enthält, daß das Vorliegen von Unterdokumenten im Quelldokument festgestellt wird und daß danach der nächste Status des Quelldokuments erhalten bleibt, damit er nach der Umwandlung des Unterdokuments verwendet werden kann.