DE69737115T2

DE69737115T2 - Verfahren und Vorrichtung zur Wiedergabe von schriftartfreien, strukturierten Dokumenten

Info

Publication number: DE69737115T2
Application number: DE69737115T
Authority: DE
Inventors: Daniel P. Ithaca Huttenlocher; William J. Mountain View Rucklidge; John Seely Palo Alto Brown
Original assignee: Xerox Corp
Current assignee: Xerox Corp
Priority date: 1996-05-23
Filing date: 1997-05-23
Publication date: 2007-04-05
Anticipated expiration: 2017-05-24
Also published as: US6275301B1; US20010043349A1; JPH1097397A; CA2205732C; BR9703310A; CA2205732A1; JP3061765B2; DE69737115D1; EP0809210A3; EP0809210A2; MX9703686A; EP0809210B1; US6529285B2

Description

Die vorliegende Erfindung bezieht sich auf strukturierte Dokumentdarstellungen und im speziellen bezieht sie sich auf strukturierte Dokumentendarstellungen, die geeignet sind für die Umrechnung in druckfähige oder am Bildschirm ausgebbare Dokumentrasterbilder, wie zum Beispiel gerasterte Binärbilder, oder andere binäre Pixel-oder Rasterbilder. Die Erfindung bezieht sich weitehin auf Datenkomprimierungsmethoden, die für die Dokumentbildumrechnung und-übermittlung geeignet sind.
Strukturierte Dokumentdarstellungen
Strukturierte Dokumentdarstellungen stellen digitale Darstellungen von Dokumenten bereit, die auf einer höheren, abstrakteren Ebene organisiert sind als lediglich eine Reihe von Pixeln. Als einfaches Beispiel, wenn diese Textseite in dem Speicher eines Computers oder in einem dauerhaften Speichermedium wie einer Festplatte, CD-ROM oder ähnlichem wie eine BIT-Map, d.h. als eine Reihe von Einsen und Nullen, die schwarze und weiße Pixel angeben, repräsentiert wird, wird solch eine Darstellung als eine unstrukturierte Darstellung der Seite angesehen. Im Gegensatz dazu, wenn die Textseite durch einen geordneten Satz an numerischen Codes repräsentiert wird, wobei jeder Code ein Symbol des Textes repräsentiert, wird solch eine Darstellung gesehen, als habe sie einen ziemlich kleinen Grad an Struktur. Wenn die Textseite durch einen Satz von Ausdrücken repräsentiert wird, die in einer Seitenbeschreibungssprache ausgedrückt sind, um Informationen über die dazugehörige Schriftart der Textsymbole, über die Positionen der Symbole auf der Seite, über die Größe der Seitenränder usw. zu enthalten, wird solch eine Darstellung als eine strukturierte Darstellung angesehen mit einer großen Menge an Struktur.
Bekannte strukturierte Dokumentdarstellungsmethoden stellen einen Kompromiss dar zwischen der Geschwindigkeit, mit der ein Dokument umgerechnet (im Englischen: rendered) werden kann, und der Aussagekraft oder der Feinheit, mit welcher dieses dargestellt werden kann. Dies ist schematisch in 1 (Stand der Technik) gezeigt. Wenn man von links nach rechts entlang der in 1 dargestellten Skala 1 schaut, erhöht sich die Aussagekraft der Darstellungen, aber die Umrechnungsgeschwindigkeit sinkt.
Deshalb rendert ASCII (American Standard Code for Information Interchange), eine rein textliche Darstellung ohne Formatierungsinformation, schnell, aber ihr fehlt Formatierungsinformation oder andere Information über die Dokumentstruktur, und ist auf der linken Seite von 1 gezeigt. Seitenbeschreibungssprachen (im Englischen: Page description languages) (PDLs), wie PostScript^® (Adobe Systems, Inc., Mountain View, CA; Internet: http://www.adobe.com) und Interpress (Xerox Corporation, Stamford, CT; Internet: http://www.xerox.com), umfassen eine große Menge an Informationen über die Dokumentstruktur, benötigen aber bedeutend mehr Zeit zum rendern als rein textliche Darstellungen, und werden auf der rechten Seite der Skala 1 gezeigt.
Skala 1 kann als eine von Dokumentdarstellungen mit steigenden Graden an Dokumentstruktur gesehen werden:

• Auf der linken Seite der Skala 1 sind rein textliche Darstellungen, wie ASCII. Diese transportieren nur die Zeichen eines Textdokumentes, mit keiner Information bezüglich Schriftart, Aufbau, oder anderer Seitenbeschreibungsinformationen, und schon gar nicht irgendwelche graphischen, bildhaften (z.B. fotographisch) oder anderen Informationen, jenseits von Text.
• Auch in der Nähe des linken Endes der Skala ist HTML (Hyper Text Markup Language), die verwendet wird, um Dokumente für das weltumspannende Netz des Internets zu repräsentieren. HTML ermöglicht etwas mehr Flexibilität als ASCII, dadurch, dass es eingebaute Graphiken, Bilder, Audio- oder Videoaufnahmen und Hypertextlinkfähigkeiten unterstützt. Allerdings fehlen HTML auch Informationen über Schriftart und Aufbau (d.h. das eigentliche Dokumentaussehen). Das heißt, dass ein HTML-Dokument durch unterschiedliche Netzclients („browser")-Programme oder unterschiedliche Computer, oder sogar durch dasselbe Netzclient-Programm, das zu unterschiedlichen Zeiten auf dem gleichen Rechner läuft, auf unterschiedliche und doch gleich „korrekten" Arten geändert (in eine bildschirmfähige oder druckfähige Ausgabe konvertiert) werden kann. Zum Beispiel variiert in vielen Netzclient-Programmen die Linienbreite des geänderten HTML-Dokuments mit der Größe des Ausgabefensters, das der Benutzer ausgewählt hat. Vergrößert man die Fenstergröße, so vergrößert sich entsprechend die Linienbreite. HTML erlaubt also eine Auszeichnung der Struk tur des Dokuments, aber keine Auszeichnung des Aufbaus des Dokuments. Man kann z.B. bestimmen, dass ein Textblock eine Überschrift einer erste Ebene ist, man kann aber nicht die Schriftart, den Blocksatz oder andere Eigenschaften exakt bestimmen, mit welchen die Überschrift der ersten Ebene gerendert wird. (Information über HTML ist im Internet von dem World Wide Web Konsortium bei http://www.w3.org/pub/WWW/MarkUp/. erhältlich).
• Am rechten Ende der Skala 1 befinden sich Seitenbeschreibungssprachen, wie PostScript und Interpress. Diese PDLs sind voll ausgestattete Programmiersprachen, die es erlauben komplexe Konstrukte für Seitenaufbau, Grafiken und anderen Dokumenteigenschaften in symbolischer Form auszudrücken.
• In der Mitte der Skala 1 sind Druckeransteuerungssprachen, wie PCL5 (Hewlett-Packard, Pato Alto, CA; Internet: http://www.hp.com/), die Funktionen für die Kurven- und Symboldarstellung enthalten.
• Auch in der Mitte der Skala 1, aber etwas näher an den PDLs befinden sich plattformübergreifende Dokumentaustauschformate. Diese umfassen das Portable Document Format (Adobe Systems, Inc.) und Common Ground (Common Ground Software, Belmont, CA; Internet: http://www.commonground.com/). Portable Document Format, oder PDF, kann in Verbindung mit einem Softwareprogramm namens Adobe Acrobat^TM verwendet werden. PDF beinhaltet einen umfassenden Satz an Zeichnungs- und Renderingsabläufen, die durch jede gegebene Funktion (verfügbare Funktionen umfassen „Zeichnen," „Füllen," „Abtrennen (im Englischen: clip)," „Text," etc.) aufgerufen werden können, beinhaltet aber nicht Programmiersprachenkonstrukte, die z.B. eine Definierung einer Zusammenstellung von Funktionen erlauben würden.

Bekannte strukturierte Dokumentdarstellungsmethoden setzen voraus, dass die Renderingsfunktionseinheit (z.B. Bildschirmtreibersoftware, Drucker-PDL-Zerlegungssoftware, oder andere Software oder Hardware zur Erstellung eines Pixelbildes aus der strukturierten Dokumentdarstellung) auf einen Satz von Symbolschriftarten Zugang hat. Deshalb kann ein Dokument, das in PDL dargestellt ist, z.B. Text aufweisen, der mit einer 12-Punkt Times New Roman-Schriftart mit 18-Punkt Arial Bold-Titeln und Fußnoten in 10- Punkt Kurier gedruckt werden soll. Für die Renderingsfunktionseinheit wird vorausgesetzt, dass sie die erforderlichen Schriftarten bereits gespeichert hat und diese für die Verwendung verfügbar hat. Das heißt, dass das Dokument selber üblicherweise keine Schriftartinformation liefert. Deshalb, wenn die Renderingsfunktionseinheit aufgerufen wird, um ein Dokument umzurechnen, für welches es nicht die erforderliche Schriftart oder Schriftarten verfügbar hat, wird die Renderingsfunktionseinheit nicht im Stande sein eine echte Umrechnung des Dokuments zu erstellen. Zum Beispiel könnte die Renderingsfunktionseinheit wechselnde Schriftarten anstatt der in der strukturierten Dokumentdarstellung spezifizierten einsetzen, oder noch schlimmer, könnte scheitern an solchen Passagen des Dokuments, für welche keine Schriftarten verfügbar sind überhaupt etwas zu rendern.
Die grundlegende Bedeutung von Schriftarten für PDLs wird z.B. durch die umfangreiche Diskussion über Schriftarten im Referenzhandbuch der Adobe Systems, Inc PostScript-Sprache (2. Auflage 1990) (im Folgenden: PostScript-Handbuch) veranschaulicht. Auf Seite 266 sagt das PostScript-Handbuch, dass ein erforderlicher Eintrag in allen Basisschriftarten, Codieren, ein „Feld von Namen" ist, „welche Zeichencodes (integers) auf Symbolnamen – die Werte in einem Feld – abbildet." Später, im Appendix E (Seiten 591-606) gibt das PostScript-Handbuch mehrere Beispiele für Schriftarten und – Codierungsvektoren.
Ein Gedanke, der für eine Schriftart grundlegend ist, ist der der Kennzeichnung, oder die semantische Bedeutung, die einem bestimmten Zeichen oder Symbol gegeben wird. Jedes Zeichen oder Symbol einer Schriftart hat eine einzigartig verknüpfte semantische Kennzeichnung. Die Kennzeichnung ermöglicht einen Schriftartaustausch: Zeichen aus unterschiedlichen Schriftarten mit demselben semantischen Kennzeichen können gegeneinander ausgetauscht werden. Zum Beispiel jeder der Zeichen 21, 22, 23, 24, 25, 26, in 2 (Stand der Technik) hat die gleiche semantische Bedeutung: Jedes stellt die Großbuchstabenform von „E," dar, dem dritten Buchstaben des Alphabets, das üblicherweise in Englisch benutzt wird. Allerdings tritt jedes in einer unterschiedlichen Schriftart auf. Aus dem Beispiel von 2 ist ersichtlich, dass Schriftartaustausch, selbst wenn es nur für ein einzelnes Zeichen ausgeführt wird, dramatisch das Ausschauen des geänderten Bildes eines Dokuments verändern kann.
Ein bekannter Drucker, der als Eingabe eine PDL-Dokumentbeschreibung akzeptiert, ist schematisch in 3 (Stand der Technik) gezeigt. Drucker 30 akzeptiert eine PDL-Beschreibung 35, die durch eine Umrechnungseinheit 31 übersetzt oder zerlegt wird, um Rasterbilder 32 der Seiten des Dokuments zu erzeugen. Rasterbilder 32 werden dann an eine Bildausgangsklemme (im Englischen: image output terminal, IOT) 33 gegeben, welche die Bilder 32 in sichtbare Kennzeichnungen auf den Papierblättern konvertiert, die für die Verwendung durch einen menschlichen Benutzer als gedruckte Ausgabe 36 ausgegeben werden. Bedauerlicherweise kann die Geschwindigkeit, mit welcher die Umrechnungseinheit 31 die Eingabe-PDL-Beschreibung zerlegen kann, im Allgemeinen nicht der Geschwindigkeit, mit welcher die IOT 33 die Papierblätter kennzeichnen und diese als Ausgabe 36 abgeben, entsprechen. Dies ist zum Teil, weil das Ergebnis der Zerlegung der PDL-Beschreibung unbestimmt ist. Wie oben erwähnt, entspricht eine PDL-Beschreibung wie die PDL-Beschreibung 35 nicht einem bestimmten Bild oder einem Satz von Bildern, ist aber anfällig für unterschiedliche Interpretationen und kann auf unterschiedliche Arten geändert werden. Deshalb wird die Umrechnungseinheit 31 zu einer Engstelle, die die insgesamte Durchsatzleistung des Druckers 30 beschränkt.
Dementsprechend wird eine besser strukturierte Dokumentdarstellungstechnik benötigt. Was insbesondere benötigt wird ist eine Art und Weise den Kompromiss zwischen Aussagekraft und Umrechnungsgeschwindigkeit zu beheben und außerdem eine Art und Weise, um der Zwangsherrschaft der Schriftartenabhängigkeit zu entfliehen.
Datenkomprimierung für Dokumentbilder
Datenkomprimierungsmethoden konvertieren große Datensätze, wie z.B. Datenfelder für Pixelbilder von Dokumenten, in kompaktere Darstellungen, von welchen die originalgroßen Datensätze entweder perfekt oder unvollständig wiederhergestellt werden können. Wenn die Wiederherstellung perfekt ist, wird die Komprimierungsmethode als verlustfrei bezeichnet; wenn die Wiederherstellung unvollständig ist, wird die Komprimierungsmethode als verlustbehaftet bezeichnet. Das heißt, eine verlustlose Komprimierung bedeutet, dass keine Information über das Originaldokumentbild unwiderruflich innerhalb des Komprimierungs/Dekomprimierungsdurchlaufs verloren geht. Mit der verlustbehafteten Komprimierung wird Information während der Komprimierung unwiderruflich verloren.
Vorzugsweise leistet eine Datenkomprimierungsmethode eine schnelle, unaufwändige Dekomprimierung und bietet eine genaue Umrechnung samt einer hohen Komprimierungsrate, so dass komprimierte Daten in einem kleinen Bereich vom Speicher oder Ablage gespeichert werden können und in einer angemessenen Menge an Zeit übertragen werden können, selbst wenn die Übertragungsbandbreite begrenzt ist.
Verlustfreie Komprimierungsmethoden werden oftmals bevorzugt, wenn digitale Bilder komprimiert werden, die aus strukturierten Dokumentdarstellungen stammen, die durch ein Computerprogramm erzeugt wurden. Beispiele beinhalten die gedruckte oder angezeigte Ausgabe von Textverarbeitungsprogrammen, Textumbruchsprogrammen, Zeichen- und Malprogrammen, Folienpräsentationsprogrammen, Tabellenprogrammen, Netzclientprogrammen und jegliche Anzahl von anderen Arten von üblicherweise verwendeten Computersoftwareprogrammen. Solche Ausgaben können z.B. Dokumentbilder sein, die aus PDL (z.B. PostScript), oder Dokumentaustauschformatdarstellungen (z.B. PDF oder Common Ground) gerendert werden. Kurz gesagt, diese Ausgaben sind Bilder, die in erster Linie aus symbolischen Darstellungen erzeugt werden, statt als optisch abgetastete Versionen von physikalischen Dokumenten zu entspringen.
Verlustbehaftete Komprimierungsmethoden können für Bilder, die aus optisch abgetasteten Versionen von physikalischen Dokumenten stammen, angemessen sein. Solche Bilder sind schon an sich mangelhafte Nachbildungen des von ihnen repräsentierten originalen Dokuments. Das ist aufgrund der Beschränkungen des Abtastprozesses (z.B. Rauschen, begrenzte Auflösung, Ausrichtungsfehler, Versatz, Verzerrung, etc.). Sofern die Bilder selbst von beschränkter Genauigkeit des Dokuments sind, kann ein zusätzlicher Verlust von Genauigkeit durch einen verlustbehafteten Komprimierungsschema unter vielen Umständen annehmbar sein.
Bekannte Codierungsmethoden, die für die verlustfreie Bildkomprimierung geeignet sind, umfassen z.B. ITU (CCITT) Gruppe-4-Codierung, die weitgehend für facsimile (Fax)-Übertragungen benutzt wird, und Joint Bilevel Image Experts Group (JBIG) Codierung, ein binärer Bildkomprimierungsstandard, der zusammen durch die CCITT und die internationale Standardorganisation (ISO) veröffentlicht wird. Bekannte Codierungsmethoden, die für die verlustbehaftete Bildkomprimierung geeignet sind, umfassen z.B. JPEG (Joint Photographic Experts Group) Codierung, die weitgehend für das Komprimieren von Graumaßstab und farbfotographischen Bildern verwendet wird, und zeichenbasierte Komprimierungsmethoden, wie die in US-A-5,303,313 offengelegte, welche für Bilder von Dokumenten benutzt werden kann, die Textzeichen und andere Symbole enthalten.
Verglichen mit verlustbehafteten Methoden bieten verlustfreie Komprimierungsmethoden natürlich eine größere Genauigkeit, besitzen aber auch bestimmte Nachteile. Insbesondere bieten sie niedrigere Komprimierungsraten, langsamere Dekomprimierungsgeschwindigkeit und andere Leistungscharakteristiken, die für bestimmte Applikationen ungeeignet sein können, wie z.B. wenn die Menge an unkomprimierten Daten groß ist und die Übertragungsbandbreite von dem Server oder einer anderen Datenquelle zu dem Endbenutzer niedrig ist. Es wäre wünschenswert, eine Komprimierungsmethode zu haben, mit den Geschwindigkeits- und Komprimierungsratenvorteilen der verlustbehafteten Komprimierung, jedoch mit der Genauigkeit und Echtheit, die nur durch verlustfreie Komprimierung geleistet wird.
Die vorliegende Erfindung stellt eine strukturierte Dokumentdarstellung bereit, die sowohl hoch ausdrucksstark ist, als auch schnell und unaufwändig zu rendern ist. Gemäß der Erfindung wird ein symbolbasierter Zeichenabgleich (im Englischen: token matching) verwendet, ein Komprimierungssystem, das bisher nur für verlustbehaftete Bildkomprimierung verwendet worden ist, um verlustfreie Komprimierungen von originalen Dokumentbildern zu erzielen, die von PDL-Darstellungen oder anderen strukturierten Dokumentdarstellungen hervorgebracht sind. Ein Dokument, das Text und Grafiken enthält, wird aus seiner originalen strukturierten Darstellung in eine zeichenbasierte Darstellung (welche selber eine strukturierte Dokumentdarstellung ist) übersetzt (im Englischen: compiled), und die zeichenbasierte Darstellung wiederum wird benutzt, um ein gerendertes Pixelbild zu erzeugen. Die zeichenbasierte Darstellung kann hohe Komprimierungsraten erreichen und kann schnell und genau gerendert werden, ohne Bezugnahme auf einen Satz von Schriftarten.
Die Erfindung ist in den Ansprüchen dargelegt.
Die vorliegende Erfindung sieht eine Methode vor, die in einem Datenverarbeitungssystem ausgeführt wird und die folgenden Schritte enthält: (a) Bereitstellen von ersten und zweiten Darstellungen eines Dokuments, wobei die ersten und zweiten Darstellungen auflösungsabhängige strukturierte Darstellungen sind und jeweils erste und zweite charakteristische Auflösungen besitzen, wobei die zweite Auflösung größer ist als die erste; (b) Bereitstellen der ersten Darstellung, aber nicht der zweiten Darstellung an einen nicht vertraulichen Empfänger in digitaler Form; (c) Konvertieren der zweiten Darstellung in eine dritte Darstellung des Dokuments, wobei die dritte Darstellung eine Darstellung in einer menschlich lesbaren, nicht digitalen Form ist; und (d) Bereitstellen der dritten Darstellung, aber nicht der zweiten Darstellung, an den nicht vertraulichen Empfänger.
Die Erfindung stellt weiter ein Verfahren bereit gemäß eines anderen Beispiels.
Vorteilhafterweise umfasst Schritt (k) das Bereitstellen einer schriftartbasierten ersten strukturierten Darstellung des Dokuments, und wobei der Erzeugungsschritt das Erzeugen einer schriftartfreien zweiten strukturierten Darstellung des Dokuments umfasst.
Vorteilhafterweise umfasst Schritt (n):(n1) Erzeugen einer Darstellung des Dokuments in der Niedrigauflösung innerhalb eines ersten Mediums aus dem zweiten Satz an digitaler Information; und (n2) Erzeugen einer Darstellung des Dokuments in der Hochauflösung innerhalb eines zweiten Mediums aus dem dritten Satz an digitaler Information.
Vorteilhafterweise umfasst der Schritt des Erzeugens der Darstellung des Dokuments in der Niedrigauflösung das Anzeigen des Dokuments in der Niedrigauflösung mit einer optischen Anzeige; und der Schritt des Erzeugens der Darstellung des Dokuments in der Hochauflösung umfasst das Drucken des Dokuments in der Hochauflösung mit einem Drucker.
Schritt (n) kann die Kommunikation des zweiten Satzes an digitaler Information in einer unsicheren Art und Weise zu einem nicht vertraulichen Empfänger, die Kommunikation des dritten Satzes an digitaler Information in einer sicheren Art und Weise zu einem vertraulichen Empfänger, das Anzeigen von wenigstens einem Teil der Niedrigauflösungsdarstellung mit einer optischen Anzeige, und/oder das Drucken von wenigstens einem Teil der Hochauflösungsdarstellung mit einer Druckvorrichtung umfassen.
Vorteilhafterweise kann Schritt (n) weiter umfassen: Kommunikation des zweiten Satzes von digitaler Information zu einem Prozessor, der einen Anzeigedienst bereitstellt (im Folgenden „der Anzeigeserver"); Speichern des zweiten Satzes von digitaler Information, das so übermittelt wurde, dass es für den Anzeigeserver erreichbar ist; Übermitteln des dritten Satzes von digitaler Information in einer sicheren Art und Weise zu einem Prozessor, der einen Druckdienst bereitstellt (im Folgenden „der Druckserver"); und Speichern des dritten Satzes von digitaler Information, das so dem Druckserver übermittelt wurde.
Das Verfahren umfasst vorteilhafterweise weiter die Schritte: Mit Hilfe des Anzeigeservers, Übermitteln von wenigstens einem Teil der Niedrigauflösungsdarstellung zu einem Empfangsprozessor (im Folgenden „der Client") ohne irgendeinen Teil der Hochauflösungsdarstellung zu dem Client zu übermitteln; Empfangen in dem Anzeigeserver einer Anfrage von dem Client um eine Ausgabe bereitzustellen, die von wenigstens einem Teil der Hochauflösungsdarstellung stammt; Übermitteln dieser Anfrage in einer sicheren Art und Weise von dem Anzeigeserver zu dem Druckserver; in Antwort auf die Anfrage, Übermitteln von wenigstens einem Teil der Hochauflösungsdarstellung in einer sicheren Art und Weise von dem Druckserver zu einer vertraulichen Ausgangseinrichtung; und Erzeugen bei der vertraulichen Ausgangseinrichtung aus der Hochauflösungsdarstellung eine Ausgabe, die eine menschlich lesbare Darstellung von wenigstens einem Teil des Dokuments umfasst. Vorteilhafterweise umfasst der letzte Erzeugungsschritt das Drucken mit einem Drucker der vertraulichen Einrichtung, einer gedruckten Darstellung von wenigstens einem Teil des Dokuments, wobei die gedruckte Darstellung eine charakteristische Auflösung besitzt, die gleich der Hochauflösung ist.
In einem Aspekt der Erfindung wird einem Prozessor ein erster Satz von digitaler Information bereitgestellt, der eine erste strukturierte Darstellung eines Dokuments enthält. Diese erste Darstellung ist eine auflösungsunabhängige Darstellung. Eine Vielzahl von Bildsammlungen ist aus der ersten Darstellung beziehbar. Jeder dieser erhältlichen Bildsammlungen umfasst mindestens ein Bild. Jedes Bild in jeder dieser Sammlungen ist ein Bild von wenigstens einem Teil des Dokuments und besitzt eine charakteristische Auflösung. Mit Hilfe eines Prozessors wird aus dem ersten Satz von digitaler Information ein zweiter Satz von digitaler Information erzeugt. Der zweite Satz umfasst eine zweite, verhältnismäßig niedrigaufgelöst strukturierten Darstellung des Dokuments. Die Niedrigauflösungsdarstellung ist eine verlustfreie Darstellung einer Niedrigauflösungsbildsammlung, die eine aus der Vielzahl von Bildsammlungen ist, die von der ersten Darstellung verfügbar ist. Jedes Bild in der Niedrigauflösungsbildsammlung hat eine verhältnismäßig geringe charakteristische Auflösung. Die Niedrigauflösungsdarstellung enthält eine Vielzahl von Zeichen und eine Vielzahl von Positionen. Der zweite Satz von digitaler Information wird erzeugt durch das Herausziehen der Niedrigauflösungstoken aus der ersten Darstellung, wobei jedes Niedrigauflösungstoken einen Satz an Daten enthält, die ein Teilbild der Niedrigauflösungsbildsammlung darstellt, und durch das Bestimmen der ersten Darstellung der Vielzahl an Positionen der Niedrigauflösungsdarstellung, wobei jede dieser Position eine Position in der Niedrigauflösungsbildsammlung eines Teilbildes aus einem der Niedrigauflösungstokens ist. Wenigstens ein solches Niedrigauflösungsteilbild besitzt eine Vielzahl von Pixeln und tritt an mehr als einer Position in der Bildsammlung auf. Mit Hilfe eines Prozessors wird ein dritter Satz von digitaler Information aus dem ersten Satz von digitaler Information erzeugt. Der dritte Satz enthält eine dritte, verhältnismäßig hochaufgelöst strukturierten Darstellung des Dokuments. Die Hochauflösungsdarstellung ist eine verlustfreie Darstellung einer Hochauflösungsbildsammlung, die eine aus der Vielzahl von Bildsammlungen ist, die aus der ersten Darstellung erhältlich sind. Jedes Bild in der Hochauflösungsbildsammlung besitzt eine verhältnismäßig hohe charakteristische Auflösung, die größer ist, als die charakteristische Auflösung der Niedrigauflösungsbildsammlung. Die Hochauflösungsdarstellung umfasst eine Vielzahl an Zeichen und eine Vielzahl an Positionen. Der dritte Satz an digitaler Information wird erzeugt durch das Extrahieren der Hochauflösungszeichen aus der ersten Darstellung, wobei jedes Hochauflösungszeichen einen Satz an Pixeldaten umfasst, welche ein Teilbild der Hochauflösungsbildsammlung darstellen, und durch das Bestimmen aus der ersten Darstellung der Vielzahl an Positionen der Hochauflösungsdarstellung, wobei jede dieser Position eine Position in der Hochauflösungsbildsammlung eines Teilbildes von einer der Hochauflösungszeichen ist. Mindestens ein solches Hochauflösungsteilbild besitzt eine Vielzahl an Pixeln und tritt an mehr als einer Position in der Bildsammlung auf. Die zweiten und dritten Sätze an digitaler Information, die so erzeugt sind, werden dann für die weitere Benutzung verfügbar gemacht.
In einem weiteren Aspekt der Erfindung werden erste und zweite Darstellungen eines Dokuments bereitgestellt, indem z.B. diese auf ein oder mehreren Servercomputern verfügbar gemacht werden, die mit einem Computernetzwerk verbunden sind, wie z.B. das Internet oder ein firmeninternes Netzwerk. Die ersten und zweiten Darstellungen sind auflösungsabhängige strukturierte Darstellungen und besitzen jeweils erste und zweite charakteristische Auflösungen, wobei die zweite Auflösung größer ist, als die Erste. Die erste Darstellung, aber nicht die zweite, wird in digitaler Form an einen nicht vertraulichen Empfänger geliefert. Zum Beispiel, die erste Darstellung kann über das Netzwerk von dem Server, auf welchem die erste Darstellung verfügbar ist, zu einem Client Computer, der mit dem Netzwerk verbunden ist, übermittelt werden. Die zweite Darstellung wird in eine dritte Darstellung des Dokuments umgewandelt, wobei die dritte Darstellung eine Darstellung in einer menschlich lesbaren, nicht digitalen Form ist. Zum Beispiel, die zweite Darstellung kann über das Netzwerk in einer sicheren Art und Weise zu einer vertraulichen Druckeinrichtung, die mit dem Netzwerk verbunden ist, übermittelt werden. Die vertrauliche Einrichtung kann dann die dritte Darstellung erzeugen, z.B. indem eine Hartkopiedarstellung des Dokuments gedruckt wird. Schlussendlich wird die dritte Darstellung, aber nicht die Zweite, zu dem nichtvertraulichen Abnehmer geliefert, indem z.B. die dritte Darstellung physikalisch zu dem nichtvertraulichen Abnehmer übermittelt wird.
In der europäischen Patentveröffentlichung 0 165 554 A1 wird ein Verfahren und eine Vorrichtung für die Zugabe und Entfernung von digitalen Wasserzeichen in einem hierarchischen Bildspeicher und Abrufsystem offenbart. Eine Bildverarbeitungsmethode wird beschrieben, in der digitale Wasserzeichen, welche verschlüsselt sind, hinzugefügt, oder aus den Bildeinzelteilen entfernt werden können. Diese Technik ermöglicht den Vorteil, dass die komplette Bildrangordnung auf einem einzelnen Speichermedium bereitgestellt ist, wobei zugelassen wird, dass auf die Wasserzeichen enthaltenden Bilder ohne Beschränkung für das Durchstöbern und Probedrucken zugegriffen wird, wohingegen die Entfernung des Wasserzeichens das Wissen und die Benutzung eines kontrollierten Codes benötigt.
Die europäische Patentveröffentlichung 0 567 800 A1 offenbart ein Datenverarbeitungssystem und Verfahren, um die Zahlung von Lizenzgebühren, beim Kopieren von Softcopy-Büchern durchzusetzen. Informationen über die Lizenzgebührzahlungen liegen dem Buch bei, wohingegen um das Buch zu lesen, der Benutzer ein spezielles Softkopie-Buchleseprogramm in seinem Arbeitsplatz anwenden muss. Ein Lizenzgebührenprogramm fängt einen Kopierbefehl ab und setzt den Kopiervorgang des Buches aus. Der Benutzer muss erst zahlen, bevor das Lizenzgebührbezahlungsprogramm erlaubt, eine Kopie des Buches zu machen.
Das United States Patent Nr. 5,504,843 stellt eine Vorrichtung und ein Verfahren dar, um einen Datenstrom von Bilddaten in einem Drucksystem zu verarbeiten. Ausdrucke werden durch eine Tätigkeit erzeugt, die durch den Datenstrom an Bilddaten, die in einer Seitenbeschreibungssprache geschrieben ist, dargestellt ist und, die ein Token besitzt, das als eine Vielzahl von Bits wiedergegeben ist. Ein Block der Bilddaten wird gelesen, um das Vorhandensein des Zeichens zu bestimmen, wohingegen eine ausgewählte Funktion initiiert wird, nachdem ein Teil des Datenstroms der Bilddaten empfangen wird, basierend auf dem Vorhandensein eines Zeichens.
Die europäische Patentveröffentlichung Nr. 0 647 921 A2 offenbart Mittel und ein Verfahren zum Beschreiben eines komplexen Farbrasterbildes als eine Sammlung von Objekten in einem hierarchischen und vorrichtungsunabhängigen Format. Ein Rasterbild wird als eine Sammlung von einzelmanipulierbaren Einzelteilobjekten beschrieben, welche aus Text- oder Grafiken stammen können.
Die Erfindung wird in Bezugnahme auf die nachstehenden Zeichnungen und detaillierte Beschreibung besser verstanden. In den Zeichnungen, in welchen gleiche Bezugszahlen gleiche Einzelteile angeben:
zeigt 1 schematisch den Kompromiss zwischen Aussagekraft gegen Umrechnungsgeschwindigkeit in strukturierten Dokumentdarstellungen des Standes der Technik;
stellt 2 Beispiele des Buchstabens „E" in verschiedenen Schriftarten des Standes der Technik dar;
zeigt 3 schematisch einen Drucker, um ein Dokument aus einer Eingangsseitenbeschreibungssprachendatei im Stand der Technik zu drucken;
veranschaulicht 4 den insgesamten Ablauf von Umwandlungen, die auf eine strukturierte Dokumentdarstellung innerhalb eines kompletten Komprimierungs-Dekomprimierungszyklus gemäß der Erfindung angewendet werden;
beschreibt 5 schematisch einen Komprimierer, um eine Eingangsseitenbeschreibungssprachdatei in eine in Zeichen übersetzte Darstellung zu konvertieren, wobei dabei ausführlicher die Umwandlungen gezeigt werden, die auf eine strukturierte Dokumentdarstellung in der Komprimierungsphase von 4 angewendet werden;
ist 6 eine Reihe von Ansichten, die zeigen, wie die Komprimierungs- und Dekomprimierungszeitabschnitte voneinander entkoppelt werden können;
beschreibt 7 schematisch einen Drucker, um ein Dokument aus einer in Token übersetzten Darstellung zu drucken;
zeigt 8 schematisch einen Bildschirmanzeiger, um ein Dokument aus einer in Zeichen übersetzten Darstellung anzuzeigen;
zeigt 9 Hardware- und Softwarekomponenten eines Systems, das geeignet ist, um eine strukturierte Darstellung eines Dokuments in eine in Zeichen übersetzte Darstellung des Dokuments zu konvertieren;
stellt 10 ein System dar, welches Einzelteile umfasst, die geeignet sind, um eine in Zeichen übersetzte Darstellung eines Dokuments in gerenderte Bilder umzuwandeln, wie z.B. druckfähige oder anzeigefähige Seitenbilder;
beschreibt 11 die Zeichen und Positionen in einem beispielhaften, stark vereinfachten, in Zeichen übersetzen Dateiformat;
ist 12 ein Diagramm der Verkapselung von Wörterbuchblöcken und Seiten (einschließlich Positionsblöcken und Resteblöcken) für ein Dokument, das in einem beispielhaften, vereinfachten, nicht überlappenden, in Token übersetzten Dateiformat dargestellt ist;
ist 13 ein Diagramm der Verkapselung von Wörterbuchblöcken und -Seiten (einschließlich Positionsblöcken und Resteblöcken) für ein Dokument, das in einem beispielhaften, vereinfachten, überlappenden, in Zeichen übersetzten Dateiformat dargestellt wird;
ist 14 ein Flussdiagramm der Schritte in der Dokumentkomprimierung;
ist 15 ein Flussdiagramm der Schritte in der Dokument-Dekomprimierung;
zeigen 16 bis 23 das in Zeichen übersetzte Dateiformat einer vorteilhaften Ausführungsform, wobei
16 das Format eines Wörterbuchblocks, einschließlich Wörterbucherweiterungen zeigt,
17 das Format einer Höhenklasse zeigt,
18 das Format eines Wörterbuchbereinigungssabschnittes zeigt,
19 das Format eines Positionsblockes, einschließlich Positionserweiterungen, zeigt,
20 das Format eines Streifens zeigt,
21 das Format eines Resteblockes zeigt,
22 die Verkapselung von Wörterbuchblöcken und Seiten für ein Dokument zeigt, das in dem in Zeichen übersetzten Dateiformat der vorteilhaften Ausführungsform dargestellt wird, und
23 die Positionsblöcke, Resteblöcke und andere Elemente einer Seite eines Dokuments in dem in Zeichen übersetzten Dateiformat der vorteilhaften Ausführungsform zeigt;
ist 24 ein Flussdiagramm, das den Arbeitsablauf eines World Wide Web-Betrachters zeigt, der Netzseiten aufbaut, die als in Zeichen übersetzte Dateien komprimiert worden sind;
beschreibt 25 ein konzeptionelles Beispiel eines schaue-jetzt-drucke-später-Netzzugangs, wie es aus der Perspektive des Netzbenutzers gezeigt wird;
stellt 26 die Codierungsphase der Erfindung für schaue-jetzt-drucke-später-Anwendungen dar;
veranschaulicht 27 ein einfaches Beispiel einer Ausführungsform der Decodierungsphase der Erfindung für schaue-jetzt-drucke-später-Anwendungen; und
zeigt 28 ein komplexeres Beispiel einer Ausführungsform der Erfindung für schaue-jetzt-drucke-später-Anwendungen.
Überblick
Gemäß der Erfindung in einer bestimmten Ausführungsform wird eine hoch ausdrucksstarke strukturierte Dokumentdarstellung, wie z.B. eine PostScript^® oder andere PDL-Darstellung, oder PDF oder andere Darstellung einer Dokumentaustauschsprache, kompiliert oder auf andere Weise in ein in Zeichen übersetztes Dateiformat umgewandelt, wie z.B. das DigiPaperformat gemäß eines Aspektes der Erfindung, der unten ausführlicher beschrieben wird. Die in Token übersetzte Darstellung wiederum kann schnell in eine unstrukturierte Darstellung des Dokuments gerendert werden, wie z.B. ein Bitmap oder ein CCITT Group-4-komprimiertes Bitmap, das gedruckt, angezeigt, gespeichert, übermittelt, etc. werden kann.
Die PDL oder andere Anfangsdarstellung des Dokuments ist imstande, in Seitenbilder auf unterschiedlichen Weisen gerendert zu werden, wie z.B. mit unterschiedlichen Bildschirm- oder Druckauflösungen, oder mit unterschiedlichen Schriftartsubstitutionen. Zum Beispiel, eine gegebene PostScriptdatei kann auf zwei verschiedenen Druckern mit unterschiedlichen Auflösungen, z.B. einen 300 dots per inch (dpi) (12 dots/mm) Drucker und ein 600 dpi (24 dots/mm) Drucker ausgedruckt werden, und der PostScript^® Übersetzer für jeden Drucker wird automatisch den Maßstab ändern, um die unterschiedlichen Auflösungen auszugleichen. Als anderes Beispiel, kann eine gegebene PostScript^®-Datei durch zwei unterschiedliche Drucker unterschiedlich gerendert werden, wenn die zwei Drucker unterschiedliche Schriftartsubstitutionen ausführen. Trotz seiner hohen Ausdrucksstärke, beschreibt also eine PDL-Darstellung eines Dokuments nicht eindeutig ein Bild des Dokuments, das durch den Drucker oder Bildschirm ausgegeben wird.
Im Gegensatz dazu ist die in Zeichen übersetzte Darstellung in einer vorteilhaften Ausführungsform einzigartig für eine bestimmte Umrechnung des Dokuments, d.h., ein bestimmtes Seitenbild oder ein Satz von Seitenbildern in einer bestimmten Auflösung. Die in Zeichen übersetzte Darstellung hat auch keine Auffassung über Schriftarten, und ist nicht auf Schriftarten angewiesen, um in eine druckfähige oder anzeigefähige Form umgewandelt zu werden.
Deshalb betrachtet das erfindungsgemäße Verfahren in einer vorteilhaften Ausführungsform eine automatische Konvertierung durch einen Computer oder einen anderen Prozessor von einer anfänglichen, auflösungsunabhängigen, strukturierten Dokumentbeschreibung, eine die nicht eine einzigartige, sichtbare Erscheinung des Dokuments definiert, in eine auflösungsabhängige strukturierte Dokumentbeschreibung, welche eine einzigartige optische Erscheinung des Dokuments definiert. Diese bildbasierte, auflösungsabhängige Beschreibung gewährleistet Genauigkeit: wohingegen ein Satz von Seitenbildern immer wieder generiert werden muss, jedes Mal wenn ein PDL-Dokument für die Anzeige den Druck oder ein anderes menschlich lesbares Medium gerendert wird, wird mit der DigiPaper-Darstellung ein Satz von Seitenbildern im Voraus nur einmal erzeugt, und wird dann effizient und verlustfrei in einem strukturierten Format dargestellt, das gespeichert, verteilt usw. werden kann. DigiPaper behält die Ausdrucksstärke der originalen PDL-Darstellung bei, ohne der Unberechenbarkeit des Renderings unterworfen zu sein, die der nicht bildbasierten Darstellung innewohnend ist. Darüber hinaus kann eine DigiPaperDarstellung eines Dokuments schneller und mit weniger rechnerischen Mehraufwand, als ein PDL-Gegenstück in eine endgültige Ausgabe umgewandelt werden.
Obwohl die DigiPaper im Zeichen übersetzte Darstellung bildbasiert ist, ist sie nicht desto trotz eine strukturierte Dokumentdarstellung; sie ist nicht bloß eine Folge von Bits, Bytes oder Stichproben. In dieser Hinsicht unterscheidet sich DigiPaper von einem Raster (z.B. Bitmap) Bild, einem CCITT Club 4 komprimierten Bild, oder Ähnlichem. Darüber hinaus erzielt DigiPaper im Gegensatz zu unstrukturierten Darstellungen bessere Bildkomprimierungsraten. Zum Beispiel erreicht DigiPaper üblicherweise eine zwei- bis zwanzigmal größere Komprimierung, als durch die Verwendung von Adobe Systems, Inc.'s Tagged Image File Format (TIFF^®) Dateiformat mit CCITT Group-4 komprimierten Bilddaten erreicht werden kann, und bietet eine Komprimierungsrate im Vergleich zu den unbearbeiteten, unkomprimierten Bilddaten von etwa 100 zu 1. In der Tat kann eine DigiPaper-Datei ungefähr die gleiche Größe haben, wie die PDL-Datei, aus welcher sie erzeugt ist.
Da DigiPaper eine schnelle, vorhersehbare Umrechnung, eine garantierte Genauigkeit, und eine gute Datenkomprimierung bietet, ist sie für eine breite Auswahl an Druck- und Anzeigeanwendungen gut geeignet. Deshalb ist das Verfahren für die Umwandlung eines Dokuments aus einer PDL- oder anderen strukturierten Dokumentdarstellung in eine DigiPaper in Zeichen übersetzte Darstellung gemäß der Erfindung ein Verfahren von großem Nutzen.
Beispielsweise kann die Erfindung verwendet werden, um den Durchsatz eines Druckers zu verbessern, wie z.B. eines Laserdruckers, eines Tintenstrahldruckers oder ähnlichem, in dem die Engstelle der Umrechnungsgeschwindigkeit eliminiert wird, die den PDL-Druckern des Standes der Technik innewohnt (siehe obige Diskussion des Druckers 30 in Verbindung mit 3). Die Engstelle kann beseitigt werden, weil DigiPaper-Dateien schnell, in vorhersehbaren Geschwindigkeiten decodiert werden können. Geschwindigkeiten von etwa fünf Seiten pro Sekunde wurden auf einem Sun SPARC-20 Arbeitsplatz unter Verwendung von 600 dpi (24 dots/mm) Bildern erreicht.
Andere Verwendungsbeispiele der Erfindung werden im Späteren beschrieben.
Komprimierungs-/Dekomprimierungsdurchlauf
4 zeigt den gesamten Ablauf der Umwandlungen, die auf eine strukturierte Darstellung eines Dokuments innerhalb eines kompletten Komprimierungs-Dekomprimierungszyklus gemäß der Erfindungin der bestimmten Ausführungsform angewendet werden. Für das Dokument, das umgewandelt werden soll, wird angenommen, dass es eins ist, das als ein Satz von einem oder mehreren binären Bildern, wie z.B. ein Dokument, das Schwarz- und Weiß-Texte und Grafiken enthält, gerendert werden kann. Eine PDL-Darstellung 40 des Dokuments, wie z.B. eine PostScript Datei, wird in einen Zeichenkompilierer 41 eingegeben, der eine in Zeichen übersetzte Darstellung 42 des Doku ments erzeugt. Die in Zeichen übersetzte Darstellung 42 wiederum wird in eine Renderings-Funktionseinheit 43 eingegeben, die ein Ausgangsbinärbild 44 produziert.
Der Zeichenübersetzer 41 wird auch als Komprimierer bezeichnet, und die in Token übersetzte Darstellung 42 wird auch als komprimierte Darstellung bezeichnet. Die in Zeichen übersetzte Darstellung 42 wird in dem Sinne komprimiert, dass sie kleiner ist als das Ausgangs-Bitmap 44. (Die in Zeichen übersetzte Darstellung 42 kann von der Größe mit der PDL-Darstellung 40 verglichen werden.) Die Erzeugung einer in Token übersetzten Dokumentdarstellung aus einer Eingangs-PDL-Dokumentdarstellung (z.B., die Erzeugung einer in Zeichen übersetzten Darstellung 42 aus Eingangs-PDL-Darstellung 40) wird deshalb die Komprimierungsphase des Umwandlungsablaufs genannt, und die Erzeugung eines Ausgangsbildes aus der in Zeichen übersetzten Darstellung (z.B., die Erzeugung des Ausgangsbinärbildes 44 aus der in Zeichen übersetzten Darstellung 42) wird als Dekomprimierungsphase der Sequenz bezeichnet.
5 zeigt wieder die PDL-Darstellung 40, die in Zeichenübersetzer 41 eingegeben wird, und die in Zeichen übersetzte Darstellung 42, die daraus erzeugt wird. Hier wird der Zeichenkompilierer 41 ausführlicher beschrieben. In dieser Ausführungsform beginnt der Zeichenkompilierer 41 mit der Verarbeitung der PDL-Darstellung 40 durch einen PDL-Zerleger 45, um eine oder mehrere Seitenbilder 46 zu erzeugen. Der PDL-Auflöser 45 ist von der Art, die üblicherweise verwendet wird, um PDL-Dateien in Ausgangsbilder für bekannte Drucker und Bildschirme zu wandeln; z.B. für eine PostScript^®-Eingangsdatei 40 kann der PDL-Zerleger 45 als ein PostScript^®-Interpreterprogramm, das durch einen Prozessor ausgeführt wird, implementiert werden. Die Seitenbilder 46 sind Bitmaps, oder komprimierte Bitmaps, die die Seiten des Dokuments darstellen. In einem gewöhnlichen Drucker oder Bildschirm würden die Bitmaps 46 ausgegeben werden, um jeweils den IOT oder Bildschirm anzusteuern. Hier allerdings werden gemäß der Erfindung die Seitenbilder 46 durch einen Zeichenübersetzer oder Komprimierer 47 komprimiert. Der Komprimierer 47 nimmt die Seitenbilder und konstruiert einen DigiPaper oder anderen in Zeichen übersetzten Datenstrom oder Datei, welche der Komprimierer 47 dann speichern, übermitteln, oder anderweitig für die weitere Verarbeitung zur Verfügung stellen kann. Somit ist der Ausgang des Komprimierers 47 die in Zeichen übersetzte Darstellung 42.
Der Komprimierer 47 kann als Software-Programm ausgeführt werden, das auf einem Prozessor abläuft.
Die Schritte, mit welchen der Komprimierer 47 die Zeichenübersetzung (Komprimierung) in dieser Ausführungsform durchführen kann, werden unten in Bezug auf 14 und den begleitenden Text beschrieben. Das DigiPaper-Dateiformat, welches in dieser Ausführungsform die bevorzugte Form für die in Zeichen übersetzte Darstellung 42 ist, und damit die bevorzugte Form für den Ausgang des Komprimierers 47, wird unten ausführlich in Bezug auf die 16 bis 23 und den begleitenden Text in den nummerierten Abschnitten 1 bis 8 beschrieben.
In 5 ist auch eine alternative Vorgehensweise gezeigt, um die in Token übersetzte Darstellung 42 zu erzeugen. Gemäß dieser Alternative ist der Zeichenübersetzer 41 so konzipiert, dass der PDL-Auflöser 45 nicht ein Standard-PDL-Auflöser ist, sondern statt dessen eng mit dem Komprimierer 47 gekoppelt ist, so dass keine Zwischenseitenbilder 46 erzeugt werden. Diese Alternative kann als direkte Kompilierung der Eingangs-PDL-Darstellung 40 in eine in Zeichen übersetzte Darstellung 42 bezeichnet werden. Dies ist durch Pfeil 49 veranschaulicht.
Die Folge von zwei Ansichten in 6 zeigt, dass die Komprimierungs- und Dekomprimierungsphasen der Umwandlungssequenz von 4 voneinander entkoppelt werden können. In der Ansicht (a) findet die Komprimierungsphase statt. Eine PDL-Dokumentbeschreibung 60 wird in einen Zeichenkompilierer 61 eingegeben, um eine in Zeichen übersetzte Darstellung 62 zu erzeugen. Die in Zeichen übersetzte Darstellung 62 wird dann für eine spätere Verwendung bei 63 gespeichert. Zum Beispiel kann die in Zeichen übersetzte Darstellung 62 in einer Datei auf einer Festplatte oder einem anderem dauerhaften Speichermedium gespeichert werden, entweder lokal oder entfernt von dem Prozessor, der die Zeichenübersetzung durchführt. In einem anderen Beispiel kann die in Zeichen übersetzte Darstellung 62 von wo immer diese erzeugt wird, zu einem anderen Ort übertragen werden. Insbesondere kann die in Zeichen übersetzte Darstellung 62 durch einen Computer erzeugt werden und über ein lokales oder Großraum-Computernetzwerk zu einem anderen Computer übertragen werden, wie z.B. einem Druck- oder Dateiserver, oder zu einem Hartkopie-Ausgabegerät, wie z.B. einen Drucker oder ein Mehrfunktionsgerät. In noch einem anderen Beispiel kann die in Zeichen über setzte Darstellung 62 kopiert und verbreitet werden. Zum Beispiel kann die in Tokenübersetzte Darstellung über ein Computernetzwerk, wie z.B. das Internet, zu einem Servercomputer übertragen werden und dort zwischengespeichert werden; danach können Kopien der in Zeichen übersetzten Darstellungen aus dem Serverzwischenspeicher von entfernten Clients aufgerufen werden.
In Ansicht (b) der 6 findet die Dekomprimierungsphase statt. Die in Zeichen übersetzte Darstellung 65 wird bei 64 durch ein Gerät erhalten, welches die Dekomprimierung und Ausgabe durchführt. Zum Beispiel kann die in Zeichen übersetzte Darstellung 65 aus einem Speicher abgerufen werden, kann über ein Computernetzwerk oder über ein Telefon (Modem) erhalten werden, oder kann von einer anderen in Zeichen übersetzten Darstellung kopiert werden. Die in Zeichen übersetzte Darstellung 65 wird in eine Rendering-Funktionseinheit 66 eingegeben, die das Dokument als ein Seitenbild oder Satz von Zeichenbildern ausgibt, die angezeigt, gedruckt, gefaxt, über ein Computernetzwerk übertragen, etc. werden oder werden können.
Obwohl in diesem Beispiel die in Zeichen übersetzte Darstellung 65 der Dekomprimierungsphase (b) als die in Zeichen übersetzte Darstellung der Komprimierungsphase (a) identifiziert werden kann, muss sie nicht als solche identifiziert werden. Die in Zeichen übersetzte Darstellung 65 kann auch z.B. eine aus einer beliebigen Anzahl von Kopien der in Zeichen übersetzten Darstellung 62 sein, die im Voraus erzeugt und verteilt wurde. Als anderes Beispiel kann die in Zeichen übersetzte Darstellung 65 eine Darstellung irgendeines Dokuments sein, welches anders ist, als das welches benutzt wurde, um die in Token übersetzte Darstellung 62 zu erzeugen. Auf jeden Fall ist die in Zeichen übersetzte Darstellung 65 vorzugsweise eine Darstellung, die aus einem Bild oder Satz von Bildern erzeugt (d.h., komprimiert) worden ist, dessen Auflösung der Ausgangsauflösung der Rendering-Funktionseinheit 66 entspricht.
Weitere Beispiele, wie eine in Zeichen übersetzte Darstellung für die spätere Verwendung gespeichert werden kann (wie bei 63) und zur Verwendung dann abgerufen wird (wie bei 64) wird unten in Bezug auf die 9 bis 10 und den begleitenden Text beschrieben.
Bestimmte Vorteile werden erreicht, indem die Komprimierungs- und Dekomprimierungsphasen wie in 6 veranschaulicht, entkoppelt werden. Insbesondere für Druckanwendungen kann die rechnerisch aufwändige und unvorhersagbar lange Aufgabe des Zerlegens der PDL vorzeitig ausgeführt werden (z.B. rechnerunabhängig durch einen dafür zugeordneten Server). Dann braucht der Drucker nur das DigiPaper in Zeichen übersetzte Format zu dekomprimieren, was schnell und effizient und in vorhersehbaren Geschwindigkeiten gemacht werden kann. Dementsprechend kann der Drucker schneller gemacht werden und zur gleichen Zeit weniger teuer, da seine Rechenhardware weniger leistungsfähig sein kann, als das was von einem herkömmlichen PDL-Drucker gefordert wird.
Einige Beispiele von Renderings-Funktionseinheiten, die für die Benutzung als Renderings-Funktionseinheit 66 geeignet sind, werden in den 7 bis 8 gezeigt. 7 beschreibt schematisch einen Drucker 76, der ein Dokument aus einer in Zeichen übersetzten Darstellung, wie z.B. einer Digipaper-Datei drucken kann. Drucker 76 ist ein Beispiel des vorher erwähnten engstellenfreien Druckers. Er ist konzipiert, um eine Eingangs in Zeichen übersetzte Darstellung zu empfangen, wie z.B. die in Zeichen übersetzte Darstellung 75, und diese Darstellung in eine gedruckte Ausgabe zu wandeln. Er muss keinen bordeigenen PDL-Zerleger haben, und seine bordeigene Rechenleistung kann dementsprechend ziemlich anspruchslos sein. Der Drucker 76 arbeitet, indem die Eingangs in Zeichen übersetzte Darstellung 75 durch einen Dekomprimierer 71 dekomprimiert wird. Der Dekomprimierer 71 kann z.B. ein bordeigener Prozessor sein, der Dekomprimierungssoftware ausführt. Alternativ kann diese auch durch zugehörige Hardware realisiert werden. Der Dekomprimierer 71 erzeugt einen Satz von einem oder mehreren Rasterbildern 72, eines für jede Seite des gedruckten Dokuments. Die Rasterbilder werden einer herkömmlichen IOT 73 bereitgestellt, die die gedruckte Ausgabe 77 erzeugt.
8 beschreibt schematisch einen Bildschirm 86, der ein, in einer Eingangs in Zeichen übersetzten Darstellung gegebenes, Dokument, wie z.B. eine Digipaper-Datei anzeigen kann. Er ist vom Entwurf ähnlich dem Drucker 76. Bildschirm 86 nimmt eine Eingangs in Zeichen übersetzte Darstellung an, wie z.B. die in Zeichen übersetzte Darstellung 85, und dekomprimiert diese mit einem Dekomprimierer 81. Der Dekomprimierer 81 erzeugt einen Satz von einem oder mehreren Rasterbildern 82, eines für jede Seite des gedruckten Dokuments. Die Rasterbilder können alle auf einmal erzeugt werden, oder auf einer je- nach-Bedarf-Basis, gemäß dem vorhandenen Bildschirmspeicher, oder anderen Beschränkungen der Umgebung, in welcher der Bildschirm 86 arbeitet. Die Rasterbilder werden einer Bildschirmstation 83 bereitgestellt, wie z.B. einer Kathodenstrahlröhre (CRT) oder einem Flachbildschirm, welcher eine Ausgabe erzeugt, die von einem Menschen gelesen werden kann.
Wie der Drucker 76 muss Bildschirm 86 keinen bordeigenen PDL-Zerleger besitzen. Deshalb, wenn z.B. der Bildschirm 86 als Teil eines persönlichen Computers oder anderem Allgemeinfunktionscomputer enthalten ist, muss der Prozessor (CPU) des Computers nicht eine hohe Rechenleistung aufwenden, um den Bildschirm 86 mit Pixeln versorgt zu halten. Dies kann vorteilhaft sei, wenn z.B. der Bildschirm 86 Dokumente rendert, die von weither empfangen werden, wie z.B. World Wide Web-Seiten.
Obwohl die Beispiele 76, 86 der Renderings-Funktionseinheit, die in 7 bis 8 gezeigt sind, Ausgabebilder erzeugen, die sofort als gedruckte oder angezeigte Seiten sichtbar sind, können andere Renderings-Funktionseinheiten andere Arten von Bildausgaben erzeugen. Insbesondere kann die Ausgabe einer Renderings-Funktionseinheit, die für die Verwendung als Renderings-Funktionseinheit 66 geeignet ist, ein codiertes Bitmap (z.B. eine CCITT Group-4 Übertragung, die durch ein entferntes Fax oder Multifunktionsgerät empfangen wird) oder ein anderes unstrukturiertes Dokumentformat sein.
Die Schritte, mit welchen der Komprimierer, wie z.B. der Komprimierer 71 und der Dekomprimierer 81, die Dekomprimierung in dieser Ausführungsform durchführen können, werden unten in Bezug auf 15 und den begleitenden Text beschrieben.
Systemkomponenten
9 zeigt Hardware- und Softwarekomponenten eines Beispielsystems, das für die Ausführung der Komprimierungsphase der Umwandlungssequenz von 4 geeignet ist. Das System von 9 enthält einen Mehrzweckcomputer 100, der über einen oder mehreren Kommunikationspfaden, wie z.B. Verbindung 129, zu einem lokalen Netzwerk (LAN) 140 und auch zu einem Großraumnetzwerk, hier als Internet 180 veranschaulicht, verbunden ist. Der Computer 100 kann über das LAN 140 mit anderen lokalen Compu ter, wie z.B. einem Dateiserver 141 kommunizieren. Der Computer 100 kann über das Internet 180 mit anderen Computern, sowohl lokal als auch entfernt, wie z.B. einem World Wide Web-Server 181, kommunizieren. Die Verbindung von Computer 100 zu dem Internet 180 kann, wie wir erkennen werden, auf mehreren Wegen hergestellt werden, z.B. direkt über die Verbindung 129, oder über das lokale Netzwerk 140, oder durch ein Modem (nicht gezeigt).
Der Computer 100 ist ein persönlicher oder Bürocomputer, der z.B. eine Arbeitsstation, persönlicher Computer, oder ein anderes Einzelbenutzer oder Mehrbenutzercomputersystem sein kann; eine beispielhafte Ausführungsform benutzt einen Sun SPARC-20 Arbeitsplatz (Sun Microsystems, Inc., Mountain View, CA). Zu Zwecken der Anschaulichkeit kann der Computer 100 in geeigneter Weise in Hardware-Einzelteile 101 und Software-Einzelteile 102 unterteilt werden; allerdings können Fachmänner absehen, dass diese Unterteilung konzeptionell und etwas willkürlich ist, und dass die Grenze zwischen Hardware und Software keine harte und feste ist. Zusätzlich kann man verstehen, dass die Grenze zwischen einem zentralen Rechner und seinen angeschlossenen Peripheriegeräten keine harte und feste ist, und dass insbesondere Komponenten, die als Peripheriegeräte in einigen Computern angesehen werden, als integrierte Teile bei anderen Computern angesehen werden. Deshalb kann die Benutzer I/O 120 eine Tastatur, eine Maus und einen Bildschirmmonitor enthalten, wobei jedes von diesen entweder als Peripheriegerät oder als Teil des Computers selbst angesehen werden kann, und kann weiterhin einen lokalen Drucker enthalten, der üblicherweise als Peripheriegerät angesehen wird. Als anderes Beispiel kann ein dauerhafter Speicher 108 eine CD-ROM Einheit (compact disc read-only memory) enthalten, die entweder peripher, oder in den Computer eingebaut ist.
Hardwarekomponenten 101 enthalten einen Prozessor (CPU) 105, einen Speicher 106, einen dauerhaften Speicher 108, eine Benutzer I/O 120 und eine Netzwerkanschlussstelle 125. Diese Komponenten sind für den Fachmann klar verständlich, und müssen hier dementsprechend nur kurz erläutert werden.
Der Prozessor 105 kann z.B. ein Mikroprozessor oder eine Ansammlung von Mikroprozessoren sein, die für einen Mehrrechnerbetrieb konzipiert sind. Es ist ersichtlich, dass die Funktion des Computers 100 in einigen Ausführungsformen durch mehrere Compu ter, die zusammenarbeiten (dezentralisierte Verarbeitung) angenommen werden können; in solchen Ausführungsformen wird die Funktionalität des Computers in dem System von 9 durch eine Kombination von diesen Computern eingenommen, und die Rechenfähigkeiten des Prozessors 105 werden durch die kombinierten Prozessoren der mehreren Rechner bereitgestellt.
Der Speicher 106 kann einen schreibgeschützten Speicher (im Englischen: read-only memory: ROM), einen Direktzugriffspeicher (im Englischen: random-access memory: RAM), einen virtuellen Arbeitsspeicher, oder andere Speichertechnologien, einzeln oder in Kombination, umfassen. Der dauerhafte Speicher 108 kann z.B. eine magnetische Festplatte, eine Diskette, oder andere dauerhafte Leseschreibdatenspeichertechnologien, einzeln oder in Kombination, umfassen. Dieser kann weiterhin Massen- oder Sicherungsspeicher umfassen, der z.B. durch ein CD-ROM oder eine andere Großraumspeichertechnologie bereitgestellt werden kann. (Beachten Sie, dass der Dateiserver 140 zusätzliche Speicherfähigkeiten bereitstellt, die der Prozessor 105 benutzen kann.) Die Benutzer I/O (im Englischen: input/output) Hardware 120 umfasst typischerweise einen visuellen Bildschirmmonitor, wie z.B. einen CRT oder Flachbildschirm, eine alphanumerische Tastatur und eine Maus oder ein anderes Zeigegerät, und kann optional weiterhin einen Drucker, einen optischen Scanner oder andere Geräte für die Benutzereingabe und Ausgabe enthalten.
Die Netzwerk I/O-Hardware 125 stellt eine Schnittstelle bereit zwischen dem Computer 100 und der Außenwelt. Spezieller ausgedruckt, erlaubt die Netzwerk I/O 125 dem Prozessor 105 mit anderen Prozessoren und Geräten über die Verbindung 129 über das LAN 140 und über das Internet 180 zu kommunizieren.
Die Softwarekomponenten 102 enthalten ein Betriebssystem 150 und einen Satz von Aufgaben, die unter der Kontrolle des Betriebssystems 150 stehen, wie z.B. ein Anwendungsprogramm 160 und, was wichtiger ist, die Zeichenkompiliersoftware 165. Das Betriebssystem 150 erlaubt dem Prozessor auch die unterschiedlichen Geräte zu kontrollieren, wie z.B. den dauerhaften Speicher 108, die Benutzer I/O 120, und die Netzwerkschnittstelle 125. Der Prozessor 105 führt die Software des Betriebssystems 150 und dessen Aufgaben 160 und 165 in Verbindung mit dem Speicher 106 und den anderen Komponenten des Computersystems 100 aus.
Die Softwareeinzelteile 102 geben dem Computer 100 die Fähigkeit, als Zeichenkompilierer gemäß der Erfindung zu fungieren. Diese Fähigkeit kann zwischen dem Betriebssystem 150 und seinen Prozessen aufgeteilt werden, wie es für die jeweiligen Umstände zweckmäßig ist.
In 9 wird die Zeichenübersetzungsfähigkeit primär durch den Prozess 165 bereitgestellt, der die Zeichenübersetzung eines Eingangs-PDL-Dokuments ausführt, gemäß den Schritten, die unten in Bezug auf die 14 und den begleitenden Text beschrieben werden. Das Eingangs-PDL-Dokument kann von unzähligen Quellen bereitgestellt werden. Insbesondere kann es als Ausgabe durch das Anwendungsprogramm 160 erzeugt werden, aus dem dauerhaften Speicher 108 oder dem Dateiserver 141 abgerufen werden, oder aus dem Internet 180, z.B. vom Webserver 181, heruntergeladen werden.
10 zeigt ein System, in welchem die Dekomprimierungsphase des Umwandlungsablaufs von 4 auf unterschiedlichen Wegen durchgeführt werden kann. Das Beispielsystem aus 10 ist als eine Obermenge des Systems aus 9 veranschaulicht; insbesondere umfasst es den Computer 100, den Dateiserver 141, den Webserver 181, das LAN 140 und das Internet 180. Darüber hinaus fügt das System von 10 mehrere Systemeinzelteile 200 hinzu, die benutzt werden können, um in zeichenübersetzte Darstellungen von Dokumenten zu rendern. Die Komponenten 200 umfassen einen zweiten Mehrzweckcomputer 210, einen Netzwerkdrucker 220, einen Druckserver 230 und ein „intelligentes" Mehrfunktionsgerät 240.
Im Arbeitsablauf des Systems aus 10 wird ein Dokument, das vorher aus einer PDL-Darstellung in eine in Zeichen übersetzte Darstellung (z.B. ein Dokument, das durch den Zeichenübersetzer 165 im Computer 100 erzeugt wurde; ein Dokument aus dem Dateiserver 141, oder dem Webserver 181) umgewandelt worden ist, über eine Netzwerkverbindung 229 für eine oder mehrere der Komponenten 210, 220, 230, 240 verfügbar gemacht. Jeder dieser Komponenten kann als eine Rendering-Funktionseinheit und insbesondere als ein Dekomprimierer fungieren. Für jede wird angenommen, dass sie Kommunikationssoftware umfasst, die dem Prozessor erlaubt, eine in Zeichen übersetzte Darstellung eines Dokuments zu erhalten, und die Dekomprimierungssoftware enthält, die dem Prozessor erlaubt, diese in Zeichen übersetzte Darstellung in Bilddaten umzuwandeln, die für eine bestimmte Form der Ausgabe geeignet sind. Die Dekomprimierungssoftware kann in der Komponente enthalten sein, oder kann zusammen mit der in Zeichen übersetzten Darstellung über das LAN 140 oder das Internet 180 über die Verbindung 929 heruntergeladen werden.
Der Computer 210 kann ein Allgemeinzweckcomputer sein mit Eigenschaften und Hardwarekomponenten ähnlich denen des Computers 100; eine beispielhafte Ausführungsform verwendet einen Sun SPARC-20 Arbeitsplatz. Computer 210 besitzt auch ähnlich wie Computer 100 Software, die ein Betriebssystem umfasst, das ein oder mehrere Prozesse steuert. Allerdings während Computer 100 Komprimierungssoftware besitzt, hat Computer 210 Dekomprimierungssoftware. Das heißt, dass die Software des Computers 210 Software umfasst, die selber den Prozessor des Computers 310 befähigt, die in Zeichen übersetzte Darstellung zu dekomprimieren, oder umfasst ansonsten Netzwerkclientsoftware, die der Prozessor ausführen kann, um die Dekomprimierungssoftware herunterzuladen, welche wiederum ausgeführt werden kann, um die in Zeichen übersetze Darstellung zu dekomprimieren. (Bitte beachten Sie, dass ein Computer natürlich sowohl Komprimierungs-, als auch Dekomprimierungssoftware in seinem Speicher geladen haben kann, und dass in manchen Fällen ein einzelner Computer sowohl als Komprimierungscomputer 100 und als Dekomprimierungscompuer 210 auftreten kann.)
Der Computer 210 ist wie gezeigt mit einem Bildschirm 211, einem lokalen Drucker 212, einem Modem 213, einem dauerhaften Speichergerät 240 und mit einer Netzwerkausgabehardware 215 verbunden. Der Computer 210 kann diese Geräte steuern, und insbesondere kann Dekomprimierungssoftware ausführen, die jeden einzelnen von diesen entspricht.
Zum Beispiel, indem der Prozessor des Computers 210 die Dekomprimierungssoftware ausführt, die für den Bildschirm 211 geeignet ist, kann er bewirken, dass eine in Zeichen übersetzte Darstellung in eine Form dekomprimiert wird, die der Bildschirm 211 anzeigen kann. Deshalb dienen der Computer 210 und der Bildschirm 211 zusammen als eine Renderings-Funktionseinheit für die visuelle Anzeige. In ähnlicher Weise kann der Computer 210 und der lokale Drucker 212 die in Zeichen übersetzte Darstellung des Doku ments als eine Hartkopieausgabe rendern. Der lokale Drucker 212 kann ein „dummer" Drucker sein, mit wenig oder keiner bordeigenen Rechenhardware, da der Computer 210 die Arbeit des Dekomprimierens macht.
Außerdem kann der Computer 210 die Dokumentbilder) in Formen umrechnen, die nicht sofort für einen Menschen lesbar sind, aber trotzdem nützlich sind. Der Computer 210 kann Dekomprimierungssoftware ausführen, die Bilddaten in einem unstrukturierten (z.B. CCITT Group-4) komprimierten Format ausgibt, welches über Telefonleitungen durch das Modem 213 übertragen werden kann. Der Computer 210 kann auch unkomprimierte oder komprimierte Bilddaten an den dauerhaften Speicher 214 für ein späteres Aufrufen ausgeben, und kann unkomprimierte oder komprimierte Bilddaten zu dem Netzwerkausgabegerät 215 für eine Übertragung irgendwohin ausgeben (z.B. zu einem anderen Computer im LAN 140 oder im Internet 180). Wenn das dekomprimierte Dokument Hypertextverbindungen oder andere Bemerkungen wie unten beschrieben enthält, kann der Computer 210 eine benutzerangezeigte Auswahl von solchen Anmerkungen übersetzen und kann diese Auswahl über das Netzwerk zusammen mit den Bilddaten übertragen.
Der Netzwerkdrucker 220 ist ein Drucker, der eigene Rechenhardware an Bord besitzt, inklusive einem CPU und Speicher. Deshalb kann der Netzwerkdrucker 220 im Gegensatz zu dem lokalen Drucker 212 seine eigene Dekomprimierung ausführen, ohne die Hilfe eines Hostrechners oder Servers. Der Netzwerkdrucker 220 ist deshalb eine ausgewachsene Umrechnungsfunktionseinheit, die fähig ist, in Zeichen übersetzte Eingabedateien in eine Hardcopyausgabe zu wandeln. In dieser Weise ist sie wie Drucker 76, der in 7 gezeigt wurde.
Mit 10 fortfahrend, ist Druckerserver 230 ein Computer, der „dumme" Drucker steuern kann, und der für die temporäre Speicherung von Dateien, die durch solche Drucker gedruckt werden sollen, verwendet werden kann. Während für den Allgemeinzweckcomputer 210 vorausgesetzt wird, dass er ein Computer ist, der durch einen Menschen interaktiv benutzt wird, ist der Druckerserver 230 ein Computer, der hauptsächlich für die Steuerung von Druckern und Druckprozessen verwendet wird. Sein Prozessor führt die Dekomprimierungssoftware aus, um Bilder zu erzeugen, die an die IOT 231 für die sofortige Druckausgabe gesendet werden können, die zu einem Druckvorschauanzeiger 232 für die vorausgehende Kontrolle vor dem Drucken gesendet werden, oder die im dauerhaften Speicher des Druckservers 230 für das spätere Drucken oder Druckvorschauanzeigen eingespielt wird (vorübergehend gespeichert).
Multifunktionsgeräte sind eine Klasse von alleinstehenden Geräten, die eine Kombination von Drucken, Kopieren, Abtasten und Faxfunktionen anbieten. Die Multifunktion 240 wird als ein „intelligentes" Gerät gesehen, das seinen eigenen Prozessor und Speicher besitzt, mit ausreichend Rechenleistung, um seine eigenen in Zeichen übersetzten Dateien ohne Hilfe von einem Hostrechner oder Server zu dekomprimieren. Hier wird gezeigt, wie es über das Netzwerkausgabegerät 220 eine Ausgabe für das Netzwerk bereitstellt; wenn ein Multifunktionsgerät 240 Software besitzt, um eine Papierbenutzerschnittstelle zu unterstützen, können die Ausgabedaten Hypertextlinkauswahlen enthalten, oder andere Informationen neben den Bilddaten. Das Multifunktionsgerät 240 wird auch gezeigt, wie es komprimierte Bilddaten an eine Facsimile-Maschine 241 bereitstellt. Zum Beispiel kann das Multifunktionsgerät 240 die Facsimile-Maschine 241 über ein herkömmliches Telefon kontaktieren, und ihm komprimierte Bilddaten im CCITT Group-4-Format zusenden. Das Faxgerät 241 empfängt die Faxübertragungen vom Multifunktionsgerät 240, wie es irgendwelche anderen Faxübertragungen empfangen würde, und druckt eine Kopie des Dokuments aus.
Fachleute werden verstehen, dass die Systeme aus den 9 bis 10 als erläuternd, nicht einschränkend gedacht sind, und dass eine große Vielfalt von Rechen-, Kommunikations-, Informations- und Dokumentverarbeitungsgeräten anstelle von oder zusätzlich zu dem, was in den 9 bis 10 gezeigt ist, verwendet werden können. Zum Beispiel schließen Verbindungen über das Internet 180 üblicherweise Packetvermittlung durch zwischenliegende Routencomputer (nicht gezeigt) ein, und der Computer 210 greift wahrscheinlich während einer typischen Webclientsitzung auf eine jegliche Anzahl von Webservern zu, inklusive, aber keineswegs auf Computer 100 und Webserver 181 beschränkt,.
In Zeichen übersetzte Darstellungen
In einer vorteilhaften Ausführungsform ist die in Zeichen übersetzte Dokumentdarstellung, die durch den Zeichenkompillierer erzeugt wurde, in dem DigiPaperformat gegliedert, welche unten im Bezug auf die 16 bis 23 erläutert werden wird. Um das Ver ständnis der Einzelheiten des DigiPaperformats zu erleichtern, werden zuerst einige vereinfachte, in Zeichen übersetzte Formate in Bezug auf die 11 bis 13 betrachtet. Diese vereinfachten Formate werden dargestellt zum Zwecke der Veranschaulichung bestimmter Ideen, die für die in der Erfindung verwendeten, in Zeichen übersetzen Darstellungen grundlegend sind, inklusive, aber keineswegs beschränkt auf DigiPaper.
11 veranschaulicht das Konzept der Token und Positionen mittels eines stark vereinfachten Beispiels. Ein einseitiges Eingangsdokument, dessen Bild 1100 gezeigt ist, enthält den Text 1101. Das Dokument kann in eine in Zeichen übersetzte Darstellung 1110 umgewandelt werden. Die in Token übersetzte Darstellung 1110 enthält einen Satz (oder Wörterbuch) von Zeichen 1111 und einen Satz von Positionen 1112.
Jedes der Zeichen 1111 stellt eine Form dar, die irgendwo in dem Dokument auftritt. Jede Form eines Zeichens ist als ein Bitmap gespeichert. Jede der Positionen 1112 bedeutet wo eines der Zeichen platziert werden soll, d.h. wo die Form des Zeichens in dem Dokument auftritt. Zum Beispiel erscheint die Form „t", welche mit dem ersten Zeichen verknüpft ist, an einer Position, dessen (X, Y) Koordinaten durch das geordnete Paar (10, 20) gegeben sind. Der Umriss „h", welcher mit dem zweiten Zeichen verknüpft ist, erscheint an einer Position, dessen (X, Y) Koordinaten durch das geordnete Paar (20, 30) gegeben sind. Im Allgemeinen enthält jede der Positionen 1112 einen Zeichenindex, d.h. einen Index, der ein bestimmtes von den Zeichen 1111 anzeigt, zusammen mit einem (X, Y) Koordinatenpaar, das aussagt, wo die angezeigte Form des Zeichens in dem Dokument stattfindet.
Um die in Zeichen übersetzte Darstellung 1110 aus dem Dokumentbild 1100 zu erzeugen, kann ein Computer die unterschiedlichen Gebilde, die in dem Dokumentbild vorkommen, erkennen und vermerken, wo diese auftreten. Zum Beispiel, wenn man von links nach rechts untersucht, beginnend mit der ersten Zeile des Textes 1101, findet der Computer als erstes die Form „t", dann die Form „h", dann das Gebilde „i", dann den Umriss „s". Der Computer erfasst jedes dieser Formen als Zeichen 1111 und speichert darin die jeweiligen Positionen als Positionen 1112. Weiter zur Rechten findet der Computer als nächstes ein weiteres „i"; da diese Form schon in dem Wörterbuch ist, braucht der Computer nur seine Position zu speichern. Der Computer setzt seine Prozedur fort, bis das komplette Dokumentbild abgetastet worden ist. Kurzum kann der Computer das Bild in Tokens übersetzen, in dem jede Form der Reihe nach gefunden wird, wobei bestimmt wird, ob diese Form schon in dem Tokenwörterbuch ist, und wenn nicht, dieses an das Wörterbuch angehängt wird und, in jedem Fall seine Position in den Satz von Positionen gespeichert wird.
Um das Bild 1100 aus der in Token übersetzten Darstellung 1110 zu rekonstruieren, kann ein Computer die Positionen 1112 der Reihe nach einlesen und für jede Position die Form des Tokens, dessen Index für die notierte (X, Y) Koordinate aufgelistet ist, übertragen. Deshalb wird ein Computer beim Rekonstruieren des Bildes 1100 das erste Token (die Form „t") zweimal verwenden, das zweite Zeichen (Umriss „h") zweimal, das dritte Zeichen (Form „i") viermal, etc. Im Allgemeinen ist die Komprimierungsrate, die durch die in Zeichen übersetzte Darstellung erreicht werden kann um so größer je öfter eine Form eines Zeichens in einem Dokument auftritt.
Beachten Sie, dass der Satz von Zeichen 1111 keine Schriftart ist. Eine in Zeichen übersetzte Darstellung eines Dokuments gemäß der Erfindung enthält keine Auffassung von semantischer Kennzeichnung oder von Charaktersätzen, enthält keine Codierung oder Abbildung von Sätzen an Charaktercodes auf Sätzen von Charakternamen. Die Formen „t", „h", „i" usw. werden nur als Formen behandelt, d.h. bestimmte Bitmaps, und nicht als Buchstaben eines Alphabets oder Mitglieder eines größeren Satzes von Charaktercodes. Die Formen tauchen in dem Wörterbuch in der Reihenfolge auf, in denen sie im Dokumentbild 1101 zuerst auftauchen, nicht in einer festen Reihenfolge. Die Formen, die in dem Dokument auftauchen, schreiben vor, was in dem Wörterbuch sein wird, und nicht andersherum.
Jegliche Formen, die wiederholt in dem Dokument auftauchen, können als Zeichenformen benutzt werden, inklusive Gebilde, die überhaupt keine symbolische Bedeutung besitzen. Die Formen, die den Text 1101 in dem Dokumentbild 1100 bilden, sind zufällig für englischsprechende Menschen als alphabetische Buchstaben wieder erkennbar, aber sie könnten genauso gut keilförmige Buchstaben oder bedeutungslose Schnörkel sein, und der Zeichenübersetzer würde diese auf die gleiche Art und Weise verarbeiten. Umgekehrt wird ein gegebener Buchstabe des Alphabets, der als zwei unterschiedliche Formen (z.B. in zwei unterschiedlichen Größen oder in zwei unterschiedlichen Schriftar ten) gerrndert werden soll, zwei unterschiedlichen Zeichen zugeordnet, eines für jede unterschiedliche Form, in welcher der Buchstabe auftritt.
Für ein Einseitendokumentbild, wie das Bild 1100, ist es nicht erforderlich, Seiteninformation in die in Zeichen übersetzten Darstellung zu kodieren. Für Mehrseitenbilder von längeren Dokumenten sollte die in Tokens übersetzte Darstellung Informationen umfassen, über welche Zeichenformen auf welchen Seiten auftauchen. Zu diesem Zweck kann ein getrennter Satz von Positionen für jede Seite des Dokuments gehalten werden. Typischerweise für in Zeichen gesetzte Darstellungen sind höhere Kompressionsraten für Mehrseitendokumente erhältlich, weil um so länger das Dokument ist, um so öfter jedes Zeichen wieder verwendet werden kann.
12 und 13 veranschaulichen wieder in einer vereinfachten Art und Weise einige unterschiedliche Möglichkeiten für Mehrseiten-Zeichenformate. 12 zeigt eine in Zeichen übersetzte Darstellung (auch eine Verkapselung genannt) 1200 eines Dokuments, dessen gerendertes Bild n Seiten lang ist. Die in Zeichen übersetzte Darstellung 1200 beginnt mit einem Dateivorsatz 1205 und einem Wörterbuchblock 1206, welches die Zeichen und ihre Formen enthält. Danach folgen Sequenzen von Blöcken für die Seiten des Mehrseitendokumentbildes. Blöcke 1211, 1212 und 1215 gehören zu Seite 1; 1221, 1222 und 1225 gehören zu Seite 2; usw. für die verbleibenden Seiten (wie durch die Auslasspunkte 1250 veranschaulicht), inklusive der Blöcke 1291, 1292 und 1295, die zu der Seite n gehören.
Für jede Seite der Darstellung 1200 gibt es einen Seitenvorsatzblock, einen Positionsblock und einen Resteblock. Zum Beispiel ist Block 1211 der Vorsatzblock für Seite 1; Block 1212 ist der Positionsblock für Seite 1; und Block 1215 ist der Resteblock für Seite 1. Der Seitenvorsatzblock weist auf den Anfang einer neuen Seite hin, und kann zusätzliche seitenspezifische Information enthalten. Der Positionsblock speichert, welche Zeichen an welche Positionen der aktuellen Seite zu setzen sind. Der Resteblock speichert ggf. die Formen, die auf dieser Seite auftauchen und die nicht in dem Tokenwörterbuch sind, wie z.B. Formen, die nur einmal in dem Dokument erscheinen.
13 zeigt eine in Zeichen übersetzte Darstellung 1300 eines Mehrseitendokuments. Nur die ersten zwei Seiten sind gezeigt, wobei der Rest des Dokuments durch die Aus lassungspunkte 1350 angedeutet ist. Das Format ist ähnlich dem der in Zeichen übersetzten Darstellung 1200 in 12, außer, dass Wörterbuchblöcke überall in der Datei miteinander verschachtelt sein können. Die in Zeichen übersetzte Darstellung 1300 beginnt mit einem Dateivorsatz 1305, gefolgt von einem Wörterbuchblock 1310, einem Seitenvorsatz 1311, einem Positionsblock 1312 und einem Resteblock 1315 für Seite 1. Wörterbuchblock 1310 enthält all die Formen, die auf Seite 1 des Dokumentbildes auftauchen. Danach macht die in Token übersetzte Darstellung auf Seite 2 mit einem zusätzlichen Wörterbuchblock 1320 weiter, gefolgt durch Seitenvorsatz 1321, Positionsblock 1322 und Resteblock 1325 für Seite 2. Der Wörterbuchbereich 1320 umfasst all die Formen, die das erste Mal auf Seite 2 des Dokumentbildes auftauchen, d.h. die Formen, die nicht erforderlich waren, um Seite 1 umzurechnen, aber die benötigt werden, um Seite 2 zu rendern. Dementsprechend werden diese neuen Formen dem Wörterbuch hinzugefügt, welches benutzt wird, um die Seite 2 zu rendern. Das Format wird auf diese Weise (Auslassungspunkte 1350) fortgesetzt, bis alle Seiten bearbeitet sind. Zusätzliche Wörterbuchblöcke können in dem Format eingebunden werden, wann immer ein neuer Satz an sich wiederholenden Formen benötigt wird, um nachfolgende Seiten des Dokumentbildes zu rendern.
In Zeichen übersetzte Darstellungserweiterungen
Das Format einer in Zeichen übersetzten Darstellung kann erweitert werden, um Informationen unterzubringen, die eigentlich nicht durch die Zeichenübersetzung betroffen sind. Zum Beispiel, wenn eine quellstrukturierte Darstellung eines Dokuments Schwarz-Weißtext enthält, zusammen mit einer Farbfotografie, kann das Bild des Farbfotos unter Verwendung von JPEG oder anderen Komprimierungstechniken komprimiert werden, und das Schwarz-Weißtextbild kann mit Hilfe von DigiPaper oder anderen Zeichenübersetzungskomprimierungen gemäß der Erfindung komprimiert werden. Das mit JPEG komprimierte Foto, oder ein Zeiger auf dieses, kann in einem Erweiterungsbereich des Positionsblockes für diese Seite gespeichert werden, wenn das in Token übersetzte Format solche Erweiterungen unterstützt. Insbesondere können Positionsblockerweiterungen positionsabhängige Informationen beinhalten, und Wörterbuchblockerweiterungen können Informationen beinhalten, die in mehr als einer Stelle des Dokuments wieder verwendet werden.
Erweiterungen können z.B. verwendet werden, um in Zeichen übersetzte Komprimierung von Hypertextdokumenten, wie z.B. World Wide Web Seiten, zu unterstützen. Wie weithin bekannt ist, kann eine Webseite Hypertextlinks zu anderen Webseiten enthalten. Wenn ein HTML Dokument, das als eine Webseite vorhergesehen ist, in eine in Zeichen übersetzte Darstellung gemäß der Erfindung komprimiert wird, kann sein anzeigbarer Text und seine gebitmapten Graphiken in Zeichen übersetzt werden und seine Linkinformation (d.h. universal resource locator, oder URL Information) in Erweiterung gespeichert werden. Wenn der gleiche Link mehr als einmal in dem Dokument verwendet wird, kann seine URL in einer Wörterbucherweiterung gespeichert werden, und die Seitenpositionen, die als aktiv angesehen werden und die diesem Link zugeordnet sind, können in Positionserweiterungen gespeichert werden. Wenn der Link nur einmal auftritt, kann sowohl die URL als auch die Seitenposition als eine Positionserweiterung gespeichert werden.
Erweiterungen können auch verwendet werden, um die in Zeichen übersetzte Komprimierung von Objekten zu unterstützen, die eingebettete Objekte enthalten, wie z.B. Microsoft OLE Objekte (Microsoft Corp., Redmond, WA). Ein eingebetteter Gegenstand, wie z.B. eine aktive Tabellenkalkulation, eingebettet in einem sonst textlichen Dokument, das mit einem Textverarbeitungsanwendungsprogramm erzeugt wurde, kann dargestellt werden, indem die entsprechende Information (z.B. ein Zeiger auf den Gegenstand) in der Positionsblockerweiterung der Seite des gerenderten Dokuments eingebaut wird, in welchem der Gegenstand auftreten soll. Wenn der Gegenstand an mehreren Punkten des Dokuments eingebaut ist, kann seine entsprechende Information in einer Wörterbucherweiterung angegeben werden.
Komprimierung und Dekomprimierungsverfahrensschritte
Die Flussdiagramme der 14 und 15 veranschaulichen jeweils, wie die Komprimierungs- und Dekomprimierungssoftware in der speziellen Ausführungsform arbeiten.
14 zeigt eine Abfolge von Schritten, um eine strukturierte Dokumentdarstellung in eine in Zeichen übersetzte Darstellung zu kompilieren. Eine strukturierte Dokumentdarstellung wie, z.B. eine PDL-Datei, wird in den Arbeitsspeicher geladen (Schritt A) und wird durch einen herkömmlichen PDL-Zerleger einmal pro Seite (Schritt B) in einen Satz von Bitmapbildern gerendert. Danach wird die in Zeichen Übersetzungskomprimierung durch den Komprimierer durchgeführt (Schritte C, D und E). Zuerst werden die Bitmapbilder analysiert, um die Formen darin zu erkennen (Schritt C). Als nächstes werden diese Formen klassifiziert, so dass mehrfache Erscheinungen derselben Form zu demselben Token zugeordnet werden können (Schritt D). Danach wird das Tokenwörterbuch, die Positionsinformation und die Reste zusammen mit jeglichen Erweiterungen, wie z.B. Hypertextlinks oder eingebettete nicht binäre Bildkomponenten, kodiert (Schritt E). Dies schließt die Erzeugung der in Zeichen übersetzten komprimierten Darstellung ab, welche dann ausgegeben wird (Schritt F).
Der Schritt der Identifizierung der Formen (Schritt C) wird in der speziellen Ausführungsform mit Hilfe einer verbundenen Komponentenanalyse ausgeführt, obwohl jegliche andere geeignete Methode verwendet werden kann. Der Schritt der Klassifizierung von Umrissen (Schritt D) wird in der bestimmten Ausführungsform mit Hilfe eines sehr einfachen, verlustfreien Klassifizierers durchgeführt: Zwei Formen werden dann, und nur dann als einander entsprechend angesehen, wenn sie bitweise identisch sind. Dieser einfache Klassifikator steht vorteilhaft im Gegensatz zu den schwerfälligen Klassifizierern, die für die in Zeichenübersetzung von abgetasteten Dokumenten im Stand der Technik verwendet werden, und deutet auf einen Vorteil der Erfindung hin: Gemäß der Erfindung ist das Dokumentbild, welches in Zeichen zu übersetzen ist, ein Bild, das direkt aus einer PDL oder anders strukturierten Dokumentbeschreibung erzeugt wird. Solche Bilder sind schon an sich frei von Rauschen, Verlusten, Verzerrungen, Abtastartefakten und ähnlichem. Deshalb ist es nicht notwendig, approximierende oder heuristische Klassifizierer zu verwenden, wie es in den bekannten Verfahren für die in Zeichenübersetzung von abgetasteten Dokumenten getan wird. Stattdessen kann eine exakte Klassifizierung verwendet werden, und zeitaufwendige und fehleranfällige heuristische Vergleiche können eliminiert werden. Insbesondere verwechselt irrtümlicherweise der genaue Klassifikator nicht zwei Symbole, wie z.B. die Zahl „1" und den Buchstaben „1", dessen Formen einander stark ähneln.
Der im Schritt B verwendete PDL-Zerleger kann z.B. der Zerleger 45 aus 5 sein. Der in den Schritten C bis E verwendete Komprimierer kann z.B. der Komprimierer 47 aus 5 sein (Ein direkter Kompilierer geht durch den Pfeil 49 aus 5 direkt von Schritt A zu Schritt E).
15 zeigt die Schritte, um eine in Zeichen übersetzte Darstellung in ein Ausgabebild umzuwandeln. Eine in Zeichen übersetzte Darstellung, wie z.B. eine DigiPaper-Datei wird in einen Arbeitsspeicher (Schritt G) geladen. Danach beginnt eine Schleife (Schritt H) in der der Dekomprimierer die Blöcke der Datei durchliest. Wenn der nächste Block ein Wörterbuchblock ist (Schritt I), wird der Wörterbuchblock gelesen (Schritt J) und seine Tokens werden zu jeglichen schon im Wörterbuch befindlichen Tokens hinzugefügt, das im Arbeitsspeicher gespeichert ist (Schritt K). Ersatzweise, wenn der nächste Block ein Seitenvorsatz ist (Schritt L) wird diese Seite dekomprimiert und gerendert (Schritte M bis Q): Der Positionsblock für die Seite wird gelesen (Schritt M); er wird in Bezug auf den Satz von Zeichen des gegenwärtige im Arbeitsspeicher gespeicherten Wörterbuchs interpretiert. Der Resteblock wird auch gelesen (Schritt N). Die in Zeichen übersetzten Symbole werden dann in ein Bitmapbild der Seite umgewandelt (Schritt O), indem die Information aus dem Positionsblock der Seite und die Zeichen in dem gegenwärtig gespeicherten Wörterbuch verwendet werden. Die einzelnen Bitmaps für die Tokens werden in ein größeres Bitmap, das gerade für die Seite aufgebaut wird, übertragen (z.B. durch Verwendung eines Bit-Bit-Vorgangs). Auch werden jegliche Erweiterungen zu diesem Zeitpunkt verarbeitet. Als Nächstes werden die Reste gerendert, wobei ihre Bitmaps auch in das größere Bitmap überführt werden (Schritt P). Das fertig gestellte Seitenbild wird zu einem Bildschirm, IOT, dauerhaften Speicher, Netzwerk, Fax oder anderem Ausgabemechanismus ausgegeben (Schritt Q). Die Schleife wird weitergeführt (Schritt H), bis die komplette in Zeichen übersetzte Darstellung (oder irgendein gewünschter Teil davon) abgearbeitet worden ist (Schritt R).
Details der DigiPaper in Zeichen übersetzten Darstellung
Die nächsten verschiedenen Abschnitte, die der Einfachheit halber mit 1 bis 8 durchnummeriert sind, stellen detailliert ein Format für die in Zeichen übersetzte Darstellung von Dokumenten vor, das in einer vorteilhaften Ausführungsform der Erfindung verwendet wird. Das Format, das in Bezug auf die 16–23 beschrieben wird, wird das DigiPaper-Format genannt, und (unnötig zu erwähnen) ist den vereinfachten, in Zeichen übersetzten Darstellungen vorzuziehen, die vorher in Bezug auf die 11–13 diskutiert wurden.
Abschnitt 1 erörtert Entwicklungskriterien, die die Gestaltung des DigiPaper-Formats beeinflusst haben. Abschnitt 2 gibt einen Überblick über die Komponenten eines komprimierten Datenstroms in diesem Format, ohne jeglichen Bezug auf die übergeordneten Strukturen des Datenstroms zu nehmen. Abschnitte 3 bis 5 geben eine detailliertere Beschreibung von jeder dieser Komponenten. Abschnitt 6 beschreibt den Algorithmus, der verwendet wird um einen Huffman-Baum zu bilden. Abschnitt 7 gibt eine Beschreibung eines übergeordneten Datenstroms, der die Komponenten einkapselt. Abschnitt 8 erörtert einige zusätzliche Aspekte dieses Datenstromformats.
Der Text der Kapitel 1 bis 8 enthält Bezüge auf die Tabellen 1 bis 12. Diese Tabellen können am Ende der ausführlichen Beschreibung gefunden werden.
1. Einführung
Merkmale, die die Entwicklung dieses Codierungsformats beeinflusst haben, umfassen:

• es sollte möglich sein, mehrere Seiten in einen einzelnen Datenstrom zu codieren, da die Komprimierung, die für Mehrseitendokumente erreicht wird, erheblich besser ist als die Komprimierung, die für Einzelseitendokumente erreicht wird.
• Wenn ein Dokument, das in diesem Format codiert wird, in eine Datei gespeichert wird, dann sollte es möglich sein, jegliche gegebene Seite wieder herzustellen, ohne alle vorherigen Seiten voll analysieren zu müssen.
• die Codierung von individuellen Werten innerhalb des Formats sollte so einfach wie möglich sein, im Einklang mit dem Ziel einer guten Komprimierung; dies erlaubt die Einsatz von preiswerten Geräten.

2. Datenstromkomponenten
Ein Datenstrom codiert ein Dokument, welches aus einer Anzahl von Seiten besteht. Der Datenstrom umfasst eine Anzahl von Wörterbuchblöcken, Positionsblöcken und Resteblöcken.
Alle Bytes werden vom MSB bis zum LSB aufgefüllt. Sofern nicht anders bestimmt, sind alle 32-Bit-Werte vorzeichenlos und werden mit Hilfe der Tabelle 1 codiert.
2.1. Wörterbuchblöcke
Ein Wörterbuchblock umfasst Informationen über eine Anzahl von Tokens. Jede Bitmap der Zeichen (und die entsprechende Größe und Breite) werden in dem Wörterbuchblock gespeichert. Manch andere Information über jedes Zeichen wird auch in dem Wörterbuchblock gespeichert. Insbesondere wird die Anzahl der Benutzungen von jedem Token (seine Verwendungsanzahl) zusammen mit dem Token codiert. Dies erlaubt dem Decodierer, einen Huffman-Baum zu bilden mit der Codierung jeder Token-Zahl.
Wörterbuchblöcke können beliebig zwischen Seiten verschachtelt werden, außer dass mindestens ein Wörterbuchblock vor dem ersten Positionsblock sein muss.
2.2. Positionsblöcke
Ein Positionsblock enthält eine Anzahl von Triple, wobei jedes eine X-Koordinate, eine Y-Koordinate und eine Token-Nummer umfasst. Die Tokens, die in jeglichem gegebenen Positionsblock referenziert werden, müssen in irgendeinem Wörterbuchblock definiert sein, welches (in dem Datenstrom) dem Positionsblock vorausgeht.
Jeder Positionsblock wird relativ zu der Vereinigung von allen vorhergehenden Wörterbuchblöcken interpretiert: es kann jegliches Zeichen von jeglichem dieser Blöcke enthalten (aber siehe Unterabschnitt 3.3). Der Decodierer muss deshalb alle Tokens in all diesen Wörterbuchblöcken berücksichtigen, und einen Huffman-Baum bilden, basierend auf der jedem Token zugehörigen Verwendungsanzahl, um die Token-Nummern zu decodieren, die in dem Positionsblock codiert sind. Einzelheiten über, wie man diesen Huffman-Baum aufbaut, werden in Abschnitt 6 gegeben.
Es kann höchstens einen Positionsblock pro Seite geben.
2.3. Resteblöcke
Ein Resteblock codiert ein Bitmap, welches alle Nichtzeichenteile einer Seite umfasst. Er kann ohne Bezug auf jeglichen Block von jeglichem Typ decodiert werden.
Es kann höchstens einen Resteblock pro Seite geben.
3. Codierung des Wörterbuchblockes
Ein Wörterbuchblock umfasst einen Satz von Tokens, die verwendet werden sollen (zusammen mit den Tokens aus den vorherigen Wörterbuchblöcken), um nachfolgende Positionsblöcke zu decodieren.
Das Format eines Wörterbuchblockes ist in 16 gezeigt. Wörterbuchblock 1600 umfasst einen ersten Wert 1610, der kurz beschrieben werden soll, der entweder eine Zeichenanzahl oder ein Wörterbuchbereinigungscode ist. Dieser wird durch ein Flag 1620 gefolgt, das andeutet, welche Codierungstabelle für die Verwendungsanzahlfür diesen Wörterbuchblock verwendet werden soll. Zusätzlich enthält Wörterbuchblock 1600 Höhenklassen (siehe Abschnitt 3.1), wie z.B. Höhenklasse 1 1630, Höhenklasse 2 1640 und weitere Höhenklassen (wie durch die Auslassungspunkte 1650 angedeutet). Nach den Höhenklassen folgt ein END-Code 1660 und ein Wörterbucherweiterungsfeld 1670.
Der erste Wert 1610 in einem Wörterbuchblock ist ein 32 Bit (vorzeichenloser) Wert, der die Anzahl von Tokens, die in diesem Block gespeichert sind, angibt. Dieser Wert, die Token-Anzahl, wird selber unter Verwendung der Codierung aus Tabelle 1 gespeichert. Wenn die Anzahl von Tokens als null spezifiziert ist, dann ist der erste Wert 1610 ein Wörterbuchbereinigungscode (da ein Wörterbuchblock, der null neue Zeichen enthält, nicht nützlich ist); für die Details über Wörterbuchbereinigungscodes siehe Unterabschnitt 3.3.
Nach der Token-Anzahl 1610 folgt ein 1-Bit-Flag 1620, das angibt, welche Codierungstabelle der Verwendungsanzahl für diesen Wörterbuchblock verwendet wird: wenn das Bit 0 ist, wird Tabelle 3 verwendet, um die Token-Verwendungsanzahlen zu codieren; wenn das Bit 1 ist, wird Tabelle 4 verwendet.
3.1. Höhenklassen
All die Zeichen, die in dem Wörterbuchblock gespeichert sind, werden gemäß ihren Höhen und Breiten sortiert, und in Höhenklassen gruppiert: Gruppen von Zeichen, die die gleiche Höhe besitzen. Alle Zeichen einer bestimmten Höhe sind in derselben Höhenklasse. Innerhalb der Höhenklasse sind sie nach zunehmender Breite sortiert.
Das Format einer Höhenklasse ist in 17 gezeigt. Höhenklasse 1700 enthält einen ersten Code 1710, eine Breite 1720 des ersten Zeichens, eine Verwendungsanzahl 1730 des Zeichens 1, eine Delta-Breite 1740 des Zeichens 2, eine Verwendungsanzahl 1750 des Tokens 2, zusätzliche Delta-Breiten und Verwendungsanzahlen für zusätzliche Tokens (wie durch die Auslassungspunkte 1760 angedeutet), einen END-Code 1770, eine Größe 1780 (in Bytes) des komprimierten Token-Bildes, und die komprimierten Token-Bilder 1790 selbst.
3.1.1. Codieren der Zeichenhöhen
Der erste Code 1710 in der Höhenklasse ist die Höhendifferenz zu der vorherigen Höhenklasse. Die Klassen erscheinen von der kleinsten (kürzesten) ab, womit diese Deltas immer positiv sind. Die Deltas werden gemäß der Tabelle 2 codiert, mit Ausnahme, dass, da die Höhe jeder Höhenklasse um mindestens eins von der vorherigen Höhenklasse abweicht, wird das Höhen-Delta um eins erniedrigt, bevor es codiert wird. Es gibt eine imaginäre Höhenklasse der Höhe null, die der ersten realen Höhenklasse vorangeht, wodurch die Höhe der ersten Klasse direkt codiert wird. Die letzte Höhenklasse wird durch einen END-Code aus der Tabelle 2 gefolgt, statt einem zulässigen Höhen-Delta-Code.
3.1.2. Codieren der Token-Breiten
Innerhalb jeder Höhenklasse werden die Tokens nach zunehmender Breite sortiert. Die Breite jedes Tokens wird durch eine Differenz zu der vorherigen Zeichenbreite dargestellt; diese ist immer nicht negativ. Die Breite 1720 des ersten Zeichens wird direkt codiert (d.h. als ein Delta zu einem imaginären Zeichen der Breite null). Die Breiten werden unter Verwendung von Tabelle 2 codiert. Bitte beachten Sie, dass die Codierung für ein Breiten-Delta w exakt die gleiche ist wie die Codierung von w + 1 als ein Höhen-Delta.
Das letzte Zeichen in jeder Höhenklasse wird durch einen END-Code aus Tabelle 2 gefolgt.
3.1.3. Codieren der Verwendungsanzahlen
Jeder Token besitzt eine dazugehörige Verwendungsanzahl. Diese ist konzeptionell die Anzahl der Male, die dieses Zeichen in all den Positionsblöcken zwischen diesem Wörterbuchblock und dem nächsten Wörterbuchblock auftritt. In einigen Fällen mag es nicht exakt dieser Wert sein (d.h. der Decodierer sollte sich nicht darauf verlassen, dass das Token exakt diese Anzahl von Malen in diesen Positionsblöcken erscheint). Diese Verwendungsanzahlen sollten nur dafür verwendet werden, die Huffman-Codierung der Zeichennummern zu bilden (siehe Abschnitt 4).
Einige Zeichen sind Einmalverwendungszeichen. Das bedeutet, dass der Komprimierer gewährleistet, dass dieses Token genau einmal verwendet wird, und so kann der Dekomprimierer imstande sein, Speicher frei zu machen, sobald er das Token verwendet hat. Typischerweise sind solchen Token groß, womit die Speicherersparnisse signifikant sind, die das dem Dekomprimierer ermöglichen kann. Für Einweg-Tokens ist die Verwendungsanzahl wirklich eins, wird aber als null codiert, um es gegenüber anderen Tokens zu unterscheiden, die zufällig nur einmal zwischen diesem Wörterbuchblock und dem nächsten verwendet werden (singletons), welche aber theoretisch später wieder verwendet werden können. Einwegzeichen sollen nicht komplett vergessen werden, sobald diese verwendet werden (sie müssen beim Erstellen der Huffman-Bäume berücksichtigt werden, selbst wenn diese nicht mehr auftreten können), aber die einzige Information, die beibehalten werden muss, ist die Größe des Zeichens und seine Position innerhalb seines Wörterbuchblockes (wird benötigt, um Verknüpfungen zu brechen, wenn der Huffman-Code des Tokens berechnet wird); seine Bildinformation kann verworfen werden.
Dies mag nach Verschwendung ausschauen – sobald das Einweg-Token in irgendeinem Positionsblock aufgetreten ist, kann es dann nicht wieder auftreten, und so wird sein Teil des Codierungsplatzes der Zeichennummer verschwendet. Allerdings nehmen Se an, dass der Dekomprimierer den Positionsblock überspringt, in dem die Verwendung des Tokens geschieht. Dies könnte z.B. passieren, weil jemand interaktiv eine Datei durch stöbert, die in diesem Format gespeichert ist, und dieser Jemand die Seite übersprungen hat, auf welcher das Einwegzeichen verwendet wurde. Ohne eine komplette Syntaxanalyse dieses übersprungenen Seitenpositionsblockes durchzuführen, würde der Dekomprimierer dann keine Möglichkeit haben zu wissen, dass das Einweg-Token verwendet worden ist; diese Extra-Syntaxanalyse (möglicherweise von mehreren ausgelassenen Seiten) ist für die interaktive Benutzung nachteilig; es führt eine unnötige Abhängigkeit zwischen den Teilen der Datei ein.
In einigen Anwendungen könnten Singletons und Einweg-Tokens nicht in dem Token-Wörterbuch gespeichert werden; sie könnten in dem Resteblock der Seite, auf der sie auftreten, codiert werden (dies bringt im Allgemeinen eine bessere Komprimierung und reduzierte Decodierer-Speichervoraussetzungen). Wenn diese in diesem Wörterbuchblock vorliegen, sollte Tabelle 3 verwendet werden, um Verwendungsanzahlen zu codieren; wenn diese nicht vorliegen, sollte Tabelle 4 verwendet werden. Das Codier-Flag-Bit der Verwendungsanzahl (in dem Wörterbuchblockvorsatz) gibt an, welche Tabelle benutzt worden ist. Bitte beachten Sie, dass Tabelle 4 keine Verwendungsanzahlen von 0 oder 1 codieren kann.
3.1.4. Codieren von Token-Bildern
Alle Token-Bilder innerhalb einer Höhenklasse werden von links nach rechts in der gleichen Reihenfolge (d.h. sortiert nach zunehmender Breite) verkettet, wobei der erste (kleinste), ganz links angeordnet ist. Dieses einzelne Bild wird dann CCITT Gruppe-4 komprimiert. Die Group-4-Komprimierung verwendet keine EOL-Codes, und füllt Bytes von MSB nach LSB auf.
Die Länge (in ganzen Bytes) der Codierung wird als ein 32-Bit-Wert unter Verwendung von Tabelle 1 ausgegeben. Das komprimierte Bild wird dann herausgeschrieben, wobei am nächsten Byte-Rand in der Datei begonnen wird. Die nächste Höhenklasse beginnt am Byte-Rand, der dem komprimierten Bild folgt; deshalb beginnt und endet das Gruppe-4-komprimierte Bild der Höhenklasse an einer Byte-Grenze.
In einigen Fällen steigert die Gruppe-4-Komprimierung des Bildes der Höhenklasse seine Größe. Wenn dies passiert, könnte der Codierer das Bild-Bitmap unkomprimiert spei chern. Er zeigt dies an, indem er sagt, dass die Länge des gespeicherten Bitmaps null Bytes ist. Dies ist eine unmögliche Byte-Anzahl für das Ergebnis der Komprimierung, da keine Höhenklasse leer ist, so dass der Decodierer diese Situation erkennen kann. Die Größe des Höhenklassen-Bitmaps ist dem Decodierer zu diesem Zeitpunkt bekannt, womit er die Anzahl von Bytes, die er wirklich verbraucht, kennt. Jede Reihe der Bitmap ist bis zum Ende einer Byte-Grenze aufgefüllt.
3.2. Wörterbuch-Blockerweiterungen
Nach der letzten Höhenklasse kann der Wörterbuchblock Erweiterungen enthalten. In diesem Moment ist dieser Abschnitt des Wörterbuchblockes im Großteil undefiniert. Es wird angenommen, dass es verwendet wird, um Zusatzinformationen über die Tokens in dem Wörterbuchblock zu speichern; z.B. welche ASCII-Symbole diese repräsentieren, wenn dies bestimmt worden ist.
Der einzige Teil des Erweiterungsabschnittes, welcher in dieser Ausführungsform definiert ist, ist das Längenfeld. Sofort nach der letzten Höhenklasse befindet sich ein 32-Bit-Wert (der gespeichert ist unter Verwendung der Codierung in Tabelle 1), der die Größe, in Bytes, des Wörterbuchblockerweiterungsfeldes angibt. Das Erweiterungsfeld selber beginnt, wenn überhaupt vorhanden, an der nächsten Byte-Grenze. Wenn es keine Erweiterungen gibt, sollte eine Länge von 0 angegeben werden.
3.3. Wörterbuchbereinigungscodes
Wenn der Wert der Anzahl von Zeichenfeldern in einem Wörterbuchblock null ist, dann zeigt dies an, dass ein Wörterbuchbereinigungscode vor diesen Wörterbuchblock gestellt ist. Solche Bereinigungscodes senken Speichervoraussetzungen in dem Dekomprimierer, ebenso wie sie die Speichereffizienz verbessern, indem die Anzahl von Tokens in dem Huffman-Baum reduziert wird, und somit die Anzahl von Bits, die benötigt werden, um Token-Nummern in nachfolgenden Positionsblöcken zu codieren. Sie zeigen an, dass das Zeichenwörterbuch, welches in dem Dekomprimierer gespeichert ist, gelöscht werden sollte. Allerdings könnten einige Zeichen aus vorherigen Wörterbuchblöcken (denjenigen, von welchen der Komprimierer glaubt, dass sie in der Zukunft am Wahrscheinlichsten nützlich sein werden) beibehalten werden.
Das Format dieses Bereinigungsfeldes ist in 18 gezeigt. Das Wörterbuchbereinigungsfeld 1800 enthält einen Wert 1810, welches die Anzahl der Tokens angibt, die beibehalten werden sollen 1810, gefolgt von den Huffman-Codes für die beibehaltenen Tokens (z.B. Code 1820 für das erste beibehaltene Token, Code 1830 für das zweite, etc., zusätzliche Codes werden hier durch die Auslassungspunkte 1840 dargestellt). Nach den Huffman-Codes folgt ein Wert 1850, der die Anzahl von neuen Zeichen in diesem Wörterbuchblock angibt.
Das Löschfeld tritt sofort nach dem "Null-Zeichen in diesem Wörterbuchblock"-Flag auf, welches sein Vorhandensein andeutet. Die Anzahl von Zeichen, die beibehalten werden sollen 1810, werden mit Hilfe von Tabelle 1 codiert. Der letzte Wert in dem Feld ist die Anzahl von neuen Zeichen in diesem Wörterbuchblock; der Wörterbuchblock verläuft dann wie gewöhnlich weiter. Beachten Sie, dass der Huffman-Baum erstellt werden muss, ebenso wie es für einen Positionsblock an dieser Stelle der Datei gewesen wäre.
4. Positionsblöcke
Positionsblöcke codieren binäre Bilder, indem eine Abfolge von (Token-Position, Token-Nummer) Paaren abgespeichert werden. Ein Positionsblock beinhaltet nicht die Größe des Bildrechtecks, welches es darstellt; dies wird einer anderen Schicht des Dateiformats überlassen.
Die innerhalb jeglichem Positionsblock verwendeten Tokens können von irgendeinem Wörterbuchblock gezogen werden, der in der Datei vorangeht (ausgenommen, dass ein vorhergehender Wörterbuchblock einen Wörterbuchlöschcode beinhaltet hat; siehe Unterabschnitt 3.3.). Die Zeichen werden durch ihre Huffman-Codes angesprochen. Diese werden berechnet, indem alle vorherigen Wörterbuchblöcke (logischerweise) zusammen verknüpft werden, und dann wird ein Huffman-Baum von den Verwendungsanzahlen der Zeichen in diesen Blöcken erstellt. Bitte beachten Sie, dass dieser Baum wieder erstellt werden muss, jedes Mal, wenn man auf einen neuen Wörterbuchblock in der Datei stößt. Der genaue Algorithmus, um den Huffman-Baum zu erstellen, wird in Abschnitt 6 gezeigt.
Zum Zweck dieser Diskussion wird angenommen, dass die Koordinaten der oberen linken Ecke des Bildrechtecks, das durch diesen Positionsblock codiert wird, (0,0) sind. Da all die Koordinaten innerhalb des Blockes relativ zueinander sind, können die eigentlichen Koordinaten alles mögliche sein; alles wird relativ zu dieser oberen linken Position codiert. Die Koordinaten steigen mit dem Bild abwärts und nach rechts über dem Bild. Üblicherweise stellt die Y-Koordinate die vertikale Position einer Instanz eines Zeichens dar, und die X-Koordinate repräsentiert seine horizontale Position. Allerdings gibt es einen versetzten Codierungsmodus, der für Dokumente gedacht ist, in denen die primäre Richtung des Textflusses vertikal ist (wie es z.B. in chinesischen Texten geschieht). In diesem Fall stellt die X-Koordinate einer Token-Position seine vertikale Position in dem Bild dar, und die Y-Koordinate repräsentiert seine horizontale Position.
Die Position, die für ein Token codiert wird, ist die Position von seinem unteren linken Eck-Pixel im normalen Codierungsmodus, und die Position seines oberen linken Eck-Pixels im transponierten Codierungsmodus.
Das Format eines Positionsblockes 1900 ist in 19 gezeigt. Der erste Wert 1910 ist die Anzahl von Tokens, die in diesem Positionsblock vorhanden sind, wobei diese unter Verwendung der Tabelle 1 codiert ist. Darauf folgt einige Information über die verwendete Codierung innerhalb dieses Blockes. Die Felder hier sind:
Modaler Delta-X-Wert Dieses vorzeichenlose 4-Bit-Feld (Feld 1920) gibt den modalen Delta-X-Wert an. Dieser Wert wird von allen Delta-X-Werten abgezogen, bevor diese codiert werden, und muss für die Decodierung wieder dazuaddiert werden.
Streifenhöhe Dieses 2-Bit-Feld (Feld 1930) gibt die Höhe der Streifen an, in denen das Bild unterteilt ist. Im Augenblick sind drei Werte definiert: 0, 1 und 3, die Streifenhöhen von jeweils 1, 2 und 4 Pixeln angeben.
Erstes X-Codier-Tabellen-Flag Dieses 2-Bit-Feld (Feld 1940) gibt an, welche Codiertabelle verwendet worden ist, um die erste X-Position innerhalb jedes Streifens zu codieren; siehe Tabellen 5 und 6. Werte von 2 und 3 sind im Augenblick undefiniert.
Delta X-Codier-Tabellen-Flag Dieses 2-Bit-Feld (Feld 1950) gibt an, welche Codiertabelle verwendet worden ist, um die Delta-X-Werte innerhalb jedes Streifens zu codieren; siehe Tabellen 7, 8 und 9. Ein Wert von 3 ist im Augenblick undefiniert.
Delta-Y-Codier-Tabellen-Flag Dieses 2-Bit-Feld (Feld 1960) gibt an, welche Codiertabelle verwendet worden ist, um die Delta-Y-Werte zwischen den Streifen zu codieren; siehe Tabellen 10, 11 und 12. Ein Wert von 3 ist derzeitig undefiniert.
Umstellungsflag Dieses 1-Bit-Feld (Feld 1965) enthält 0, wenn der Positionsblock normal codiert ist, und 1, wenn er transponiert codiert ist.
Dieser anfänglichen Codierinformation folgend, werden die Standorte und Identifikationen der in diesem Bild auftauchenden Tokens codiert. Das Bild wird in Streifen der Größe unterteilt, welche durch das Streifengrößenfeld (1, 2 oder 4 Pixel) codiert sind. Im normalen Koordinaten-Codiermodus unterteilen die Streifen das Bild in horizontale Scheiben; in dem transponierten Codierungsmodus unterteilen die Streifen das Bild in vertikale Scheiben. Der Deutlichkeit halber werden die Streifen in dem Kontext des Normalcodierungsmodus beschrieben (hinsichtlich von Reihen).
Im Positionsblock 1900 beinhalten die Streifen Streifen 1 1970, Streifen 2 1980, und zusätzliche Streifen (wie durch die Auslassungspunkte 1985 angezeigt). Den Streifen folgend befindet sich ein Positionserweiterungsabschnitt 1990.
Die erste Reihe des ersten Streifens in einem Positionsblock ist die obere Reihe des Bildes. Die Streifen werden von oben nach unten codiert. Nur Streifen, welche Aufrufe von einigen Tokens enthalten, werden tatsächlich codiert; jeder nicht leere Streifen codiert die Anzahl von Streifen, welche zwischen ihm und dem vorherigen, nicht leeren Streifen übersprungen worden sind. Innerhalb jedes Streifens werden die Tokens nach ansteigender X-Position sortiert.
Das Formal eines einzelnen Streifens wird in 20 gezeigt. Der Streifen 2000 enthält die Y-Differenz 2010 zum vorherigen Streifen, die X-Position 2020 und Y-Position 2030 des ersten Tokens, den Huffman-Code 2040 des ersten Tokens, die Delta-X-Position 2050 zu dem zweiten Token, die Y-Position 2060 des zweiten Tokens, den Huffman- Code 2070 des zweiten Tokens und zusätzliche Delta-X-, Y- und Huffman-Code-Information für zusätzliche Zeichen (wie durch die Auslassungspunkte 2080 angezeigt). Am Ende des Streifens 2000 ist ein END-Code 2090.
Der erste Wert in einem Streifen (z.B. der erste Wert 2010 in Streifen 2000) ist die Differenz zwischen der Start-Y-Position dieses Streifens und der Start-Y-Position des vorherigen Streifens. Da Streifen gezwungen sind, bei Reihen anzufangen, die durch die Streifenhöhe teilbar sind, teilt der Codierer die eigentliche Differenz durch die Streifenhöhe und codiert diese dann. Die Codierung wird unter Verwendung von einer der Tabellen 10 bis 12 durchgeführt; welche Tabelle benutzt wird, wird durch das "Delta-Y-Codier-Tabellenflag" in dem Positionsblockvorsatz angezeigt. Es gibt einen imaginären, nicht leeren Streifen genau über dem oberen Ende des Bildes; dieser wird benutzt, um den Versatz für die Y-Position des ersten Streifens zu berechnen.
Die X-Position des ersten Tokens innerhalb jedes Streifens wird unter Verwendung von Tabellen 5 oder 6 codiert; welche Tabelle benutzt wird, wird durch das "erste X-Codier-Tabellenflag" in dem Positionsblockvorsatz angezeigt. Die X-Position wird als ein Offset zu der ersten X-Position des vorherigen Streifens codiert (oder als ein absoluter Wert im Falle des ersten Streifens).
Die Y-Position jedes Tokens innerhalb eines Streifens wird mit 0,1 oder 2 Bits codiert, abhängig von der Streifenhöhe (Streifenhöhe von 1, 2 oder 4). Der Wert ist die Anzahl von Reihen, welche die Referenzposition dieses Tokens (seine untere linke Ecke) unterhalb von dem oberen Streifens ist.
Die X-Position jedes Tokens in dem Streifen, ausgenommen dem ersten, wird codiert (im Standardcodiermodus), indem die X-Position des Tokens genommen wird, und die X-Position von dem vorherigen Token abgezogen wird, plus der Breite des vorherigen Tokens; dies berechnet die Differenz in X zwischen der unteren linken Ecke dieses Tokens und dem Pixel zur rechten Seite der unteren rechten Ecke des vorherigen Tokens. In dem transponierten Codierungsmodus wird die X-Position jedes Tokens in dem Streifen codiert, indem die Differenz zwischen der X-Position des Zeichens und der X-Position des vorherigen Zeichens genommen wird, plus die Höhe des vorherigen Zeichens. Was in dem transponierten Codierungsmodus codiert wird ist deshalb die vertikale Differenz zwischen der oberen linken Ecke dieses Tokens und dem Pixel unterhalb der unteren linken Ecke des vorherigen Tokens.
In jedem Fall wird der modale Delta-X-Wert, der in dem Positionsblockvorsatz gegeben ist, von diesem Wert abgezogen, bevor dieser codiert wird; dies gewährleistet, dass der am häufigsten codierte Wert immer null ist. Die Codiertabelle, die für den entstehenden vorzeichenbehafteten Wert verwendet wird, wird durch den "Delta-X-Codier-Tabellenflag"-Wert angegeben; es ist eine der Tabellen 7 bis 9.
Das letzte Zeichen in einem Streifen wird durch einen END-Code (welches von der entsprechenden Delta-X-Codiertabelle gezogen wird) statt einem Delta-X-Code beflaggt. Da Streifen niemals leer sind, gibt es keine Möglichkeit, einen END-Code in irgendeinen von den ersten X-Codiertabellen zu codieren.
Beachten Sie, dass es keinen Ende-des-Bildes-Code gibt; statt dessen wird der letzte Streifen mit einer Y-Position beflaggt, welche außerhalb des möglichen Bereichs für dieses Bildrechteck ist. Diese Position beginnt keinen realen Streifen, also gibt es keine darauffolgenden Zeichenpositionen. Statt dessen wird es durch einen Positionsblockerweiterungsabschnitt 1990 gefolgt (siehe 19), ähnlich der Wörterbuch-Blockerweiterung 1670 (aus 16). Der einzige Teil des Abschnittes 1990, der derzeit definiert ist, ist das Längenfeld: ein 32-Bit-Wert (der gespeichert wird mit Hilfe der Codierung in Tabelle 1), der die Größe, in Bytes, des Positionsblockerweiterungsabschnittes angibt, welches an der nächsten Byte-Grenze beginnt. Eine Länge von 0 wird verwendet, um einen leeren Erweiterungsabschnitt anzuzeigen.
5. Resteblöcke
Das Bitmap jeder Seite wird in zwei Teilen codiert: der Positionsblock, der die Tokens aus dem Wörterbuch angibt, das auf dieser Seite verwendet wird, und das Reste-Bitmap. Das Reste-Bitmap codiert alle Zeichen auf der Seite, die nicht in dem Positionsblock codiert worden sind. Beim Decodieren sollten die Tokens, die durch den Positionsblock der Seite angegeben sind, zuerst in ein unkomprimiertes Bitmap geschrieben werden; der Resteblock sollte dann mit diesem Bitmap über einen OR-Vorgang kombiniert werden. Das Bitmap, welches in dem Resteblock gespeichert ist, kann kleiner sein als das origi nale Seiten-Bitmap. Wenn das Reste-Bitmap leer ist (komplett weiß), dann enthalten die Reste-Bitmap-Felder (inkl. dem Längenfeld) alle null, und es gibt kein codiertes Reste-Bitmap.
21 zeigt das Format eines Resteblocks 2100. Alle Felder, ausgenommen dem eigentlichen codierten Reste-Bitmap, sind vorzeichenlose 16- oder 32-Bit-Werte. Diese werden jeweils als 2 oder 4 Bytes codiert, wobei das höchstwertige Byte zuerst auftaucht ("big-endian"-Codierung).
Linke Kante des Reste-Bitmaps Dieses Feld (Feld 2110) gibt die Position der linken Kante des Reste-Bitmaps relativ zu dem Original-Bitmap an. Es ist ein 2-Byte-Wert.
Obere Kante des Reste-Bitmaps Dies ist ein 2-Byte-Wert (Wert 2120), der die Position der oberen Kante des Reste-Bitmaps relativ zu dem originalen Bitmap angibt.
Breite des Reste-Bitmaps Dies ist ein 2-Byte-Wert (Wert 2130), der die Breite des Reste-Bitmaps angibt.
Höhe des Rest-Bitmaps Dies ist ein 2-Byte-Wert (Wert 2140), der die Höhe des Reste-Bitmaps angibt.
Länge des codierten Reste-Bitmaps Dies ist ein 4-Byte-Wert (Wert 2150), der die Länge in Bytes des codierten Reste-Bitmaps angibt.
Codiertes Reste-Bitmap Dies ist eine CCITT Group-4-codierte Darstellung 2160 des Reste-Bitmaps. Die Group-4-Komprimierung verwendet keine EOL-Codes, und füllt die Bytes von MSB-nach-LSB auf. Wie in dem Fall der Wörterbuch-Höhenklassen, im Unterabschnitt 3.1.4, kann dieses Bitmap optional auch unkomprimiert gespeichert werden; dies wird mit einem Byte-Anzahlwert von null beflaggt.
6. Huffman-Codierung
Der Algorithmus, der verwendet wird, um den Huffman-Baum zu erstellen, ist:

• Bilde eine Datenreihe (Array) der Token-Verwendungsanzahlen. Tokens, dessen Verwendungszählungen als null angegeben sind, werden angesehen als ob sie eine Verwendungsanzahl von eins haben (dieses sind Einweg-Tokens). Die Reihenfolge der Reihe sollte exakt die Reihenfolge sein, in welcher die Tokens in der Datei bis zu diesem Zeitpunkt aufgetreten sind. Nach einem Wörterbuchlöschcode ist die Reihenfolge von jeglichen behaltenen Tokens die Reihenfolge, in welcher sie in der Liste der behaltenen Tokens erschienen sind.
• Abtasten des aktuellen Arrays nach den zwei Elementen mit dem niedrigsten Wert. In den Fällen von Verknüpfungen wähle immer das Element aus, das am nächsten zum Anfang des Arrays ist. Dies kann mit Hilfe von einer Prioritätsschlange erfolgen mit einem primären Schlüssel der Verwendungszählung, und einem sekundären Schlüssel der Position in der Datenreihe.
• Erstelle einen Baumknoten, der den Zusammenschluss von diesen zwei Elementen darstellt. Seine Verwendungsanzahl ist die Summe ihrer Verwendungsanzahlen.
• Ersetze in dem Array das erste von diesen zwei Elementen (dasjenige, das am Nächsten zu dem Anfang des Arrays ist) mit diesem zusammengelegten Knoten. Entferne das zweite Element aus dem Array (aber vergiss es nicht).
• Mache weiter, bis das Array nur einen einzigen Knoten enthält.
• Verwende diesen Baum, um die Länge des Huffman-Codes für jedes Token zu finden: durchlaufe den Baum runter bis zu jedem Token; die Länge dieses Pfades ist die Anzahl an Bits in dem Code für dieses Token.
• Weise den Codes sich selber zu unter Verwendung des "kanonischen Huffman-Code"-Zuweisungsalgorithmus: – lasse c[I] die Anzahl von Codes der Länge I Bits sein. – Nehme an, dass die maximal mögliche Code-Länge 32 ist. – f[32] = 0; – for(I = 31; I >= 0; I--) f[I] = (f[I + 1] + c[I + 1])/2; – f[I] ist nun der erste (niedrigste) Wert für all die Codes, die die Länge I Bits haben. Diese sollten in zunehmender Reihenfolge zugewiesen werden, in der Reihenfolge, in der die Tokens in der Datei auftreten: das erste Token, dessen Code eine Länge von I hat, wird der Code f[I] zugewiesen, der nächste der Länge I bekommt den Code f[I] + 1, etc.

7. Verkapselung der Blöcke
Die momentane Verkapselung dieser Blöcke ist ziemlich einfach; andere komplexere Verkapselungen sind möglich. Die eine, die hier beschrieben wird ist minimal, aber sie ist ziemlich einfach zu analysieren (in Englischen: parse), und erlaubt einen zufälligen Zugang zu Seiten ohne unangemessene Schwierigkeit. Die Felder in dieser Verkapselung werden in 22 gezeigt.
Identifikationsvorsatz Dies ist ein 5-Byte-Feld (Feld 2210), das die Bytes 0 × 54 0 × 03 0 × 6f 0 × 8d, 0 × 50 enthält.
Dateiversion Dies ist ein Byte-Feld (Feld 2220), das die Version der verwendeten Verkapselung enthält. Derzeit ist dieser Wert 9.
Länge des codierten Wörterbuchblocks Dies ist ein 4-Byte-Wert (Wert 2230), der die Länge in Bytes des Wörterbuchblockes angibt. Der Wert wird in der Netzwerk-Byte-Reihenfolge (MSB zuerst) gespeichert, wie auch die anderen numerischen Werte in der übergeordneten Verkapselung.
Wörterbuchblock Dies ist ein Wörterbuchblock (Wörterbuchblock 2240) in dem Format, das in Abschnitt 3 beschrieben ist. Derzeit gibt es nur einen Wörterbuchblock, und Wörterbuchbereinigungscodes werden nicht verwendet; die Modifizierung der Verkapselung, um dies zu unterstützen, ist nicht schwierig.
Anzahl der Seiten Dies ist ein 2-Byte-Wert (Wert 2250), der die Anzahl von Seiten in dieser Datei angibt.
Seiten Jede dieser (z.B. codierte Seite 1 2260; codierte Seite 2 2270; zusätzliche codierte Seiten, wie durch die Auslassungspunkte 2280 angezeigt) wird codiert, wie in 23 gezeigt. Die Felder der Seite 2300 sind:
Seitendateiname Dies ist ein NUL-beendeter String (String 2310), der den Namen der Datei angibt, von der diese Seite ursprünglich herkam, oder andere Identifikationsinformation.
Seitenbreite Dies ist ein 2-Byte-Wert (Wert 2320), der die Breite des Bitmaps dieser Seite angibt.
Seitenhöhe Dies ist ein 2-Byte-Wert (Wert 2330), der die Höhe des Bitmaps dieser Seite angibt.
Länge des codierten Positonsblockes Dies ist ein 4-Byte-Wert (Wert 2340), der die Länge in Bytes des Positionsblockes der Seite angibt.
Positionsblock Dies ist ein Positionsblock 2350 in dem in Abschnitt 4 beschriebenen Format.
Resteblock Dies ist ein Resteblock 2360 in dem in Abschnitt 5 beschriebenen Format. Es ist nicht notwendig, die Länge des Resteblocks zu codieren, da er einfach bestimmt werden kann, indem die ersten wenigen Bytes abgetastet werden.
7.1. Einbettung innerhalb TIFF
TIFF^® wird derzeit verwendet, um CCITT Gruppe-4 komprimierte Bitmaps zu speichern. Dieser Unterabschnitt beschreibt kurz, wie Wörterbuchblöcke, Positionsblöcke und Resteblöcke innerhalb von TIFF^®-Dateien eingebettet werden können, um TIFF^® zu ermöglichen, Token-komprimierte Bitmaps darzustellen.
Da der Dekomprimierer all die Wörterbuchblöcke, die einem Positionsblock vorangehen, gesehen haben muss, um die Dekomprimierung richtig hinzubekommen, sollten diese Wörterbuchblöcke so einfach wie möglich zu finden sein. Vorteilhafterweise gibt es höchstens einen Block pro Seite, der in dem Verzeichnis der höchsten Ebene für diese Seite (als eine Marke) gespeichert ist. Da der Dekomprimierer durch die Datei stöbert, um eine bestimmte Seite zu erhalten, muss es deshalb an allen Wörterbuchblöcken vorbei kommen, die es benötigen wird. Es muss diese nicht analysieren, bis es wirklich auf ein Token-komprimiertes Binärbild stößt, sondern muss sich nur an deren Positionen (und Reihenfolge) erinnern.
Die Positionsblöcke hingegen sollten so viel wie möglich von der Information wiederverwenden, die für Binärbilder verfügbar ist. Sie sollten als reguläre Binärbilder gespeichert werden, aber indem ein abweichendes Komprimierungsverfahren verwendet wird (die TIFF^® spec. erlaubt es komprimierte Bilder, durch das verwendete Komprimierungsverfahren zu markieren).
Die Resteblöcke könnten auch als Binärbilder gespeichert werden, in den gleichen Seiten wie die entsprechenden Positionsblöcke; das Speichern von mehreren Bildern für die gleiche Seite ist durch die TIFF^® spec. erlaubt. (es spezifiziert aber nicht in angemessener Weise, wie sie kombiniert werden sollen).
8. Weitere Diskussion
Hier folgt einige zusätzliche Information bezüglich des aktuellen DigiPaper-Formats und bezüglich möglichen Variationen des Formats.

• Im derzeitigen Format stellt ein Positionsblock eine komplette Seite dar. In einigen Anwendungen (besonders ein Faxausgabegerät) könnten Seiten in Scheiben unterteilt sein; dies bedeutet, dass man die Seite so schnell wie möglich beginnen kann zu drucken, sobald die erste Seitenscheibe decodiert ist. Jede Seitenscheibe würde einen Positionsblock und einen Resteblock umfassen. Das Format der höchsten Ebene müsste leicht geändert werden, um dies aufzunehmen: Wörterbuchblöcke würden innerhalb einer Seite (zwischen Seitenschei ben) auftreten. Dies widerspricht sich mit dem Ziel, einen einfachen Zugang zu einer einzelnen Seite zu erlauben: der Decodierer muss durch die Seite lesen und jene Wörterbuchblöcke erfassen, um in der Lage zu sein, irgendeinenachfolgende Seite zu decodieren. Allerdings muss es immer noch nicht jeden Seitenscheibenpositionsblock komplett decodieren.
• Jegliches gegebenes Dokument kann eine große Anzahl von Darstellungen besitzen, abhängig von, wie der Codierer die Zeichen auf jeder Seite codiert, wo er Wörterbuchblöcke und Wörterbuchlöschcodes anordnet, seiner Wahl an Codierungstabellen, wie Seiten in Seitenstreifen unterteilt werden, usw. Speichervoraussetzungen in dem Codierer und Decodierer können die Darstellungen einschränken, die erfolgreich erzeugt und decodiert werden können. Wenn der Codierer und Decodierer direkt miteinander kommunizieren (wie in einer Übertragung zu einem Faxausgangsgerät), können sie ein Speicherlimit aushandeln, und der Codierer kann gewährleisten, dass der Decodierer dieses Limit nicht überschreiten wird, indem jede Seite in ausreichend kleine Streifen unterteilt wird (um die Speichererfordernisse des Seitenbildpuffers zu verringern), und in dem Wörterbuchlöschcodes eingefügt werden (um die Speicheranforderungen des Zeichen-Wörterbuchs zu verringern). Solche Einschränkungen vermindern wahrscheinlich die Komprimierung. Wenn das Dokument in eine Datei komprimiert wird, ist eine solche Verhandlung nicht möglich, und deshalb müssen Decodierer, die aus solchen gespeicherten Dateien lesen, darauf vorbereitet sein, eine (potenziell) große Menge an Speicher zu verwenden. Allerdings ist es wahrscheinlich, dass der Decoder in solch einer Situation auf irgendeinen leistungsfähigen Mehrzweckcomputer läuft, so dass diese Voraussetzung nicht zu schwerwiegend ist. Für Faxmaschinen hingegen können Kostenerfordernisse zu Situationen führen, in denen die Speicherverwendung streng begrenzt ist; glücklicherweise sind dies exakt die Situationen, in denen eine Verhandlung möglich ist.
• Die codierten Token-Höhenklassen und Reste-Bitmaps werden unter Verwendung von der CCITT Gruppe-4-Komprimierung komprimiert, oder werden unkomprimiert gespeichert, in den Fällen, wo Group-4 deren Größen tatsächlich erhöht. Dies wurde ausgewählt, weil Systeme (sowohl Hardware als auch Software), um eine Group-4-Komprimierung und Dekomprimierung auszuführen, gewöhnlich und relativ einfach sind. Diese Bitmaps könnten mit jeglichem passenden verlustfreien Binärkomprimierer gespeichert werden; JBIG würde eine Möglichkeit sein.

Anwendungen der Erfindung
Das DigiPaper-Dateiformat wurde nun komplett beschrieben. Als Nächstes werden einige weitere Anwendungen der Erfindung diskutiert. Hochgeschwindigkeitsdrucken wurde vorher als eine Anwendung erwähnt. Die beispielhaften Renderingkomponenten 200, welche in 10 dargestellt wurden, deuten auf weitere Anwendungen, inklusive Druckervorschau, computergestütztes Publizieren, Dokument-Managementsysteme und verteilte Druckeranwendungen, sowie Faxkommunikationen. Im Allgemeinen kann die Erfindung in jedweder Situation Anwendung finden, in der eine schnelle, hochqualitative Dokumentberechnung benötigt wird.
Die Erfindung ist insbesondere geeignete für interaktive Dokumente, wie z.B. World Wide Web-Dokumente. Aufgrund der Ausdruckstärke der in Token übersetzten Darstellung (speziell verglichen mit HTML), können Web-Dokumente, die im DigiPaper-Format codiert sind, mit einer Genauigkeit berechnet werden, ähnlich der in der Presse. Darüber hinaus sind Renderinggeschwindigkeiten von unter 1 Sekunde pro Seite für Text und Grafiken erreichbar. Dies bedeutet weniger ungewollte Verzögerungen für Benutzer, die Dokumente von entfernten Web-Servern herunterladen.
Das Flussdiagramm aus 24 zeigt eine einfache Interaktion zwischen einem Web-Server und einem Client-Computer, der ein Web-Client (Browser) -Programm ausführt, wie z.B. Netscape-Navigator (Netscape Communications, Inc., Mountain View, CA), das die Java^TM-Programmiersprache unterstützt (erhältlich von Sun Microsystems, Inc.). Der Client-Computer erhält einen Befehl, der anzeigt, dass der Benutzer des Client-Computers einen Hypertext-Link ausgewählt hat, der auf eine neue Web-Seite (Schritt AA) zeigt, die im DigiPaper-Format codiert ist. Der Computer antwortet darauf, indem er dem ausgewählten Link folgt (Schritt BB), und indem er anfängt, die ausgewählte Seite herunter zu laden. Die erste Sache, die heruntergeladen wird, ist ein Programm in der Java-Sprache, oder eine kleine Anwendung (Schritt CC), welche der Client-Computer automa tisch beginnt auszuführen. Indem die Java^TM-Anwendung ausgeführt wird, wird der Client-Computer veranlasst, eine Datendatei herunter zu laden, die eine in DigiPaper-Zeichen übersetzte Darstellung des ausgebbaren Textes und der Grafiken enthält, die den lesbaren Inhalt der Web-Seite ausmachen (Schritt DD). Die Anwendung enthält auch eine DigiPaper-Dekomprimierungssoftware, so dass, sobald die in Zeichen übersetzte Darstellung herunter geladen worden ist, der Client-Computer sie rendern kann (Schritt EE) und die entstehende Web-Seite anzeigen kann (Schritt FF). Die DigiPaper-Darstellung kann Erweiterungen enthalten, um die Hypertext-Links zu unterstützen, die in der herunter geladenen Web-Seite eingebettet sind, und die Anwendung kann die Auswahl des Benutzers von neuen Links auf der dekomprimierten Seite erkennen (weiter in Schritt FF). Abhängig von dem, was der Benutzer entscheidet als Nächstes zu tun (Schritt GG), kann die Anwendung entweder zu einer neuen Seite verbinden (Schritt BB) in Antwort auf die Auswahl des Benutzers von einem Link auf der herunter geladenen DigiPaper-Seite, oder kann die Kontrolle zurück zu dem Browser geben (Schritt HH). Wenn eine neue Web-Seite ausgewählt ist, behält die Anwendung die Kontrolle; insbesondere wenn die neu ausgewählte Seite eine DigiPaper-Seite ist, braucht die Anwendung nicht noch mal herunter geladen zu werden (Schritt BB). Wenn der Benutzer z.B. eine Browser-Funktion ausgewählt hat, die sich nicht sofort auf die Inhalte der im Augenblick angezeigten Seite bezieht, kann die Anwendung beendet oder ausgesetzt werden, und die Kontrolle kann zurück zu dem Haupt-Browser-Programm gegeben werden (Schritt HH).
Dieses Beispiel zeigt, dass wenn eine in DigiPaper Zeichen übersetzte Dokumentdarstellung mit einer Dekomprimierungsanwendung zusammengebündelt wird, das resultierende Packet in der Tat ein sich selbst renderndes Dateiformat ist. Solange wie der Browser die Industriestandard-Java-Sprache unterstützt, braucht der Browser nicht speziell für DigiPaper befähigt werden. Die Anwendung übernimmt dies.
Abwandlungen und alternative Ausführungsformen
Viele alternative Ausführungsformen der Erfindung sind möglich. Hier sind einige Beispiele:

• Die strukturierte Darstellung des Quelldokuments muss keine PDL-Darstellung sein. Andere Möglichkeiten umfassen Dokumentaustauschformate (z.B. PDF, Common Ground) und PCL5. Im Allgemeinen kann jegliche Nicht-Bild-basierte strukturierte Dokumentdarstellung verwendet werden.
• Obwohl das DigiPaper-Dateiformat das bevorzugte Format für die in Zeichen übersetzte Darstellung ist, können andere strukturierte Dokumentdarstellungen benutzt werden. Eine Möglichkeit ist, eine hoch reduzierte Untermenge einer PDL zu verwenden. Die Untermenge muss nur einige wenige Operatoren enthalten, nur ausreichend, um zu bestimmen, welche die Bitmaps für die diversen Symbole sind, und wo die Symbole innerhalb des gerenderten Bildes zu positionieren sind, zusammen mit grundlegenden Befehlen um zu veranlassen, dass die Symbole an den gewünschten Positionen gezeichnet werden. Zum Beispiel kann in PostScript die Untermenge die Operatoren imagemask, moveto, rmoveto, definefont und show sein; diese Operatoren sind in dem PostScript-Handbuch jeweils auf den Seiten 435, 456, 483, 398 und 520 definiert. Insbesondere der definefont-Operator kann gebitmappte Schriftarten annehmen, und kann deshalb verwendet werden, um Token-Bitmaps zu definieren.
• Obwohl die bildbasierte, in DigiPaper-Zeichen übersetzte Darstellung auflösungsabhängig ist, ist es trotzdem möglich, sie zum Drucken oder Anzeigen in einer Auflösung zu konvertieren, die unterschiedlich ist von der, in welcher sie in Zeichen übersetzt wurde. Dies kann z.B. durch Herunterberechnung (in englisch: downsampling) erledigt werden. Die erzielten Bilder können für viele Applikationen von akzeptabler Qualität sein.
• Das Restbild für eine Seite kann als nur ein weiteres Token angesehen werden, obwohl es wegen der Leistungsfähigkeit außerhalb des Wörterbuchblockes gespeichert wird. Alternativerweise kann das Restbild im Wörterbuchblock gespeichert werden, als ein Token oder als Satz von Token.
• Die erfindungsgemäße Komprimierungsmethode kann in ein Dokument-Komprimierungssystem eingebunden werden, das sowohl verlustbehaftete Codierung von abgetasteten Seiten unterstützt, als auch verlustfreie Codierung von gerenderten Seiten. Die erfindungsgemäße Technik wird speziell verwendet, um eine verlustfreie symbolbasierte Darstellung von gerendertem Text/Grafiken bereitzustellen. Symbolbasierte Techniken des Standes der Technik können benutzt werden, um abgetastete Dokumentseiten zu codieren, die Text und Grafiken enthalten; vorzugsweise wird dasselbe Dateiformat (z.B. DigiPaper) verwendet für sowohl die verlustbehaftete als auch die verlustfreie Technik, so dass die selbe Rendering-Funktionseinheit ungeachtet der Quelle des Dokumentbildes verwendet werden kann. Eine andere Technik, wie z.B. JPEG oder andere verlustbehaftete Codierungstechniken können für Farb- und Grau-Bitmap-Bilder (z.B. Fotografien) verwendet werden.

Ergebnis
Ein neues, rechnerisch effizientes Verfahren wurde beschrieben, um eine Seitenbeschreibungssprache in eine in Zeichen übersetzte, schriftartfreie strukturierte Darstellung zu kompilieren, und um diese schriftartfreie Darstellung schnell zu rendern, um ein Dokumentbild zu erzeugen. Ein Komprimierer oder in Zeichenübersetzer nimmt einen Satz von Seitenbildern, die direkt aus einer PDL-Datei oder einer anderen strukturierten Darstellung eines Dokuments erstellt sind, und konvertiert diese Seitenbilder in eine in Zeichen übersetzte Darstellung, basierend auf Tokens und Positionen. Ein Dekomprimierer rekonstruiert, die Seitenbilder aus den gespeicherten Tokens und Positionen, indem ein Gesamt-Bitmap-Bild für jede Seite aus den Einzelteilen-Subbildern der Tokens errichtet wird, dessen Formen auf dieser Seite auftreten. Die in Zeichen übersetzte, schriftartfreie strukturierte Darstellung, die durch das erfindungsgemäße Verfahren verwendet wird, stellt einen Grad an Ausdrucksstärke bereit, der gleich oder vergleichbar ist mit dem, was vorher nur mit PDLs verfügbar war. Dennoch ist diese Darstellung hochgradig kompakt und kann sehr schnell und vorhersehbar gerendert werden, und kann bequem mit Dekomprimierungssoftware gebündelt werden, um selbst extrahierende, selbst anzeigbare Dokumente bereitzustellen. Das erfindungsgemäße Verfahren kann in Hardware-Konfigurationen eingebunden werden, die sowohl Allgemeinzweck-Computer als auch Spezial-Druck- und Bildverarbeitungsgeräte umfassen.
Browse-jetzt,-drucke-später
Wie vorher in Bezug auf 24 beschrieben wurde, ist die vorliegende Erfindung insbesondere geeignet für die Verwendung mit interaktiven Dokumenten, wie z.B. World Wide Web-Dokumenten. Insbesondere können Web-Dokumente, die im DigiPaper-Format codiert sind, mit einer hohen Genauigkeit gerendert werden. Darüber hinaus, wenn eine in DigiPaper-Zeichen übersetzte Dokumentdarstellung mit einer Dekomprimierungsanwendung gebündelt wird, ist das entstehende Paket in der Tat ein sich selbst renderndes Dateiformat.
Es gibt Zeiten, in denen es wünschenswert ist, den Benutzerzugriff auf bestimmte Web-Dokumente zu kontrollieren. Betrachten Sie z.B. ein Copyright-geschütztes Dokument, das auf einem Web-Server gespeichert ist und von einer oder mehreren Web-Seiten erreichbar ist. Nehmen wir an, dass ein Benutzer eine Web-Seite durchstöbert, die das Copyright geschützte Dokument enthält, eventuell für dieses Recht bezahlt, und fortfährt, das Dokument von dem Server herunter zu laden. Danach gibt es typischerweise nichts anderes als Achtung vor dem Gesetz, um den Benutzer zu hindern, irgendeine Anzahl von digitalen Kopien des herunter geladenen Dokuments anzufertigen und zu verteilen, wodurch der Wert der Copyright-geschützten Arbeit möglicherweise untergraben wird. Deshalb wäre es wünschenswert, wenn dem Benutzer die Möglichkeit gegeben werden kann, das Dokument auf dem Web durchzublättern, er dennoch weiter gehindert wird, eine hochqualitative digitale Kopie des Dokuments zu erhalten.
Gleichzeitig muss das Bedürfnis des Benutzers für eine hochqualitative gedruckte Kopie des Dokuments auch erfüllt werden. Für viele Leute sind typische Bildschirme, wie z.B. CRTs, von hinten-beleuchtete LCDs und Ähnliches nicht angenehm für ausgiebige oder lange Leseaufgaben. Insbesondere ist die Auflösung dieser Bildschirme zu niedrig. Aus diesem Grund werden Web-Benutzer oft entscheiden, ein Web-Dokument auszudrucken, und es auf Papier zu lesen, statt zu versuchen, das Dokument in seiner Ganzheit direkt von dem Bildschirm zu lesen. Typischerweise ist die gedruckte Ausgabe leichter zu lesen als die angezeigte Ausgabe und insbesondere bietet sie eine höhere Auflösung. Zum Beispiel, wohingegen ein Bildschirm von 72 dpi (3 Dots/mm) Auflösung unangenehm für intensive Leseaufgaben ist, ist eine Laser-ausgedruckte Seite in 600 dpi Auflösung oder höher ziemlich komfortabel für die meisten Leser.
DigiPaper bietet eine Lösung für beide dieser Probleme. Man kann sich von der Beschreibung in vorhergehenden Abschnitten erinnern, dass DigiPaper eine auflösungsabhängige strukturierte Dokumentdarstellung bietet. Die Auflösungsabhängigkeit von DigiPaper zusammen mit seiner positiven Geschwindigkeit und Komprimierungsrate bedeutet, dass DigiPaper-Dokumentdarstellungen leicht in unterschiedlichen Auflösungen auf unterschiedlichen Medien für unterschiedliche Beteiligte verfügbar gemacht werden kann, mit unterschiedlichen Graden von Vertraulichkeit und Sicherheit. Insbesondere können das Netzstöbern in einer niedrigen Auflösung und das Drucken in einer hochqualitativen hohen Auflösung voneinander entkoppelt werden. Ein Web-Benutzer kann ein Copyright-geschütztes Dokument elektronisch in einer niedrigen Auflösung durchschauen und kann auf Anfrage eine Kopie mit hoher Auflösung erhalten, das alles, ohne ihm Zugriff auf eine hochqualitative digitale Kopie der Arbeit zu geben.
Gemäß der Erfindung in einer Ausführungsform, die jetzt beschrieben werden soll, wird eine auflösungsunabhängige strukturierte Darstellung eines Quelldokuments, wie z.B. eine PDL-Darstellung, verlustfrei in zwei (oder mehr) unterschiedliche, in DigiPaper-Zeichen übersetzte Darstellungen in jeweils unterschiedlichen Auflösungen umgewandelt. Zum Beispiel wird ein PDL-Original als eine Niedrigauflösungs-DigiPaper-Darstellung codiert und auch als eine Hochauflösungs-DigiPaper-Darstellung. Die Niedrigauflösungsdarstellung ist geeignet für Online-Web-Browsing und für die Bildschirmanzeige, ist aber von ungenügender Auflösung für ein hochqualitatives Drucken. Nur die Hochauflösungsdarstellung ist geeignet, um hochqualitative gedruckte Kopien des Dokuments zu erzeugen.
Die Niedrigauflösungsdarstellung wird auf einem Web-Server aufgestellt und wird so für das Online-Browsen durch einige und alle Web-Benutzer verfügbar, inklusive denen, die nicht vertrauenswürdig sind oder unwissend über die Urheberrechtsgesetze sind. Diese Benutzer können das Dokument im Netz durchstöbern, üblicherweise gebührenfrei, einfach indem sie ihre Netz-Browser (Clients) auf die Netzseite oder Seiten hin verbinden, wo sich die Niedrigauflösungs-DigiPaper-Darstellung befindet. Ein Benutzer, der an dem Dokument interessiert ist und eine hochqualitative gedruckte Kopie zum Lesen erhalten will, sendet eine Anfrage für eine Druckausgabe an den Web-Server. Als Antwort darauf kontaktiert der Server eine vertrauenswürdige Druckeinrichtung (z.B. ein Druckbüro oder einen Copy-Shop) und versorgt die Einrichtung mittels einer sicheren Kommunikationsverbindung mit der Hochauflösungs-DigiPaper-Darstellung des Dokuments. Aus der Hochauflösungs-DigiPaper-Darstellung druckt die vertrauenswürdige Druckeinrichtung eine Hardcopy des Dokuments, welche wiederum dem Benutzer, der sich angefordert hat, verfügbar gemacht wird (z.B. geliefert oder geschickt). Dem Benutzer wird das entsprechend in Rechnung gestellt, und angemessene Urheberrechts-Lizenzgebühren fließen zu dem Urheberrechtsinhaber. Wesentlich ist, dass der Benutzer nie Zugang zu der Hochauflösungs-DigiPaper-Darstellung des Dokuments besitzt, und so effektiv gehindert wird, hochqualitative digitale Kopien des Dokuments anzufertigen. Das heißt, dass die einzige digitale Kopie des Dokuments, zu welchem dem Benutzer Zugang gewährt wird, eine Niedrigauflösungskopie ist.
Diese Art der Netzbenutzung gemäß der Erfindung kann als Browse-jetzt,-drucke-später bezeichnet werden (oder, etwas präziser aber schwieriger zu sagen, Browse unsicher, drucke sicher). Dies ist in dem konzeptionellen Beispiel von 25 veranschaulicht. Ein Web-Benutzer führt einen Web-Browser (Client) auf einem PC oder anderem lokalen Computer aus. Der Benutzer sieht z.B. ein Fenster 2510 angezeigt, über das der Benutzer mit dem Browser interagiert. Eine Niedrigauflösungsdarstellung 2520 eines Dokumentes kann in dem Fenster 2510 gesehen werden. Es enthält Niedrigauflösungstextdarstellung 2521 und Niedrigauflösungsstrichkunstdarstellung 2522. Dem Benutzer ist freigestellt, die Niedrigauflösungsdarstellung 2520 herunter zu laden und sie sogar zu kopieren (z.B. um Freunde oder Kunden über dieses Dokument in Kenntnis zu setzen). Die Niedrigauflösungsdarstellung 2520 ist gut genug, um dem Benutzer zu zeigen, ob das Dokument von Interesse ist, aber ist nicht gut genug, dass der Benutzer den Niedrigauflösungstext 2521 komfortabel lesen kann oder die Details der Strichkunst 2522 wahrnimmt.
Im Fenster 2510 ist auch eine Hypertextverbindung 2523, welche der Benutzer auswählen kann, z.B. durch ein Klicken der Maus oder eines anderen Zeigegeräts, um eine Hochauflösungs-Hardcopy des Dokuments anzufordern. Nach der Ausgabe der Anfrage, zusammen mit entsprechender Zahlung oder Kredit, wie durch Pfeil 2525 angezeigt, wird die Bestellung des Benutzers zu einem Druckshop oder einer anderen vertraulichen Druckereinrichtung übermittelt, zusammen mit einer Hochauflösungsdarstellung des Dokuments. Eine hochaufgelöst-gedruckte Kopie 2530 wird aus der Hochauflösungsdarstel lung erzeugt. Danach kann der Druckshop die hochauflösend-gedruckte Kopie 2530 zu dem Benutzer schicken oder liefern lassen, oder der Benutzer kann das Druckgeschäft besuchen und dort die Kopie 2530 abholen. Der Benutzer kann komfortabel die Hochauflösungskopie 2530 lesen, welche klar den Text und die Strichkunst des Dokuments zeigt (jeweils als Hochauflösungstextdarstellung 2531 und als Hochauflösungsstrichkunstdarstellung 2532). In der Zwischenzeit sammelt und verarbeitet das Druckgeschäft oder die andere vertrauliche Druckereinrichtung das Entgelt und leitet jegliche verwertbare Urheberrechteslizenzgebühren an den Urheberrechtsinhaber oder Inhabern. Die Zahlung des Benutzers kann z.B. durch eine elektronische Lastschrift oder Kredit erfolgen, oder über das Internet, wenn ein sicheres Internet-Zahlungsverfahren verfügbar ist; alternativ kann eine Rechnung an den Benutzer geschickt werden.
26 veranschaulicht die Phase der Dokumentcodierung in einer Browse-jetzt,-drucke-später Ausführungsform der Erfindung. Eine auflösungsunabhängige Quelldokumentdarstellung 2601, wie z.B. eine PDL-Datei, wird über ein oder mehrere sichere Kommunikationsverbindungen 2609 an die Codierer 2610, 2630 bereitgestellt, um in ein in DigiPaper-Zeichen übersetztes Format in jeweils Niedrig- und Hochauflösungen konvertiert zu werden. Die Codierer 2610, 2630 können z.B. zwei unterschiedliche Computer sein, die unterschiedliche DigiPaper-Codierprogramme ausführen, oder ein einzelner Computer, der ein Programm ausführt, das ein Eingabeparameter annimmt, um die Codierauflösung zu steuern. Die Niedrigauflösung (z.B. 72 dpi) ist annehmbar, um Bildschirmanzeigen zu erzeugen, aber inakzeptabel für hochqualitatives Drucken. Die Hochauflösung (z.B. 600 dpi) ist geeignet zum hochqualitativen Drucken. Sichere Kommunikationsverbindungen 2609 können z.B. festgeschaltete, fest verdrahtete oder telefonische Verbindungen sein oder geeignete verschlüsselte Netzwerkpfade. In jedem Fall ist Information, die über sichere Kanäle 2609 gesendet wird, nicht leicht Gegenstand von unerlaubtem Abfangen oder Kopieren.
Die Niedrigauflösungs-DigiPaper-Darstellung, die durch den Niedrigauflösungscodierer 2610 erzeugt wird, wird in dieser Ausführungsform über eine unsichere Kommunikationsverbindung 2611 einem Anzeigeserver oder -service 2620 bereitgestellt, während die Hochauflösungsdarstellung, die durch den Hochauflösungscodierer 2630 geformt wird, über einen sicheren Kanal 2631 einem Druckserver oder -service 2640 bereitgestellt wird. Ein unsicherer Kanal 2611 kann z.B. ein nicht verschlüsselter Internetpfad sein. Die Niedrigauflösungsdarstellung, die über die unsichere Verbindung 2611 gesendet wird, ist Gegenstand von unautorisierten Abfangen und Kopieren. Die sichere Verbindung 2631 kann wie auch Verbindungen 2609 z.B. festgeschaltete, fest verdrahtete oder telefonische Verbindungen sein oder ein geeignet verschlüsselter Netzwerkpfad sein, oder jeglicher Kommunikationskanal, der nicht einfach Gegenstand von unautorisiertem Abfangen ist. Anzeigeserver oder -service 2620 und Druckserver oder -service 2640 können z.B. zwei physikalisch getrennte Computer (d.h. Server) sein oder können zwei Prozesse (d.h. Services) sein, die auf einem einzelnen Computer ausgeführt werden. Beachten Sie, dass der Druckserver oder -service 2640 damit vertraut ist, die Hochauflösungs-DigiPaper-Darstellung aufzubewahren, und so muss sie selber vertrauenswürdig sein.
27 veranschaulicht ein einzelnes Beispiel der Decodierung in einer Browse-jetzt,-drucke-später Ausführungsform der Erfindung. In der Ausführungsform von 27 werden sowohl die Niedrigauflösungs- als auch die Hochauflösungs-DigiPaper-Darstellungen des Dokuments auf einem einzelnen Server 2705 gespeichert. Der Server 2705 befindet sich entfernt von dem Benutzer 2790 und der Urheberrechtinhaber oder Inhabern vertrauen ihm. Der Server 2705 stellt Anzeigeservice 2706 und Druckservice 2707 bereit.
Anzeigeservice 2706 stellt die Niedrigauflösungs-DigiPaper-Darstellung über unsichere Kanäle 2711 über ein Netzwerk 2710 (z.B. das Internet oder ein firmeninternes Intranet) für einen Client-Computer 2720 bereit, der ein Web-Browser-Softwareprogramm ausführt. Client 2720 ist nicht vertrauenswürdig; d.h. die Person, die den Client 2720 benutzt (hier Benutzer 2790) ist jemand, dem man nicht vertrauen kann, dass er es unterlässt, unautorisierte Kopien des Dokuments anzufertigen. In ähnlicher Weise sind unsichere Verbindungen 2711 anfällig für das Abfangen durch unautorisierte Beteiligte. Der Client 2720 führt eine Web-Browser-Software aus, die die niedrigauflösend-angezeigte Ausgabe 2725 erzeugt, die Online 2729 durch einen Benutzer 2790 angeschaut werden kann.
Der Anzeigeservice 2706 kann auch Hardcopy-Anfragen vom Client 2720 annehmen und diese in sicherer Art und Weise zu dem Druckservice 2707 kommunizieren. Nach Erhalt solch einer Anfrage stellt in dieser Ausführungsform der Druckservice 2707 eine Hochauflösungs-DigiPaper-Darstellung über eine sichere fest geschaltete Kommunikationsverbindung 2731 für einen Drucker 2730 bereit. Dem Drucker 2730 wird vertraut; d.h. die Person oder Einrichtung, welche den Drucker 2730 bedient, ist jemand, dem vertraut wird, dass er keine unautorisierten Kopien anfertigt, und dem weiter vertraut wird, die Finanzbuchhaltung zu handhaben, welche mit dem Bereitstellen der gedruckten Kopien für die Benutzer zusammenhängt. Der Drucker 2730 erzeugt eine hochqualitative, hoch auflösend gedruckte Ausgabe 2735 und erzeugt auch eine Rechnung oder Ähnliches, wie bei 2733 angezeigt. Die gedruckte Ausgabe 2735 wird physisch zu dem Benutzer 2790 geliefert 2739, der sie dann lesen kann. Die Auslieferung 2739 kann z.B. über Mail, Luft- oder Bodentransport oder Ähnlichem ausgeführt werden. Alternativ kann der Benutzer 2790 die gedruckte Ausgabe 2735 bei der Einrichtung, in der der Drucker 2730 gehalten wird, abholen. Um die Benutzerfreundlichkeit zu verbessern, während zur gleichen Zeit die Dokumentsicherheit gewährleistet wird, befindet sich der Drucker 2730 typischerweise bei einem Druckservicebüro, Copyshop oder einer anderen Einrichtung, welche relativ nah bei dem Benutzer 2790 liegt, aber nicht auf dem Gelände des Benutzers 2790, oder wenigstens nicht durch den Benutzer 2790 ohne geeignete Authorisierung erreichbar ist.
28 veranschaulicht ein komplexeres Beispiel der Decodierung in einer Browse-jetzt,-drucke-später Ausführungsform der Erfindung. In der Ausführungsform von 28 wird die Niedrigauflösungs-DigiPaper-Darstellung des Dokuments auf einem Anzeigeserver 2806 gespeichert, und eine oder mehrere Hochauflösungs-DigiPaper-Darstellungen werden auf einem Druckserver 2807 gespeichert. Der Anzeigeserver 2806 kommuniziert mit nicht vertrauenswürdigen Clients 2820a, 2820b, 2820c über unsichere Verbindungen 2811 über das Netzwerk 2810, und mit Druckserver 2807 über sichere Verbindungen 2831, welche direkt zwischen dem Anzeigeserver 2806 und dem Druckserver 2807 laufen können oder bzw. über das Netzwerk 2810 gehen können. Der Anzeigeserver 2806 kann die Niedrigauflösungs-DigiPaper-Darstellung des Dokuments zu den Clients 2820a, 2820b, 2820c übertragen, welche sie dann ihren jeweiligen Benutzern (nicht gezeigt) als Niedrigauflösungsbildschirmausgaben 2825a, 2825b, 2825c anzeigen können.
Der Anzeigeserver 2806 kann auch Anfragen für Hardcopyausgaben von dem Client 2820a, 2820b, 2820c empfangen. Er leitet diese Anfragen über einen sicheren Kanal 2831 zu dem Druckserver 2807 weiter. Vorteilhafterweise wird die Anfrage zu dem Druckserver 2807 über eine sichere Verbindung übertragen, statt über eine unsichere Verbindung von dem Anzeigeserver 2806, um zu verhindern, dass Eindringlinge gedruckte Kopien ohne korrekte Autorisation anfordern.
Nach dem Empfangen einer Anfrage für eine Hardcopyausgabe von dem Anzeigeserver 2806, benachrichtigt der Druckserver 2807 einen Buchhaltungsserver 2833, so dass die Inrechnungstellung fortgesetzt werden kann, und übermittelt die Hochauflösungs-DigiPaper-Darstellung des Dokuments über sichere Verbindungen 2831 über Netzwerk 2810 zu dem vertrauenswürdigen Drucker 2830, der daraus eine hochauflösend-gedruckte Ausgabe 2839 erzeugt.
28 zeigt auch einen unautorisierten Lauscher 2890, der die Kommunikation von dem Anzeigeserver 2806 zu den Clients 2820a, 2820b, 2820c abfängt. Solch ein Abfangen wird möglich, weil die Verbindungen 2811 unsicher sind. Allerdings kann der Lauscher 2890 nur die Niedrigauflösungsdarstellung des Dokuments abfangen. Die Hochauflösungsdarstellung, die zu und von dem Druckserver 2807 über sichere Verbindungen 2831 gesendet wird, ist unzugänglich.
Einige Punkte, die den Ausführungsformen von 27 und 28 gemeinsam sind, sind es wert, genannt zu werden. In jeder Ausführungsform werden beiden Servern oder Services von dem Urheberrechtsinhaber oder anderem rechtsgemäßen Besitzer des Dokuments vertraut, und die Verbindungen zwischen diesen sind sicher. In gleicher Weise wird dem Ausgabedrucker vertraut. Weder der Server(s) noch der Drucker ist für unautorisierte Benutzer erreichbar. Clients und Benutzer werden als vertrauenslos und nicht vertrauenswürdig angesehen, und Kommunikation mit diesen kann deshalb unsicher sein.
Es gibt bekannte Dateiformate, die ein einzelnes Dokument als eine Menge von mehreren Darstellungen in verschiedenen unterschiedlichen Auflösungen speichern. Allerdings ist die Benutzung von mehreren Darstellungen eines Quelldokuments in mehreren Auflösungen, um die Zugangskontrolle zu erleichtern, speziell im Kontext des Netzes, neu für die vorliegende Erfindung.
Die Verwendung von Browse-jetzt,-drucke-später mit abwechselnden, in Zeichen übersetzten Codierformaten, mehreren Druckauflösungen (z.B. den Benutzern werden eine Auswahl an gedruckten Ausgaben in Auflösungen, wie z.B. 300 dpi, 600 dpi, 1200 dpi (12, 24, 48 dots/mm) etc. angeboten), mit dem Zwischenspeichern der Hochauflösungs-Dokumentdarstellung bei dem vertrauten Drucker, um unnötige Wiederübertragung zu vermeiden, und andere Erweiterungen und Modifikationen werden für den Fachmann offensichtlich sein.
Die vorhergehende Beschreibung veranschaulicht nur einige der Verwendungen und Ausführungsformen der Erfindung, und viele andere sind möglich. Dementsprechend wird der Geltungsbereich der Erfindung nicht durch die Beschreibung beschränkt, sondern statt dessen wird dieser durch die anhängigen Ansprüche und deren vollen Bereich an Äquivalenten angegeben.
Tabelle 1: Codierung für 32 Bit Werte
Tabelle 2: Breiten/Höhen-Codierungstabelle
Tabelle 3: Codierungstabelle 0 für Verwendungsanzahl
Tabelle 4: Codierungstabelle 1 für Verwendungsanzahl
Tabelle 5: Codierungstabelle 0 für erstes X
Tabelle 6: Codierungstabelle 1 für erstes X
Tabelle 7: Codierungstabelle 0 für Delta X
Tabelle 8: Codierungstabelle 1 für Delta X
Tabelle 9: Codierungstabelle 2 für Delta X
Tabelle 10: Codierungstabelle 0 für Delta Y
Tabelle 11: Codiertabelle 1 für Delta Y
Tabelle 12: Codiertabelle 2 für Delta Y

Claims

Ein Verfahren, das in einem Datenverarbeitungssystem ausgeführt wird und folgende Schritte umfasst: (a) Bereitstellen eines ersten Satzes von digitaler Information, das eine erste strukturierte Darstellung (im Folgenden „die Startdarstellung") eines Dokumentes umfasst, wobei die Startdarstellung eine auflösungsunabhängige Darstellung ist, wobei eine Vielzahl von Bildsammlungen aus der Startdarstellung erhältlich sind, wobei jede dieser erhältlichen Bildsammlung wenigstens ein Bild umfasst, wobei jedes Bild in jeder dieser Sammlung ein Bild von wenigstens einem Teil des Dokuments ist, wobei jedes Bild in jeder dieser Sammlung eine charakteristische Auflösung besitzt; (b) Erzeugen eines zweiten Satzes von digitaler Information aus dem ersten Satz von digitaler Information, wobei der zweite Satz von digitaler Information eine zweite strukturierte Darstellung (im Folgenden „die Niedrigauflösungsdarstellung") des Dokuments umfasst, wobei die Niedrigauflösungsdarstellung eine verlustfreie Darstellung einer bestimmten Bildsammlung (im Folgenden „die Niedrigauflösungsbildsammlung") ist, wobei die Niedrigauflösungsbildsammlung eine aus der Vielzahl von Bildsammlungen ist, die aus der Startdarstellung erhältlich sind, wobei jedes Bild in der Niedrigauflösungsbildsammlung eine erste charakteristische Auflösung (im Folgenden „die Niedrigauflösung") besitzt, wobei der zweite Satz von digitaler Information erzeugt wird, durch (b1) Umrechnen der Startdarstellung in einen Satz von Bitmap-Bildern; (b2) Analysieren der Bitmap-Bilder um Formen darin zu erkennen; (b3) Klassifizieren der Formen, sodass vielfache Erscheinungen derselben Form zu einem selben Niedrigauflösungszeichen zugewiesen werden können, wobei jedes Niedrigauflösungszeichen einen Satz von Pixeldaten umfasst, der ein Teilbild der Niedrigauflösungsbildsammlung repräsentiert; (b4) Codieren eines Zeichenwörterbuchs und einer Vielzahl an Positionen der Niedrigsauflösungsdarstellung, wobei jede Position der Niedrigsauflösungsdarstellung eine Position eines Teilbilds (im Folgenden „das Niedrigsauflösungsteilbild") in der Niedrigauflösungsbildsammlung ist, wobei ein Niedrigsauflösungsteilbild eines der Teilbilder aus einem der Niedrigsauflösungszeichen ist, wobei mindestens ein Niedrigsauflösungsteilbild eine Vielzahl an Pixeln besitzt und an mehr als einer Position in der Bildsammlung auftritt; (c) Erzeugen eines dritten Satzes von digitaler Information aus dem ersten Satz von digitaler Information mit einem Prozessor (105), wobei der dritte Satz an digitaler Information eine dritte strukturierte Darstellung (im Folgenden „die Hochauflösungsdarstellung") des Dokumentes umfasst, wobei die Hochauflösungsdarstellung eine verlustfreie Darstellung einer bestimmten Bildsammlung (im Folgenden „die Hochauflösungsbildsammlung") ist, wobei die Hochauflösungsbildsammlung eine aus der Vielzahl von Bildsammlungen ist, die aus der Startdarstellung erhältlich sind, wobei jedes Bild in der Hochauflösungsbildsammlung eine zweite charakteristische Auflösung (im Folgenden „die Hochauflösung") besitzt, wobei die Hochauflösung größer ist als die Niedrigauflösung, wobei der dritte Satz von digitaler Information erzeugt wird durch (c1) Umrechnen der Startdarstellung in einen Satz von Bitmap-Bildern; (c2) Analysieren der Bitmap-Bilder um Formen darin zu erkennen; (c3) Klassifizieren der Formen, sodass vielfache Erscheinungen derselben Form zu einem selben Hochauflösungszeichen zugewiesen werden können, wobei jedes Hochauflösungszeichen einen Satz von Pixeldaten umfasst, der ein Teilbild der Hochauflösungsbildsammlung repräsentiert; (c4) Codieren eines Zeichenwörterbuchs und einer Vielzahl an Positionen der Hochauflösungsdarstellung, wobei jede Position der Hochauflösungsdarstellung eine Position eines Teilbilds (im Folgenden „das Hochauflösungsteilbild") in der Hochauflösungsbildsammlung ist, wobei ein Hochauflösungsteilbild eines der Teilbilder aus einem der Hochauflösungszeichen ist, wobei mindestens ein Hochauflösungsteilbild eine Vielzahl an Pixeln besitzt und an mehr als einer Position in der Bildsammlung auftritt; (d) Erzeugen der zweiten und dritten Sätze von digitaler Information, die so erzeugt, für die weitere Benutzung verfügbar sind.
Das Verfahren nach Anspruch 1, wobei der Schritt des Bereitstellens umfasst: Versorgen des Prozessors mit einer Startdarstellung, die ausgewählt ist, aus einer Gruppe bestehend aus einer Repräsentation einer Seitenbeschreibungssprache, einer Repräsentation eines Dokumentaustauschformats, einer Repräsentation einer Druckansteuerungssprache und einer Repräsentation einer Auszeichnungssprache.
Das Verfahren nach Anspruch 1, wobei der Schritt des Bereitstellens umfasst: Versorgen des Prozessors mit einer ersten strukturierten Darstellung, die eine originale Repräsentation des Dokumentes ist, wobei die originale Repräsentation eine Repräsentation ist, die durch ein Computerprogramm erzeugt ist, in welchem das Dokument erstellt wird.
Das Verfahren nach Anspruch 1, weiter den Schritt umfassend: (e) Übertragen des zweiten Satzes von digitaler Information und des dritten Satzes von digitaler Information.
Das Verfahren nach Anspruch 1, weiter die Schritte umfassend: (e) Versorgen eines Prozessors (im Folgenden „der Client") mit dem zweiten Satz von digitaler Information; wobei der Client, aus dem zweiten Satz von digitaler Information einen vierten Satz von digitaler Information erzeugt, der eine Bildsammlung umfasst, die wenigstens ein Bild enthält, wobei jedes Bild in der Bildsammlung, die in dem vierten Satz von digitaler Information beinhaltet ist, ein Bild von wenigstens einem Teil des Dokumentes ist, wobei jedes Bild in der Bildsammlung, die in dem vierten Satz von digitaler Information beinhaltet ist, aus den Zeichenteilbildern erstellt ist und ein Zeichenteilbild in wenigstens einer der Positionen beinhaltet; und Erzeugen des vierten Satzes von digitaler Information, das so erzeugt für die weitere Benutzung verfügbar ist.
Ein programmierbares Datenverarbeitungssystem, das zum Ausführen des Verfahrens nach einem der vorhergehenden Ansprüche geeignet programmiert ist.
Vorrichtung umfassend: einen Prozessor (105), einen Befehlsspeicher (106), der verbunden ist mit dem Prozessor, der ein Informationsspeichermedium umfasst, worin Informationen gespeichert sind, welche ein Computerprogramm umfassen, um das Erzeugen eines zweiten und dritten Satzes von digitaler Information aus einem ersten Satz von digitaler Information durch einen Prozessor zu ermöglichen, wobei der erste Satz von digitaler Information eine erste strukturierte Darstellung (im Folgenden „die Startdarstellung") eines Dokumentes umfasst, wobei die Startdarstellung eine auflösungsunabhängige Darstellung ist, wobei eine Vielzahl von Bildsammlungen aus der Startdarstellung erhältlich sind, wobei jede dieser erhältlichen Bildsammlung wenigstens ein Bild umfasst, wobei jedes Bild in jeder dieser Sammlung ein Bild von wenigstens einem Teil des Dokumente ist, wobei jedes Bild in jeder dieser Sammlung eine charakteristische Auflösung besitzt, wobei der zweite Satz von digitaler Information eine zweite strukturierte Darstellung (im Folgenden „die Niedrigauflösungsdarstellung") des Dokumentes umfasst, wobei die Niedrigauflösungsdarstellung eine verlustfreie Darstellung einer bestimmten Bildsammlung (im Folgenden „die Niedrigauflösungsbildsammlung") ist, wobei die Niedrigauflösungsbildsammlung eine aus der Vielzahl von Bildsammlungen ist, die aus der Startdarstellung erhältlich sind, wobei jedes Bild in der Niedrigauflösungsbildsammlung eine erste charakteristische Auflösung (im Folgenden „die Niedrigauflösung") besitzt, wobei der Prozessor ausgebildet ist die Startdarstellung in einen Satz von Bitmap-Bildern umzurechnen, wobei der Prozessor weiterhin ausgebildet ist die Bitmap-Bilder zu analysieren um Formen darin zu erkennen, wobei der Prozessor weiterhin ausgebildet ist um die Formen zu klassifizieren, sodass mehrfache Erscheinungen derselben Form zu einem selben Niedrigauflösungszeichen zugewiesen werden können, wobei jedes Niedrigauflösungszeichen einen Satz an Pixeldaten enthält, der ein Teilbild der Niedrigauflösungsbildsammlung repräsentiert; und wobei der Prozessor weiterhin ausgebildet ist ein Zeichenwörterbuch und eine Vielzahl an Positionen der Niedrigauflösungsdarstellung zu codieren, wobei jede Position der Niedrigauflösungsdarstellung eine Position eines Teilbildes (im Folgenden „das Niedrigauflösungsteilbild") in der Niedrigauflösungsbildsammlung ist, wobei ein Niedrigauflösungsteilbild eines von den Teilbildern aus einem der Niedrigauflösungszeichen ist, wobei wenigstens ein Niedrigauflösungsteilbild eine Vielzahl an Pixeln besitzt und an mehr als einer Position in der Bildsammlung auftritt; und wobei die Niedrigauflösungsdarstellung die Niedrigauflösungszeichen und die Vielzahl an Positionen enthält; wobei der dritte Satz von digitaler Information eine dritte strukturierte Darstellung (im Folgenden die Hochauflösungsdarstellung") des Dokumentes umfasst, wobei die Hochauflösungsdarstellung eine verlustfreie Darstellung einer bestimmten Bildsammlung (im Folgenden „die Hochauflösungsbildsammlung") ist, wobei die Hochauflösungsbildsammlung eine aus der Vielzahl von Bildsammlungen ist, die aus der Startdarstellung erhältlich sind, wobei jedes Bild in der Hochauflösungsbildsammlung eine zweite charakteristische Auflösung (im Folgenden „die Hochauflösung") besitzt, wobei die Hochauflösung nicht niedriger als die Niedrigauflösung ist, wobei der Prozessor ausgebildet ist die Startdarstellung in einen Satz von Bitmap-Bildern umzurechnen, wobei der Prozessor weiterhin ausgebildet ist die Bitmap-Bilder zu analysieren um Formen darin zu erkennen, wobei der Prozessor weiterhin ausgebildet ist die Formen zu klassifizieren, sodass mehrfache Erscheinungen derselben Form zu einem selben Hochauflösungszeichen zugewiesen werden können, wobei jedes Hochauflösungszeichen einen Satz an Pixeldaten enthält, der ein Teilbild der Hochauflösungsbildsammlung repräsentiert, und wobei der Prozessor weiterhin ausgebildet ist ein Zeichenwörterbuch und eine Vielzahl an Positionen der Hochauflösungsdarstellung zu codieren, wobei jede Position der Hochauflösungsdarstellung eine Position eines Teilbildes (im Folgenden „das Hochauflösungsteilbild") in der Hochauflösungsbildsammlung ist, wobei ein Hochauflösungsteilbild eines von den Teilbildern aus einem der Hochauflösungszeichen ist, wobei wenigstens ein Hochauflösungsteilbild eine Vielzahl an Pixeln besitzt und an mehr als einer Position in der Bildsammlung auftritt; und wobei die Hochauflösungsdarstellung die Niedrigauflösungszeichen und die Vielzahl an Positionen enthält; ein Datenspeicher (108), der mit dem Prozessor verbunden ist, worin die ersten und zweiten Sätze von digitaler Information gespeichert werden können.