DE19623327A1 - Verfahren zur Bearbeitung von Objekten auf Druckseiten - Google Patents

Verfahren zur Bearbeitung von Objekten auf Druckseiten

Info

Publication number
DE19623327A1
DE19623327A1 DE1996123327 DE19623327A DE19623327A1 DE 19623327 A1 DE19623327 A1 DE 19623327A1 DE 1996123327 DE1996123327 DE 1996123327 DE 19623327 A DE19623327 A DE 19623327A DE 19623327 A1 DE19623327 A1 DE 19623327A1
Authority
DE
Germany
Prior art keywords
delta
delta list
objects
printed
list
Prior art date
Legal status (The legal status is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the status listed.)
Withdrawn
Application number
DE1996123327
Other languages
English (en)
Inventor
Wilfried Helmut Soeker
Current Assignee (The listed assignees may be inaccurate. Google has not performed a legal analysis and makes no representation or warranty as to the accuracy of the list.)
Heidelberger Druckmaschinen AG
Original Assignee
Linotype Hell AG
Priority date (The priority date is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the date listed.)
Filing date
Publication date
Application filed by Linotype Hell AG filed Critical Linotype Hell AG
Priority to DE1996123327 priority Critical patent/DE19623327A1/de
Priority to EP97925872A priority patent/EP0978091A1/de
Priority to PCT/DE1997/001062 priority patent/WO1997048071A1/de
Priority to JP10501039A priority patent/JPH11513155A/ja
Publication of DE19623327A1 publication Critical patent/DE19623327A1/de
Withdrawn legal-status Critical Current

Links

Classifications

    • GPHYSICS
    • G06COMPUTING; CALCULATING OR COUNTING
    • G06TIMAGE DATA PROCESSING OR GENERATION, IN GENERAL
    • G06T11/002D [Two Dimensional] image generation
    • G06T11/60Editing figures and text; Combining figures or text
    • GPHYSICS
    • G06COMPUTING; CALCULATING OR COUNTING
    • G06KGRAPHICAL DATA READING; PRESENTATION OF DATA; RECORD CARRIERS; HANDLING RECORD CARRIERS
    • G06K15/00Arrangements for producing a permanent visual presentation of the output data, e.g. computer output printers
    • G06K15/02Arrangements for producing a permanent visual presentation of the output data, e.g. computer output printers using printers
    • GPHYSICS
    • G06COMPUTING; CALCULATING OR COUNTING
    • G06KGRAPHICAL DATA READING; PRESENTATION OF DATA; RECORD CARRIERS; HANDLING RECORD CARRIERS
    • G06K15/00Arrangements for producing a permanent visual presentation of the output data, e.g. computer output printers
    • G06K15/02Arrangements for producing a permanent visual presentation of the output data, e.g. computer output printers using printers
    • G06K15/025Simulating output on another printing arrangement, e.g. proof output
    • GPHYSICS
    • G06COMPUTING; CALCULATING OR COUNTING
    • G06KGRAPHICAL DATA READING; PRESENTATION OF DATA; RECORD CARRIERS; HANDLING RECORD CARRIERS
    • G06K2215/00Arrangements for producing a permanent visual presentation of the output data
    • G06K2215/0002Handling the output data
    • G06K2215/0062Handling the output data combining generic and host data, e.g. filling a raster
    • G06K2215/0065Page or partial page composition
    • GPHYSICS
    • G06COMPUTING; CALCULATING OR COUNTING
    • G06KGRAPHICAL DATA READING; PRESENTATION OF DATA; RECORD CARRIERS; HANDLING RECORD CARRIERS
    • G06K2215/00Arrangements for producing a permanent visual presentation of the output data
    • G06K2215/0002Handling the output data
    • G06K2215/0062Handling the output data combining generic and host data, e.g. filling a raster
    • G06K2215/0071Post-treatment of the composed image, e.g. compression, rotation

Description

Die Erfindung bezieht sich auf das Gebiet der elektronischen Reproduktionstech­ nik und betrifft ein Verfahren zur Bearbeitung von Objekten wie Bildern und grafi­ schen Elementen auf Druckseiten, die als hochaufgelöste Contone-Map vorliegen.
In der Reproduktionstechnik werden Druckvorlagen für Druckseiten erzeugt, die alle zu druckenden Elemente wie Texte, Grafiken und Bilder enthalten. Fig. 1 zeigt ein Beispiel für eine Druckseite. Für den farbigen Druck wird für jede Druckfarbe eine separate Druckvorlage erzeugt, die alle Elemente enthält, die in der jeweiligen Farbe gedruckt werden. Für den Vierfarbdruck sind das die Druckfarben Cyan, Magenta, Gelb und Schwarz (C, M, Y, K). In Sonderfällen wie dem Verpackungs­ druck können noch weitere Druckfarben hinzukommen, z. B. Gold, Silber, Schoko­ laden-Braun, usw. Die nach Druckfarben separierten Druckvorlagen werden auch Farbauszüge genannt. Die Druckvorlagen werden in der Regel gerastert (Screening) und in hoher Auflösung auf Filme belichtet, die dann zur Herstellung der Druckformen (Druckplatten, Druckzylinder) weiter verarbeitet werden. Alterna­ tiv können die Druckvorlagen in speziellen Recordern auch direkt auf Druckplatten belichtet werden. Zum Prüfen des Inhalts und der Farben der Druckseiten werden Druckvorlagen in Proofrecordern mit einem Aufzeichnungsprozeß belichtet, der in einer farbigen Ausgabe den Druckprozeß simuliert.
Der bisher nach dem Stand der Technik überwiegend verwendete Arbeitsablauf bei der Belichtung von Druckvorlagen für Druckseiten, die in der Seitenbeschrei­ bungssprache PostScript erzeugt worden sind, ist in Fig. 2 gezeigt. PostScript- Daten (1) werden einem Raster-Image-Prozessor (RIP) (2) zugeführt, der ein spe­ ziell für diese Aufgabe optimierter Rechner sein kann oder ein Programm auf ei­ nem Standardrechner. Im Normalfall werden in einem Vorprozeß die separierten PostScript-Daten (1) für jeden Farbauszug einer Druckseite erzeugt und an den RIP (2) weitergegeben (separated PostScript). Alternativ kann eine farbige Druck­ seite auch in einem einzigen PostScript-Daten bestand erzeugt werden (composite PostScript). Im folgenden wird der Fall der separierten PostScript-Daten (1) weiter erläutert.
In einem ersten Schritt werden die PostScript-Daten (1) in einem Interpreter (3) analysiert und in eine Folge von einfachen grafischen Objekten zerlegt. Dazu wird die Druckvorlage in horizontale Streifen (Bänder) geteilt, die nacheinander bearbei­ tet werden. Fig. 3 zeigt einen Bandausschnitt (9) mit einigen vom Interpreter er­ zeugten Objekten. Der Bandausschnitt (9) ist in Aufzeichnungspixel (10) aufgeteilt. Im Beispiel von Fig. 3 ist der Bandausschnitt 8 Pixel hoch, numeriert von 0 bis 7, und 32 Pixel breit, numeriert von 0 bis 31. Die Auflösung kann symmetrisch sein (in horizontaler und vertikaler Richtung gleich), oder auch unsymmetrisch, z. B. ho­ rizontal doppelt so groß wie vertikal. Die Objekte A bis E (11, 12, 13, 14, 15) be­ schreiben Teilsegmente von Text-, Grafik- oder Bildelementen, die in den Band­ ausschnitt (9) hineinfallen.
Die Objekte A bis E (11, 12, 13, 14, 15) werden vom Interpreter in einem Daten­ format ausgegeben, das als Display-Liste (4) (Fig. 2) bezeichnet wird. Das Daten­ format beschreibt für jedes Objekt seine geometrische Form und mit welchem Grauwert es gefüllt ist. In der Display-Liste (4) erscheinen die Objekte A bis E (11, 12, 13, 14, 15) nacheinander in der Reihenfolge, in der die zugehörigen Sei­ tenelemente in den PostScript-Daten beschrieben sind. Dabei können Objekte, die in der Display-Liste (4) später erscheinen, Objekte, die früher in der Display-Liste (4) erschienen sind, teilweise oder ganz überdecken. Im Beispiel von Fig. 3 wird das Objekt A (11) teilweise vom Objekt B (12) überdeckt. Ebenso überdecken die Objekte D (14) und E (15) das Objekt C (13).
Im RIP (2) wird die Display-Liste (4) in einem weiteren Schritt einem Rastergenera­ tor (5) zugeführt, der die Objekte der Display-Liste (4) nacheinander in mit Raster­ punkten gefüllte Flächen umsetzt und als Bitmap-Daten (6) in einen Bitmap-Spei­ cher (7) schreibt. Die Rasterpunktgröße wird dabei je nach dem Grauwert des Objekts in der Display-Liste (4) variiert. Die Bitmap-Daten (6) von Objekten, die später in der Display-Liste (4) erscheinen, überschreiben jeweils die entsprechen­ den Bereiche des Bitmap-Speichers (7). Nachdem alle Objekte eines Bandes vom Rastergenerator (5) gerastert und in den Bitmap-Speicher (7) geschrieben wurden, wird der Inhalt des Bitmap-Speichers (7) als Steuersignalwerte an den Recorder (8) weitergeleitet und dort belichtet.
Diese herkömmliche Arbeitsweise hat den Nachteil, daß bei komplexen Inhalten der Druckseite die Interpretation der PostScript-Daten für bestimmte Seitenaus­ schnitte so lange dauern kann, daß die nachfolgenden Arbeitsschritte (Rasterung, Belichtung) auf die Beendigung der Interpretation warten müssen. Das ist beson­ ders dann der Fall, wenn sich in einem Bandausschnitt viele Objekte überlagern. Dann müssen für alle Objekte die Bitmap-Daten erzeugt werden, von denen später aber nur die oberste Schicht der Überlagerungen, d. h. nur ein kleiner Teil für die Belichtung gebraucht wird. Daher ist für diese Arbeitsweise ein Recorder erforder­ lich, der bei Bedarf während der Belichtung anhalten und wieder starten kann. Ein solcher Recorder stellt sehr hohe Anforderungen an die mechanische und optische Präzision seiner Konstruktion und ist deshalb aufwendig und teuer.
In der deutschen Patentanmeldung der Anmelderin "Verfahren zur Generierung ei­ ner Contone-Map", Aktenzeichen 195 13 105.3, und in der zugehörigen PCT-An­ meldung, Aktenzeichen PCT/DE 96/00585, wird daher ein verbesserter Arbeits­ ablauf für die Interpretation und Belichtung von PostScript-Daten beschrieben, bei dem als Zwischenformat eine Contone-Map in einem Datenformat erzeugt wird, das als Delta-Liste bezeichnet wird. Die Contone-Map enthält für jedes Belichtungspixel nur einen Grauwert und ist daher überlagerungsfrei. Sie ist außerdem daten­ komprimiert und kann vor der Rasterung und Belichtung mit geringem Bedarf an Speicherplatz zwischengespeichert werden. Das hat den Vorteil, daß die Rasterung und Belichtung unabhängig von der Interpretation der PostScript-Daten mit hoher Geschwindigkeit erfolgen kann, wobei der Recorder kontinuierlich ohne Start-Stop- Betrieb während der Belichtung einer Druckseite durchläuft und deshalb einfacher und preiswerter konstruiert werden kann.
Fig. 4 zeigt diesen verbesserten Arbeitsablauf. Die PostScript-Daten (1), die den Inhalt der Druckvorlage beschreiben, werden dem RIP (2) zugeführt, wo sie in ei­ nem ersten Schritt vom Interpreter (3) analysiert und in eine Display-Liste (4) um­ gewandelt werden, wie es zuvor bereits erläutert wurde. In einem zweiten Schritt wird aus der Display-Liste von einem Delta-Listen-Generator (16) die überlage­ rungsfreie Contone-Map der Delta-Liste (17) erzeugt und z. B. auf einem Platten­ speicher (18) gespeichert. Wenn die Druckseiten belichtet werden sollen, werden die gespeicherten Delta-Listen der Druckvorlagen, z. B. die verschiedenen Farb­ auszüge einer Druckseite, zu einem späteren Zeitpunkt nacheinander vom Plat­ tenspeicher (18) abgerufen, vom Rastergenerator (5) in Bitmap-Daten (6) umge­ wandelt und im Recorder (8) belichtet. Die Rasterung der Delta-Liste geschieht dabei schritthaltend mit der Recordergeschwindigkeit.
Die bisher beschriebenen Arbeitsabläufe haben den Nachteil, daß sie keine Nach­ bearbeitung der Druckseiten nach dem Interpretieren der PostScript-Daten ermög­ lichen. Eine solche Nachbearbeitung ist erwünscht, um letzte Änderungen vor dem Druckbeginn vorzunehmen. Dies soll mit wenig Zeitaufwand und kostengünstig geschehen. Solche erwünschten letzten Änderungen sind z. B. der Austausch ei­ nes Bildes, einer Grafik oder eines Textes in der Druckseite, um einen spät er­ kannten Fehler zu korrigieren oder um ein aktuelleres Bild einzusetzen.
Eine andere typische Nachbearbeitung ist der Austausch des Rasterverfahrens für ein bestimmtes Bild, das mit dem zunächst gewählten Rasterverfahren ein stören­ des Moir´ erzeugt. Solche Moir´-Erscheinungen treten auf, wenn das Bild sehr feine Strukturen enthält, z. B. ein Streifenmuster in einer Bluse bei einer Modeauf­ nahme. In einem solchen Fall soll das Rasterverfahren für dieses Bild nachträglich z. B. durch eine frequenzmodulierte Rasterung ersetzt werden, die kein Moir´ mit den Strukturen im Bild erzeugt.
Eine weitere typische Nachbearbeitung ist das Trapping, d. h. die Erzeugung von überstehenden Rändern für einige der Farbauszüge an den Grenzen, wo sich far­ bige Seitenobjekte berühren. Beim Übereinanderdrucken können sich die Farb­ auszüge in der Druckmaschine etwas gegeneinander verschieben (Registerfehler). An den Grenzen zwischen farbigen Seitenobjekten können dadurch schmale wei­ ße Lücken entstehen, die sehr auffällig und störend sind. Durch die überstehenden Trapping-Ränder wird dafür gesorgt, daß trotz der Verschiebung der Farbauszüge sich stets einige der Farben überlappen, so daß die weißen Lücken nicht entste­ hen können. Grundsätzlich wäre es möglich, die Trapping-Ränder bereits beim Entwurf einer Druckseite in die PostScript-Daten einzuarbeiten. Dies ist jedoch nicht erwünscht, da die Regeln, nach denen die Trapping-Ränder erzeugt werden, ihre Breite, usw. von den Eigenschaften der Druckmaschine abhängen, die aber zum Zeitpunkt des ersten Entwurfs einer Druckseite nicht immer bekannt sind. Da­ her ist das Trapping eine Aufgabe, die erst unmittelbar vor der Ausgabe der Druck­ vorlagen durchgeführt werden muß, wenn bekannt ist, auf welcher Druckmaschine die Seiten gedruckt werden sollen.
Schließlich kann es erforderlich werden, in einer Nachbearbeitungsstufe mehrere Teilseiten, die als Contone-Maps vorliegen, zu einer neuen Druckseite zu montie­ ren. Solche Teilseiten können z. B. fertige Werbeanzeigen sein, die auf einem an­ deren Produktionsweg entstanden sind und deshalb nicht in Form von PostScript- Daten vorliegen.
Nachbearbeitungen der geschilderten Art sind nach dem Stand der Technik mit dem Arbeitsablauf nach Fig. 2 nicht möglich, da von der Interpretation der Post- Script-Daten bis zur Belichtung der gerasterten Bitmap-Daten keine Speicherung von Zwischenergebnissen erfolgt, die für die Nachbearbeitung genutzt werden könnten. Grundsätzlich wäre es möglich, die Bitmap-Daten vor der Belichtung zu speichern, aber die zu speichernde Datenmenge wäre für die typische Auflösung von Recordern für Druckvorlagen (z. B. 1333 Pixel/cm) sehr groß. Für die Bitmap- Daten der vier Druckfarben einer DIN A3 Seite müßten 1108 MByte gespeichert werden, so daß die Speicherung aufwendig und teuer wird, besonders wenn meh­ rere Seiten einer Broschüre, eines Katalogs, usw. gespeichert werden müssen. Ei­ ne Nachbearbeitung der Druckseite erfordert deshalb die entsprechende Änderung in den PostScript-Daten und das nochmalige Interpretieren, Rastern und Belichten dieser geänderten Daten.
In dem verbesserten Arbeitsablauf nach Fig. 4 werden zwar die Contone-Maps (Delta-Listen) der Druckvorlagen zwischengespeichert, aber die Delta-Listen ent­ halten für jedes Pixel nur noch Informationen über seinen Grauwert und mit wel­ chem Rasterverfahren es in die Bitmap-Daten umgesetzt werden soll. Die Infor­ mation, welches Pixel der Delta-Liste zu welchem ursprünglichen Seitenobjekt (Bild, Grafik, Text) gehört, ist darin nicht mehr enthalten. Diese Information über die Lage der Objektgrenzen wird aber benötigt, um z. B. ein Bild nachträglich in der Delta-Liste auszutauschen oder für das Trapping die Grenzen zu finden, an denen sich farbige Seitenobjekte berühren. Für das Trapping braucht man außerdem die Information, ob eine Farbgrenze mit dem Rand eines Seitenobjekts übereinstimmt. Für Farbgrenzen innerhalb eines Bildes dürfen keine Trapping-Ränder erzeugt werden. Beim nachträglichen Montieren von Teilseiten muß bekannt sein, wo auf der einen Seite eine noch nicht belegte Fläche (transparentes "Loch") ist, in die die andere Teilseite passend eingefügt werden soll. Da alle diese Informationen in den gespeicherten Delta-Listen fehlen, ist auch in diesem Fall eine auf Seitenobjekte bezogene Nachbearbeitung nicht möglich.
Es ist daher die Aufgabe der vorliegenden Erfindung, die zuvor genannten Nachtei­ le zu vermeiden und ein Verfahren anzugeben, mit dem die Nachbearbeitung von komprimierten und überlagerungsfreien Contone-Maps (Delta-Listen) der Drucksei­ ten ermöglicht wird, ohne die PostScript-Daten der Seiten zu ändern und erneut zu interpretieren.
Diese Aufgabe wird durch die Verwendung einer zusätzlich zur belichtbaren Delta- Liste erzeugten Contone-Map gelöst, die die Information über den Typ und die La­ ge der ursprünglichen Seitenobjekte enthält und die auch als Objekt-Delta-Liste bezeichnet wird. Die Objekt-Delta-Liste dient dazu, für objekt-bezogene Nachbear­ beitungen (Austausch von Bildern, Bearbeitung von Farbgrenzen zwischen Objek­ ten, usw.) die Pixel in der belichtbaren Delta-Liste zu identifizieren, die ausge­ tauscht bzw. verändert werden müssen.
Die Erfindung wird nachfolgend anhand der Fig. 1 bis 7 näher beschrieben.
Es zeigen:
Fig. 1 ein Beispiel für eine Druckseite mit Text-, Grafik- und Bildelementen (Stand der Technik),
Fig. 2 den Arbeitsablauf bei der Belichtung von PostScript-Daten (Stand der Technik),
Fig. 3 einen Ausschnitt aus einem Band mit Objekten, die der Interpreter erzeugt (Stand der Technik),
Fig. 4 den Arbeitsablauf bei der Belichtung von PostScript-Daten mit der Erzeu­ gung der Delta-Liste (Stand der Technik),
Fig. 5 die Unterteilung einer Druckvorlage in Bänder und Zonen,
Fig. 6 den Arbeitsablauf bei der Belichtung von PostScript-Daten mit der Erzeu­ gung der belichtbaren Delta-Listen und der Objekt-Delta-Listen sowie der Nachbearbeitung auf der Basis der Delta-Listen und
Fig. 7 ein Beispiel für den Inhalt einer Druckvorlage und den Inhalt der dazuge­ hörigen Objekt-Delta-Liste.
Allgemeines
In der deutschen Patentanmeldung der Anmelderin "Verfahren zur Generierung einer Contone-Map", Aktenzeichen 195 13 105.3, und in der zugehörigen PCT-An­ meldung, Aktenzeichen PCT/DE 96/00585, wird die Erzeugung einer belichtba­ ren Contone-Map (Delta-Liste) aus den PostScript-Daten einer Druckseite ausführ­ lich beschrieben. An dieser Stelle wird dies deshalb nur soweit erläutert, wie es für das Verständnis des erfindungsgemäßen Verfahrens zur Erzeugung einer Objekt- Delta-Liste auf der Basis einer Contone-Map erforderlich ist.
Eine belichtbare Contone-Map beschreibt eine zu reproduzierende Druckvorlage in Form von Grauwerten, in der jedem Pixel ein Grauwert zugeordnet ist. Die Conto­ ne-Map wird aus den Seitenbeschreibungsdaten (PostScript-Daten) der zu repro­ duzierenden Druckseite erzeugt. Die Grauwerte der Contone-Map können direkt zur Ansteuerung des Recorders verwendet werden, wenn der Aufzeichnungspro­ zeß kontinuierliche Tonwerte wiedergeben kann, wie z. B. ein Proof-Ausgabegerät. Für Aufzeichnungsprozesse, die nur zwei Tonwerte wiedergeben können (weiß bzw. schwarz), werden die Grauwerte in einem Rastergenerator, der dem Recor­ der vorgeschaltet ist, vor der Aufzeichnung in Rasterpunkte umgesetzt, mit denen die Grauwerte für das Auge simuliert werden. Im Recorder werden die Druckvorla­ gen durch mindestens einen Belichtungsstrahl pixel- und zeilenweise auf das Auf­ zeichnungsmaterial belichtet. Während der Belichtung bestimmen die Steuer­ signalwerte, welche Pixel als Teile der Rasterpunkte belichtet oder nicht belichtet werden, indem die Steuersignalwerte den Belichtungsstrahl entsprechend ein- und ausschalten.
Für die Aufbereitung der Delta-Liste werden die Überlagerungen der Objekte in der Display-Liste (Fig. 3) geeignet eliminiert und anschließend die Daten möglichst hoch komprimiert. Die Delta-Liste ist überlagerungsfrei, weil es für jedes Pixel nur einen Grauwert in der Delta-Liste gibt. Bei der Wahl des Komprimierungs-Verfah­ rens muß ein Kompromiß zwischen einem hohen Kompressionsfaktor, einer schnellen Komprimierung und vor allem einer sehr schnellen Dekomprimierung gefunden werden.
In der Delta-Liste sind im wesentlichen Grauwerte und Raster-Informationen ent­ halten, die durch einen Rastergenerator schritthaltend mit der Recorder-Geschwin­ digkeit in Bitmap-Daten umgesetzt und ausgegeben werden können.
Die Erzeugung der Delta-Liste und die Rasterung können mit unterschiedlichen Auflösungen durchgeführt werden. Eine vorteilhafte Variante ist z. B. die Berech­ nung der Delta-Liste mit 666,5 Pixel/cm und die Rasterung der Grauwerte mit 1333 Pixel/cm. Die Rasterung kann auch unsymmetrisch erfolgen, beispielsweise mit 2666 Pixel/cm in Zeilenrichtung und 1333 Pixel/cm senkrecht zur Zeilenrich­ tung.
Das Datenformat der Delta-Liste ist Byte-orientiert. Jedes Byte ist ein Befehl, dem in manchen Fällen Datenbytes nachfolgen. Die Codierung der Befehle ist derart gewählt, daß eine möglichst hohe Kompression der Daten erreicht wird. Am An­ fang jeder Delta-Liste befinden sich allgemeine Informationen, z. B. die Länge der Delta-Liste und die Länge einer Scanlinie. Außerdem enthält die Delta-Liste Infor­ mationen über das Rasterverfahren (Screening), nach dem die Objekte vom Ra­ stergenerator in Bitmaps umgesetzt werden sollen.
Da in verschiedenen Teilen einer Druckseite sehr unterschiedliche Seiteninhalte mit verschiedenen Eigenschaften bezüglich der Komprimierung vorkommen kön­ nen, wird die Druckseite bei der Generierung der Delta-Liste in horizontale Streifen (Bänder) und diese weiter in aufeinanderfolgende Abschnitte (Zonen) unterteilt. In den Bändern und Zonen können dann jeweils optimierte Komprimierungsverfahren angewendet werden.
Fig. 5 zeigt die Einteilung einer Druckvorlage (19) in Bänder (20) und Zonen (21). Die Höhe der Bänder und die Breite der Zonen ist beliebig, jedoch ist es für die Verarbeitung vorteilhaft, wenn die Bänder alle gleich hoch und die Zonen alle gleich breit sind. Ferner ist es vorteilhaft, wenn die Bandhöhe und die Zonenbreite Potenzen von 2 sind.
Da oft große Teile der Information auf einer Druckseite aus wenigen unterschiedli­ chen Grauwerten bestehen, z. B. nur aus Schwarz/Weiß-Information (Text), wer­ den Grauwerte in der Delta-Liste mit verschiedener Bitzahl codiert, z. B. 1 Bit/Grau­ wert für Schwarz/Weiß-Information und 8 Bit je Grauwert für Contone-Information. Diese Maßnahme trägt ebenfalls zur Komprimierung der Delta-Liste bei.
Die Komprimierung der Daten im Datenformat der Delta-Liste basiert auf dem Runlength-Verfahren, das für die speziellen Anforderungen modifiziert wird. Im Datenstrom existieren Kommando-Bytes, die von einer Lauflänge und/oder einem oder mehreren Grauwerten begleitet sein können. Die Komprimierung berücksich­ tigt auch Wiederholungen des ganzen Inhalts einer Zone in Y-Richtung, wobei die X-Richtung die Haupt-Scanrichtung und die Y-Richtung die Neben-Scanrichtung ist. In der folgenden Tabelle werden beispielhaft einige Delta-Listen Kommandos und ihre Codierung erläutert, die zum Verständnis der Erzeugung der Delta-Liste wichtig sind.
Das erste Byte bzw. die ersten Bits im ersten Byte jedes Kommandos sind ein Kennzeichen dafür, um welches Kommando es sich handelt und wieviele Bytes mit Parametern für das Kommando folgen. Dieser Aufbau stellt sicher, daß bei der Decodierung der Delta-Liste jedes Kommando eindeutig erkannt und richtig inter­ pretiert werden kann.
Jedes neue Band wird mit dem Kommando LHD_BAND und jede neue Zeile innerhalb des Bandes mit dem Kommando LHD_START eingeleitet. Am Anfang jeder Zone in der Zeile steht das Kommando LHD_ZONE, in dem mit dem Para­ meter "Y-cmpr" codiert ist, über wieviele Zeilen sich der Inhalt dieser Zone in Y-Rich­ tung wiederholt. Der Parameter "bits" gibt an, mit wieviel Bits die Grauwerte innerhalb der Zone codiert sind, z. B. 1 Bit für Schwarz/Weiß-Information, 8 Bit für Contone-Information mit normaler Stufung (256 Stufen) und 12 Bit für Contone- Information mit feinerer Stufung (4096 Stufen).
Mit dem Kommando LHD_SCREEN wird ein Rasterverfahren ausgewählt, das durch den Parameter "Screenindex" gekennzeichnet ist. Mit dem ausgewählten Rasterverfahren soll der Rastergenerator alle folgenden Grauwerte in der Delta- Liste rastern, bis wieder ein neues Rasterverfahren ausgewählt wird. Die Para­ meter der Rasterverfahren wie Rasterweite, Rasterwinkel, Rasterpunktform sind unter der Nummer "Screenindex" im Rastergenerator gespeichert, oder sie werden der erzeugten Delta-Liste mit weiteren Delta-Listen Kommandos hinzugefügt.
Eine Lauflänge von sich wiederholenden Grauwerten innerhalb einer Zone wird mit den Kommandos LHD_REPEATS oder LHD_REPEAT beschrieben. Im Kom­ mando LHD_REPEATS codiert eine 6 Bit-Binärzahl [nnnnnn] im ersten Byte eine Lauflänge zwischen 1 und 64, im Kommando LHD_REPEAT wird eine Lauflänge zwischen 1 und 4096 durch eine 12 Bit-Binärzahl codiert ([nnnn] im ersten Byte und [kkkk kkkk] im zweiten Byte). Jeweils das letzte Byte dieser Kommandos gibt den Grauwert an, der wiederholt werden soll.
Wenn aufeinanderfolgende Grauwerte in der Zeile nicht gleich sind und deshalb nicht mit einer Lauflänge komprimiert werden können, wird eine solche Sequenz mit dem Kommando LHD_UCDATA beschrieben. Eine 5 Bit-Binärzahl [nnnnn] im ersten Byte gibt an, wieviele unkomprimierte Grauwerte folgen.
Bei der Erzeugung der Delta-Liste werden die Zeilen eines Bandes von oben nach unten abgearbeitet, und die Zonen einer Zeile von links nach rechts. Die erzeugten Kommandos und Lauflängen werden dabei dicht gepackt aneinandergehängt, d. h. für die Zonen, für die keine Lauflängen erzeugt werden, wird nichts in die Delta- Liste eingetragen. Aufgrund des Code für die Komprimierung in Y-Richtung im Kommando LHD_ZONE kann der Rastergenerator die Delta-Liste so decodieren, daß die Lauflängen wieder den richtigen Zonen zugeordnet werden.
Die Erzeugung der Objekt-Delta-Liste
Die Fig. 6 zeigt den Arbeitsablauf nach der vorliegenden Erfindung, wobei für eine Druckvorlage neben einer belichtbaren Delta-Liste zusätzlich eine Objekt-Delta- Liste erzeugt wird. Wie bereits in Fig. 4 erläutert, werden die PostScript-Daten (1) der Druckvorlage in einem RIP (2) durch den Interpreter (3) in eine Display-Liste (4) umgewandelt, aus der von dem Delta-Listen-Generator (16) eine belichtbare Delta-Liste (17) erzeugt wird. Zusätzlich wird ebenfalls vom Delta-Listen-Generator (16) eine Objekt-Delta-Liste (22) erzeugt, die die Information über den Typ (Bilder, Grafiken, Texte) und die Lage der Seitenobjekte enthält, denen die Grauwerte in der belichtbaren Delta-Liste (17) zuzuordnen sind. Beide Delta-Listen werden für die weitere Verarbeitung zwischengespeichert, z. B. auf einem Plattenspeicher (18).
Für die Aufgaben der Nachbearbeitung (Austausch von Seitenobjekten, Erzeu­ gung von Trapping-Rändern, usw.) in einer Nachbearbeitungs-Workstation (23) werden die belichtbaren Delta-Listen (17) und die zugehörigen Objekt-Delta-Listen (22) einem geeigneten Nachbearbeitungsverfahren (24) zugeführt. Je nach der Art der Nachbearbeitung kann es erforderlich sein, mehr als eine belichtbare Delta- Liste und zugehörige Objekt-Delta-Liste zu verarbeiten. Wenn ein Bild ausge­ tauscht werden soll oder die Trapping-Ränder für aneinandergrenzende Seitenob­ jekte erzeugt werden sollen, werden die Delta-Listen aller Farbauszüge der Druck­ seite benötigt. Wenn zwei oder mehr Teilseiten zu einer neuen Druckseite kombi­ niert werden sollen, werden die Delta-Listen aller Farbauszüge aller Teilseiten be­ nötigt.
Als Ergebnis der Nachbearbeitung entstehen modifizierte belichtbare Delta-Listen (25) und gegebenenfalls auch modifizierte Objekt-Delta-Listen (26), die wieder zwischengespeichert werden, z. B. auf einem Plattenspeicher (27). Wenn erforder­ lich, können die modifizierten Delta-Listen einer weiteren Nachbearbeitung unter­ worfen werden, z. B. einer Korrektur der ersten Nachbearbeitung. Für die RIP-Funk­ tionen und für die Nachbearbeitung brauchen nicht notwendigerweise ge­ trennte Rechnersysteme vorgesehen zu werden, sie können auch auf einem Rechnersystem ausgeführt werden.
Im weiteren Arbeitsablauf werden die modifizierten belichtbaren Delta-Listen (25) dem Rastergenerator (5) zugeführt, der sie nach den in den Delta-Listen enthalte­ nen Rasterinformationen in gerasterte Bitmap-Daten (6) umwandelt und an den Recorder (8) zur Belichtung weiterleitet.
Für die Objekt-Delta-Liste wird das gleiche zuvor beschriebene Datenformat ver­ wendet wie für die belichtbaren Delta-Listen, d. h. ebenfalls in Lauflängen codierte Grauwerte und Werte für den Screenindex. Im Unterschied zu den belichtbaren Delta-Listen haben die Grauwerte und die Screenindex-Werte in der Objekt-Delta- Liste jedoch eine andere Bedeutung. Jedem Seitenobjekt wird eine andere Kombi­ nation von Screenindex-Wert und Grauwert als Objektnummer zugeordnet, und alle Pixel, die in der Druckvorlage von dem Seitenobjekt belegt sind, erhalten in der Objekt-Delta-Liste diese Kombination von Screenindex-Wert und Grauwert, d. h. die zugehörige Objektnummer. Da alle Pixel eines Objekts in der Objekt-Delta- Liste den gleichen Grauwert erhalten, ergibt sich aus der Lauflängencodierung ei­ ne hohe Datenkomprimierung und damit nur ein geringer Speicherbedarf für die Objekt-Delta-Listen. Aufgrund der Information über die Objektnummern kann bei der Nachbearbeitung von belichtbaren Delta-Listen in der zugehörigen Objekt- Delta-Liste für jedes Pixel nachgeschlagen werden, zu welchem Objekt es gehört.
Die Fig. 7a und 7b zeigen dies an einem Beispiel. Die Druckvorlage (28) in Fig. 7a enthält das Bild (29) und das Bild (30) sowie ein Grafikelement (31) mit konstanter Farbe. Fig. 7b zeigt den Inhalt der zugehörigen Objekt-Delta-Liste (32). Die Fläche, die in der Druckvorlage vom Bild (29) belegt ist, enthält in der Objekt-Delta-Liste eine Fläche (33) mit gleicher Größe und gleichem Umriß, in der alle Pixel mit dem gleichen Screenindex und Grauwert gefüllt sind, z. B. mit dem Screenindex = 128 und dem Grauwert = 0. Ebenso ist an der Stelle des Bildes (30) in der Objekt- Delta-Liste eine gleich große Fläche (34), die z. B. mit dem Screenindex = 128 und dem Grauwert = 1 gefüllt ist. Für das Grafikobjekt (31) enthält die Objekt-Delta- Liste eine äquivalente Fläche (35), die z. B. mit dem Screenindex = 1 und dem Grauwert = 0 gefüllt ist.
Die Zuordnung von Screenindex und Grauwert zu einem Objekt ist beliebig. Die folgende Tabelle zeigt eine mögliche Zuordnung als Beispiel.
Eine "Imagemask" ist ein PostScript-Objekt, das in Form von Bitmap-Daten vorliegt und in dem den "1-Bits" ein fester Grauwert oder Farbwert zugewiesen wird wäh­ ren die "0-Bits" leer bleiben, d. h. "Löcher" in der Imagemask sind.
In der obigen beispielhaften Zuordnung haben alle transparenten Flächen, alle Grafik-Objekte (= mit konstanter Farbe belegte Flächen) und alle Imagemask- Objekte jeweils die gleiche Kombination von Screenindex und Grauwert, d. h. für diese Objekte wird in der Objekt-Delta-Liste nur der Objekttyp gekennzeichnet und individuelle Objekte werden nicht unterschieden. Die Zuordnung kann selbstver­ ständlich auch so gewählt werden, daß jedes individuelle Objekt eine eigene Ob­ jekt-Nummer erhält, die als eine Kombination von Screenindex und Grauwert co­ diert ist. Ob in der Objekt-Delta-Liste individuelle Objekte oder nur der Objekttyp unterschieden werden sollen, hängt davon ab, welcher Grad der Unterscheidbar­ keit für die beabsichtigten Schritte der Nachbearbeitung erforderlich ist. In dem obigen Beispiel ist für jedes individuelle Bild eine andere Kombination von Screen­ index und Grauwert als Objekt-Nummer vorgesehen, d. h. alle Bilder können an­ hand der Objekt-Delta-Liste einzeln unterschieden und individuell nach bearbeitet werden.

Claims (10)

1. Verfahren zur Bearbeitung von Objekten auf Druckseiten, die als digitale Da­ ten in Form von pixel- und zeilenweise geordneten Contone-Maps (Delta- Listen) vorliegen, dadurch gekennzeichnet, daß eine weitere Contone-Map zur Kennzeichnung der auf der Druckseite vorhandenen Objekte erzeugt wird (Objekt-Delta-Liste), in der alle Pixel, die zu einem Objekt gehören, eine ob­ jekt-spezifische Kennung erhalten.
2. Verfahren nach Anspruch 1, dadurch gekennzeichnet, daß die objekt­ spezifische Kennung den Typ des Objekts kennzeichnet.
3. Verfahren nach Anspruch 1 oder 2, dadurch gekennzeichnet, daß die objekt­ spezifische Kennung jedes individuelle Objekt unterschiedlich kennzeichnet.
4. Verfahren nach einem der Ansprüche 1 bis 3, dadurch gekennzeichnet, daß die weitere Contone-Map (Objekt-Delta-Liste) erzeugt wird, indem eine pro­ grammierte Seitenbeschreibung des Inhaltes der Druckseite, bestehend aus Bild-, Grafik- und Textinformation, durch einen Interpreter verarbeitet wird, die Objekte der Druckseite identifiziert werden, die Objekte in Pixel umgewandelt werden und den Pixeln jedes Objekts die objekt-spezifische Kennung zuge­ wiesen wird.
5. Verfahren nach einem der Ansprüche 1 bis 4, dadurch gekennzeichnet, daß die Objekte in der weiteren Contone-Map (Objekt-Delta-Liste) überlagerungs­ frei sind, d. h. jedem Pixel die Kennung für genau ein Objekt zugewiesen wird.
6. Verfahren nach einem der Ansprüche 1 bis 5, dadurch gekennzeichnet, daß bei einer objekt-bezogenen Bearbeitung der Druckseite anhand der objekt­ spezifischen Kennungen in der weiteren Contone-Map (Objekt-Delta-Liste) ermittelt wird, welche Pixel der Druckseite zu bearbeiten sind und welche nicht.
7. Verfahren nach einem der Ansprüche 1 bis 6, dadurch gekennzeichnet, daß die objekt-spezifische Kennung eine Nummer für ein Rasterverfahren (Screenindex-Wert), ein Grauwert oder eine Kombination von Screenindex- Wert und Grauwert ist.
8. Verfahren nach einem der Ansprüche 1 bis 7, dadurch gekennzeichnet, daß die weitere Contone-Map (Objekt-Delta-Liste) nach einer Runlength-Codierung datenkomprimiert ist.
9. Verfahren nach einem der Ansprüche 1 bis 8, dadurch gekennzeichnet, daß die weitere Contone-Map (Objekt-Delta-Liste) durch Reduzierung der Zahl der Bits je Grauwert datenkomprimiert ist.
10. Verfahren nach einem der Ansprüche 1 bis 9, dadurch gekennzeichnet, daß die weitere Contone-Map (Objekt-Delta-Liste) durch Differenz-Codierung zwi­ schen den Grauwerten benachbarter Pixel datenkomprimiert ist.
DE1996123327 1996-06-12 1996-06-12 Verfahren zur Bearbeitung von Objekten auf Druckseiten Withdrawn DE19623327A1 (de)

Priority Applications (4)

Application Number Priority Date Filing Date Title
DE1996123327 DE19623327A1 (de) 1996-06-12 1996-06-12 Verfahren zur Bearbeitung von Objekten auf Druckseiten
EP97925872A EP0978091A1 (de) 1996-06-12 1997-05-26 Verfahren zur bearbeitung von objekten auf druckseiten
PCT/DE1997/001062 WO1997048071A1 (de) 1996-06-12 1997-05-26 Verfahren zur bearbeitung von objekten auf druckseiten
JP10501039A JPH11513155A (ja) 1996-06-12 1997-05-26 印刷頁におけるオブジェクトの処理方法

Applications Claiming Priority (1)

Application Number Priority Date Filing Date Title
DE1996123327 DE19623327A1 (de) 1996-06-12 1996-06-12 Verfahren zur Bearbeitung von Objekten auf Druckseiten

Publications (1)

Publication Number Publication Date
DE19623327A1 true DE19623327A1 (de) 1997-12-18

Family

ID=7796664

Family Applications (1)

Application Number Title Priority Date Filing Date
DE1996123327 Withdrawn DE19623327A1 (de) 1996-06-12 1996-06-12 Verfahren zur Bearbeitung von Objekten auf Druckseiten

Country Status (4)

Country Link
EP (1) EP0978091A1 (de)
JP (1) JPH11513155A (de)
DE (1) DE19623327A1 (de)
WO (1) WO1997048071A1 (de)

Cited By (4)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
DE10012521A1 (de) * 2000-03-15 2001-09-27 Heidelberger Druckmasch Ag Verfahren zur Komprimierung von Druckdaten
DE10128858A1 (de) * 2001-06-15 2003-02-13 Heidelberger Druckmasch Ag Verfahren zur Erzeugung von Überfüllrahmen in einer Druckseite
US6701002B1 (en) 1999-06-30 2004-03-02 Agilent Technologies, Inc. Test method for image pickup devices
WO2007096283A1 (de) * 2006-02-24 2007-08-30 OCé PRINTING SYSTEMS GMBH Verfahren und vorrichtung zum verarbeiten eines druckdatenstroms zum erzeugen mehrfarbiger druckbilder mit hilfe eines hochleistungsdrucksystems

Citations (5)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US5131058A (en) * 1990-08-24 1992-07-14 Eastman Kodak Company Method for obtaining output-adjusted color separations
US5267326A (en) * 1992-03-31 1993-11-30 Eastman Kodak Company Bitmap image segmentation using a charge model for pixels
US5425137A (en) * 1993-01-26 1995-06-13 Us Jvc Corporation System and method for processing images using computer-implemented software objects representing lenses
EP0684583A2 (de) * 1994-05-16 1995-11-29 Bayer Corporation Verfahren zur Herstellung einer Datenbank mit skalierbaren Schrifttypen
EP0700197A1 (de) * 1994-08-31 1996-03-06 Adobe Systems Inc. Verfahren und Gerät zur Erzeugung einer hybriden Datenstruktur zur Anzeige eines Rasterbildes

Family Cites Families (5)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US5125072A (en) * 1989-07-31 1992-06-23 Eastman Kodak Company Efficient data storage system for gray-scale printers
JP3092711B2 (ja) * 1990-09-11 2000-09-25 キヤノン株式会社 出力制御装置及び方法
US5539865A (en) * 1992-11-10 1996-07-23 Adobe Systems, Inc. Method and apparatus for processing data for a visual-output device with reduced buffer memory requirements
JPH07323602A (ja) * 1994-05-31 1995-12-12 Canon Inc 印刷装置および印刷装置のオブジェクト描画方法
JP2898889B2 (ja) * 1994-09-29 1999-06-02 大日本スクリーン製造株式会社 製版処理方法

Patent Citations (5)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US5131058A (en) * 1990-08-24 1992-07-14 Eastman Kodak Company Method for obtaining output-adjusted color separations
US5267326A (en) * 1992-03-31 1993-11-30 Eastman Kodak Company Bitmap image segmentation using a charge model for pixels
US5425137A (en) * 1993-01-26 1995-06-13 Us Jvc Corporation System and method for processing images using computer-implemented software objects representing lenses
EP0684583A2 (de) * 1994-05-16 1995-11-29 Bayer Corporation Verfahren zur Herstellung einer Datenbank mit skalierbaren Schrifttypen
EP0700197A1 (de) * 1994-08-31 1996-03-06 Adobe Systems Inc. Verfahren und Gerät zur Erzeugung einer hybriden Datenstruktur zur Anzeige eines Rasterbildes

Non-Patent Citations (1)

* Cited by examiner, † Cited by third party
Title
ADNER,Wolfgang: Universelle Bildbearbeitung: Geschwindigkeit zählt. In: Elektronik, 24/ 29.11.1985, S.97-99 *

Cited By (7)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US6701002B1 (en) 1999-06-30 2004-03-02 Agilent Technologies, Inc. Test method for image pickup devices
DE10012521A1 (de) * 2000-03-15 2001-09-27 Heidelberger Druckmasch Ag Verfahren zur Komprimierung von Druckdaten
DE10012521C2 (de) * 2000-03-15 2002-12-19 Heidelberger Druckmasch Ag Verfahren zur Komprimierung von Druckdaten
DE10128858A1 (de) * 2001-06-15 2003-02-13 Heidelberger Druckmasch Ag Verfahren zur Erzeugung von Überfüllrahmen in einer Druckseite
US7173738B2 (en) 2001-06-15 2007-02-06 Heidelberger Druckmaschinen Ag Method of producing traps in a print page
WO2007096283A1 (de) * 2006-02-24 2007-08-30 OCé PRINTING SYSTEMS GMBH Verfahren und vorrichtung zum verarbeiten eines druckdatenstroms zum erzeugen mehrfarbiger druckbilder mit hilfe eines hochleistungsdrucksystems
US8085439B2 (en) 2006-02-24 2011-12-27 Oce Printing Systems Gmbh Method and device for processing a print data flow for producing multicolor printed images using a high performance printing system

Also Published As

Publication number Publication date
EP0978091A1 (de) 2000-02-09
WO1997048071A1 (de) 1997-12-18
JPH11513155A (ja) 1999-11-09

Similar Documents

Publication Publication Date Title
EP0764310B1 (de) Verfahren zur generierung einer contone-map
DE69817029T2 (de) Mischung von komprimierten rasterbildern in einem drucksystem
DE69938486T2 (de) Bildverarbeitungsverfahren, -system und -gerät, und Speichermedium
DE10204751B4 (de) Verfahren zur Konvertierung eines Linework Datenformats in das Format einer Seitenbeschreibungssprache
WO2000057632A1 (de) Verfahren zur erzeugung von überfülllungskonturen in einer druckseite
EP1074143A1 (de) Verfahren zur bilddatenkomprimierung für zwei-farben-bilder
DE19856574A1 (de) Verfahren zum Optimieren von Druckerfarbpaletten
EP1842361B1 (de) Verfahren, computerprogramm, computer und drucksystem zum trapping von bilddaten
DE2154902A1 (de) Verfahren und Vorrichtung zum Zusammenstellen einer farbigen Druckseite
EP2092465B1 (de) Verfahren und system zum automatischen aufbereiten von druckdaten für einen druckvorgang
DE19623327A1 (de) Verfahren zur Bearbeitung von Objekten auf Druckseiten
WO2008062041A1 (de) Verfahren und drucksystem zum trapping von druckdaten
EP1064618B1 (de) Verfahren zur koordinatenumrechnung von bilddaten mit zufälligem offset der bildpunkte
EP0766856B1 (de) Verfahren zur montage von druckbögen
DE10205546A1 (de) Verfahren zur Datenkomprimierung von Bildmaskendaten
DE10012521C2 (de) Verfahren zur Komprimierung von Druckdaten
DE4230193C2 (de) Punktraster-Bildaufzeichnungsverfahren
DE4402723A1 (de) Verfahren zur Erzeugung von Halbtonvorlagen
DE10305046B4 (de) Verfahren zur Erzeugung eines Rasterbitmap Proofs
DE10110158B4 (de) Verfahren zur Komprimierung von Druckdaten
EP1192799B1 (de) Verfahren, system und computerprogramm zum komprimieren und übertragen von bildrasterdaten
EP0703546A1 (de) Verfahren zur Aufschärfung von Bildkonturen von digitalisierten Bildern
EP1223743A2 (de) Verfahren zur rasteradaptiven Kopierretusche
DE10360388A1 (de) Verfahren zur Zusammenfassung von Druckdaten für einen Druckauftrag

Legal Events

Date Code Title Description
OM8 Search report available as to paragraph 43 lit. 1 sentence 1 patent law
8127 New person/name/address of the applicant

Owner name: HEIDELBERGER DRUCKMASCHINEN AG, 69115 HEIDELBERG,

8181 Inventor (new situation)

Free format text: SOEKER, WILFRIED HELMUT, 63674 ALTENSTADT, DE NEUMANN, YNGVE, 24147 KLAUSDORF, DE FUNKE, VOLKMAR, 24161 ALTENHOLZ, DE

8139 Disposal/non-payment of the annual fee