Hallo,
für die Druckausgabe (Formate bis A0)benötigen wir sauber separierte Postscriptdateien im CMYK-Modus. Wenn die Karte Rasterdaten (schwarzweiße topographische Grundkarte als 1 bit-tiff) und Vektordaten enthält gibt ArcView 8.x jedoch keine verwendbaren PS-Dateien aus. Das liegt vermutlich daran, dass die Vektordaten zwar im CMYK-Modus ausgegeben werden, die Rasterdaten im rgb-Modus.
Bei der Farbseparation erhält man die Rasterdaten als schwarze Blöcke.
Der direkte Export als pdf-Datei für die Druckvorstufe kommt auch nicht in Frage, da auch hier die Rasterdaten über rgb definiert sind und nicht als Reinschwarz. Im Druck bringt die Verwendung von rgb gerade für feine schwarze Konturen kein befriedigendes Ergebnis.
Wir haben uns damit geholfen, dass wir zunächst die Vektordaten farbsepariert haben, danach die Rasterdaten ohne weiteren Inhalt (Legende, Text etc.). Das Raster lässt sich dann als 5. Farbe über die Vektordaten drucken.
Nachteil: Es lässt sich nicht steuern, welche Layer über bzw. unter dem Raster liegen, man muss darauf achten, dass sich nicht inzwischen der Ausschnitt verschoben bzw. der Maßstab verstellt hat.
Gibt es für die Druckausgabe eine einfachere Lösung?
Beim Probieren sind wir noch auf einen ärgerlichen Bug gestoßen, der für zusätzliche Verwirrung sorgte.
Druckt man ein beliebiges schwarz-weißes Rasterbild mit dem ArcView PS-Treiber im Modus composdite ist das Ergebnis zunächst o.k. Wenn man alle Einstellungen beibehält, anschließend farbsepariert druckt und dann wieder im composite-Modus, so ist nicht nur die farbseparierte Datei flächenhaft Vollschwarz, sondern auch die als drittes gedruckte Datei.
für die Druckausgabe (Formate bis A0)benötigen wir sauber separierte Postscriptdateien im CMYK-Modus. Wenn die Karte Rasterdaten (schwarzweiße topographische Grundkarte als 1 bit-tiff) und Vektordaten enthält gibt ArcView 8.x jedoch keine verwendbaren PS-Dateien aus. Das liegt vermutlich daran, dass die Vektordaten zwar im CMYK-Modus ausgegeben werden, die Rasterdaten im rgb-Modus.
Bei der Farbseparation erhält man die Rasterdaten als schwarze Blöcke.
Der direkte Export als pdf-Datei für die Druckvorstufe kommt auch nicht in Frage, da auch hier die Rasterdaten über rgb definiert sind und nicht als Reinschwarz. Im Druck bringt die Verwendung von rgb gerade für feine schwarze Konturen kein befriedigendes Ergebnis.
Wir haben uns damit geholfen, dass wir zunächst die Vektordaten farbsepariert haben, danach die Rasterdaten ohne weiteren Inhalt (Legende, Text etc.). Das Raster lässt sich dann als 5. Farbe über die Vektordaten drucken.
Nachteil: Es lässt sich nicht steuern, welche Layer über bzw. unter dem Raster liegen, man muss darauf achten, dass sich nicht inzwischen der Ausschnitt verschoben bzw. der Maßstab verstellt hat.
Gibt es für die Druckausgabe eine einfachere Lösung?
Beim Probieren sind wir noch auf einen ärgerlichen Bug gestoßen, der für zusätzliche Verwirrung sorgte.
Druckt man ein beliebiges schwarz-weißes Rasterbild mit dem ArcView PS-Treiber im Modus composdite ist das Ergebnis zunächst o.k. Wenn man alle Einstellungen beibehält, anschließend farbsepariert druckt und dann wieder im composite-Modus, so ist nicht nur die farbseparierte Datei flächenhaft Vollschwarz, sondern auch die als drittes gedruckte Datei.
- Anmelden oder Registieren, um Kommentare verfassen zu können
Gespeichert von Klaus ANUVA am Fr., 12.12.2003 - 13:29
Permalinkmit diesem Thema haben wir auch schon viele Probleme gehabt und auch einen langen Briefwechsel mit Esri hinter uns. Das Problem ist leider, dass ArcGIS eine sehr schlechte PS-Maschine besitzt. Eine saubere Farbseparation in CMYk ist nicht möglich - nicht nur bei Kombination Raster/Vektor leider auch bei reinen Vektordaten, wenn sich z.B. verschiedenfarbige Flächendefinetionen überlagern. Dann sind einige Objekte in RGB und andere in CMYK. Man kann nun den PS-file z.B. in Adobe Illustrator einladen und alle Objekte einheitlich in CMYK konvertieren. Dann hat man aber als Ergebnis z.T. leicht andere als die gewählten Farben. V.a. ist schwarz dann nicht 0,0,0,100 sondern 100,100,100,0 oder etwas ähnlches, jedenfalls nichts sauberes.
Leider sind das noch nicht dieeinzigen Problemchen der PS-files, die ArcGis produziert. Im Detail finden sich in den PS-files noch eine Reihe weiterer ungewöhnlicher Definetionen, die teilw. Proleme bereiten können. Hier ein Bericht eines Kollegen:
"Nehmen Sie doch mal eine ArcMap-erzeugte PostScript-
Ausgabe, öffnen Sie diese mit GhostScript 8 bzw. GhostView 4 und schauen Sie
sich die PostScript- Fehlermeldungen an (es genügt, die schwerwiegenden
Fehler anzuzeigen, die sonstigen Warnungen würden Bücher füllen), drucken
Sie das Ergebnis in eine Datei und schicken diese nach Kranzberg. Dies zeigt
für mich, das ArcMap-PostScript-Ausgaben - auch jenseits der
Adobe-Spezifikationen -außerhalb jeglicher gängiger PostScript-Standards
liegen.
Offensichtlich ist es ESRI - nachdem am PostScript-Treiber unter ArcInfo 15
Jahre lang nichts geändert worden war - auch weiterhin völlig egal, ob und
wie man aus Ihren Produkten in die High-End Bildverarbeitung kommt. Und die
ON-Board-Mittel z.B. zur Rasterbilderzeugung sind - gelinde gesagt - ein
Witz (Screenshots liefern noch das bessere Ergebnis! ...
Übrigens ist die Situation (jenseits der Farbraum-Problematik) auch beim
Umgang mit Schriften nicht besser (fehlerhafte Einbettung von Type 1-
Schriften, Fehlerhafte Vorgaben zur Schriftsubstitution, fehlerhafte
Vorgaben für Type 3 (Bitmap-) Schriften."
Leider ist es auch fast egal mit welchem Postscripttreiber man arbeitet. Das Hauptproblem erzeugt ArcGIS selbst. Am besten sind noch die Ergebnisse mit dem neuesten generic PS-Treiber von ADOBE. Welche Seitenbeeschreibungsdatei man nimmt, ist dabei meiner Ansicht nach weniger von Bedeutung (doch hier gibbt es unterschiedliche Meinungen).
Gruß,
Klaus