aus aktuellem Anlass möchte ich dieses Kuriosum potentiellen Tüftlern nicht vorenthalten. Ich finde in einem PDF gleich zwei OutputIntents, die sich aber widersprechen:
"ISOcoatedv2_300%"
und
"FOGRA 27..."
(siehe screenshot)
Der Preflight meldet mir keine Probleme bei Prüfung auf PDF/x-3 als OI dann zuerst: "FOGRA 27...",
die Ausgabevorschau in Acrobat entscheidet sich für "ISOcoatedv2_300%", das findet sich dann auch beim Ausklappen des OI-Pfeils im Preflight?
Ich bilde mir mitunter ein, mich einigermaßen ausreichend auszukennen bezüglich Farbmanagement für Datencheck im Printbereich, aber da haut´s mich wirklich um, das hatte ich noch nie - zumindest nicht bemerkt - und ich frage mich:
Bin ich nur zu blöd, weil ich so etwas jetzt erst zum ersten Mal beobachte oder ist das kreatives Farbmanagement auf bislang unübertroffenem Niveau?
(Rücksprache mit Datenersteller findet noch statt, ich habe auch schon - nach einem Vorgespräch - konkrete Vermutungen. Wahrscheinlich bin ich nicht mal unschuldig wegen Überbratung aus Übertreibung statt "Beratung über"...)
Beschnittenes pdf druckt falsch
Ich habe ein bestehendes pdf beschnitten und mit "Speichern unter..." neu abgesichert. Wenn ich es nun zur Litho schicke wird das pdf zwar korrekt angezeigt, aber im Ursprungszustand geprooft, also was ich vorher abgeschnitten hatte ist jetzt wieder zu sehen. Hatte dieses Problem schon häufiger, auch der Litho scheint dieses Phänomen nichts neues zu sein. Wer hat eine Lösung?
Acrobat Distiller 6.02, OSX 10.4.5, Distillersettings sind abwärtskompatibel zu Acrobat 4 ...
vorsicht, diese Aktionsliste ist sehr gefährlich. Warum? Sie löscht alle Objekte, welche vollständig außerhalb der MediaBox liegen. Was soll daran riskant sein? Die Tatsache, dass Sie alle Objekte löscht, also auch Masken/Beschneidungspfade. Es kann sein, dass ein Objekt, welches innerhalb der Seitenfläche liegt duch eine Maske beschnitten wird, welche wiederum komplett außerhalb des Seitenformats liegt. Dann ist das Objekt eigentlich unsichtbar. Wenn nun durch Ihre Aktionsliste die Maske entfernt wird (und nur diese, da das beschnitte Seitenobjekt ja nicht das "außerhalb"-Kriterium erfüllt) taucht dieses "unsichtbare" Seitenobjekt plötzlich auf.
Diese Problematik kann durch Einsatz eines zusätzlichen Selektions-Kriteriums "Wiedergabeobjekte auswählen" verhindert werden.
Dies stellt sicher, dass nur "malende" Seitenobjekte aber keine Masken für's Löschen selektiert werden. ...
Seite heute ist der Quark eigene CUPS-Filter als Download verfügbar. http://downloads.quark.com/...?fid=117&lang=de Wie die Lösung jetzt genau aussieht, kann ich nicht sagen - also Rückmeldungen erwünscht. ...
Sie sind ein Schatz. Das könnte die Lösung sein. Ein erster Test brachte keinen Fehler im Acrobat 9. Es muß tatsächlich ein PS-Font sein. Auf jeden Fall ein fettes Dankeschön. Ich werde das morgen in der Agentur mal auf anderen Rechnern testen, ob das mit echten jobs auch so funktioniert. Dann wäre ja alles in Butter und die ganze Aufregung umsonst. Dann wäre ja auch meine Intention mit der Investition in XPress 8 und der Nutzung des PDF-Exports erfüllt. Ich kann es noch gar nicht glauben. Hoffentlich klappt es so einfach. ...
letzte Woche bei einem Neukundenbesuch wurde ich auf ein Problem hingewiesen, das angeblich damit etwas zu tun hätte, daß verkleinert eingebaute Bilder in XPress oder InDesign zu kaputt gerechneter Ausgabe (Proof, Belichter, etc.) führen würde und erst das manuelle Prüfen aller platzierter Bilder und eine in Photoshop (!) parallel durchgeführte Skalierung und Einbauen mit 100% in der Layout-Software das Problem lösen würde.
Klang für mich komisch, ließ sich dann aber recht schnell eingrenzen.
Hausintern wurden dort mit Joboptions von pdfx-ready.ch PDFs erzeugt (Empfehlung irgendeines Trainers, der dort intern eine Schulung veranstaltet hatte):
Ich vermutete aufgrund der Beschreibung ein Problem mit Downsampling und nach Blick in die Joboptions traf mich dann auch fast der Schlag:
Die "PDFX-ready-coatedSheet_Dist7.joboptions" bspw. enthalten sowas hier:
Der Distiller ist hinsichtlich Downsample-Qualität ja eh schon nicht sonderlich berühmt. Aber daß allen Ernstes ein DownsampleThreshold von 1.33 vorgegeben und branchenweit empfohlen wird, ist schon arg. Immerhin wird damit ein Bild mit einer effektiven Auflösung von 401 dpi gnadenlos auf 300 dpi kaputtgerechnet (Aus 4 Pixeln 3 zu machen, kann nicht gut gehen!). Anhand dieser Einstellung war dann auch die Aussage bzgl. verkleinerter Platzierung im Layout-Programm klar. Bilder, deren eigentliche Auflösung bspw. 300 dpi betragen, überschreiten nach Skalierung auf bspw. 70% den kritischen Schwellwert von 400 (300 * 1,33) dpi und werden kaputtgerechnet.
Ich fand ja die Adobe-eigenen Standardvorgaben bzgl. DownsampleThreshold von 1.50000 schon immer reichlich gefährlich (weil alles unterhalb 2 nur zu Katastrophen führen kann, wenn Downsampling aktiviert wird) aber den Schwellwert dann auf 1.33 zu verringern und solche Joboptions allgemein zum Download anzubieten, ist dann wirklich ein starkes Stück.
Da mir nach Rücksprache mit einer der betreuenden Lithos (Vorstufe von einer der größten Druckereien in D) versichert wurde, daß das mit dem "skalierten Einbauen" von Bildern ein allgemeines Problem sei (sprich anscheinend branchenweit bzw. überall PDFs mit derlei hinsichtlich Downsamplung extrem gefährlichen Joboptions erzeugt werden), wollte ich jetzt mal hier nachfragen, weil ich nach wie vor kaum glauben kann, daß diese Problematik nicht allgemein bekannt ist?
Bei mir kommen jedenfalls grundsätzlich keine Joboptions zum Einsatz, bei denen der DownsampleTreshold nicht auf mindestens 2.0 gesetzt ist (dito mit dem ImageMemory-Parameter, der sich zwar nicht qualitativ aber teils recht drastisch von der Performance herr auswirkt).
Wie seht Ihr das so? Ach ja, und falls das in der Vergangenheit schon Thema gewesen sein sollte, bitte auf passende Threads hinweisen. Hab bei Vorrecherche per Google jedenfalls nichts Erhellendes finden können...
da möchte ich aber auch heftigst widersprechen. Die Erzeugung und der Versand von PDF-Dateien, die noch native Transparenz beinhalten würde zumindest in Produktions-Kontexten, in denen Dienstleister auch noch mal korrigierend in Kundendaten eingreifen müssen, eine enorme Erleichterung der Aufgabenstellung und Steigerung der der Produktionssicherheit mit sich bringen. Dokumente, die bereits einer Transparenzreduzierung unterzogen wurden, sind, wie wir alle wissen, nur noch eingeschränkt editierbar (Stichworte Kachelbildung, Vektor-nach-Bitmap-Wandlung, Schichten-Bildung, Text-nach-Outline-Wandlung, usw.). Ganz zu schweigen von der Vielzahl an kaputt-verflachten PDF-Dokumenten, die durch ungeeignete Reduzierungs-Einstellungen des PDF-Erzeugers entstanden und bei denen selbst der beste Dienstleister oftmals nichts mehr retten kann.
PDF-Dokumente mit nativer Transparenz, stellen dagegen eine optimale Ausgangsbasis für die notwendigen Bearbeitungsschritte dar und der Dienstleister kann vor allem selbst entscheiden, ob eine Verflachung notwendig ist und wenn ja, mit welchen Mitteln und Einstellungen und an welcher Stelle seine Workflows das zu bewerkstelligen ist.
Aus diesen Gründen bin ich auch der festen Überzeugung, dass der PDF/X-4 Standard derjenige ist, der in Zukunft die größten Chancen hat. Solange aber Quark nicht in der Lage ist ein "passendes" Produkt anzubieten, bleiben die Vorteile den Adobe-Anwendern vorbehalten. ...
beschriebene Problem, habe ich eben beschlossen, meinen Fix fürs Problem zu veröffentlichen (weil ich alle Hoffnung fahren gelassen habe, daß Quark da was Vernünftiges rausbringen wird -- siehe weiter unten)
* Drei klitzekleine CUPS-Backends installieren, die für Distiller 6, 7 und 8 zuständig sind (wenn die entsprechende Distiller-Version nicht auf dem Mac aktiv sind, bleibt das Backend inaktiv)
* Wenn ein "Distiller-Drucker" bereits eingerichtet ist, für diesen einen neuen gleichlautenden Drucker anlegen, der noch die Ergänzung "(Xpress 7.x Distiller-Fix") im Namen trägt. Es wird auch die selbe PPD genutzt wie für den korrespondierenden Distiller-Drucker
Das Ganze sieht dann anschl. bspw. so aus wie in beigefügtem Screenshot.
Was hat man anschließend? Die Möglichkeit, wieder direkt aus Xpress 7.x heraus "direkt in den Distiller" zu drucken, indem man die gefixten Varianten benutzt (Handhabung 1:1 wie beim originalen Adobe-PDF-Drucker: D.h. Joboptions im Druckdialog auswählen, dito Speicherort des PDF -- wenn hier was nicht klappt, dann ist eine falsche PPD ausgewählt worden).
Was geschieht dabei im Hintergrund? Xpress erzeugt wie gehabt eine temporäre Datei, schiebt die ins Drucksystem und mein Backend wird dann mit dem Pfad zu dieser Datei aufgerufen. Mein Backend verschiebt dann die temporäre Datei an eine sichere Stelle, ruft Adobes Backend auf und fertig.
Wer sollte das Ganze einsetzen? Eigentlich jeder, der direkt den Distiller aus Xpress heraus nutzen will (zu den Risiken und Nebenwirkungen des Ganzen hinsichtlich "PDF-Boxen" gibt es ja geteilte Meinungen) und nicht auf den "offiziellen Fix" seitens Quark warten will. Ich will das definitiv nicht mehr, denn abgesehen davon, daß der eh erst mit Xpress 7.3 funktionieren kann, so wie es Quark aktuell vorhat, bemüht sich Quarks Lösung redlich alle Nachteile der beiden in
skizzierten Ansätze zu vereinigen (also ab 7.3 wieder PS-Datei mit anderem MIME-Type spoolen und diesen dann von einem Mini-CUPS-Filter einlesen und an "standard out" Richtung Adobe Distiller duplizieren).
Warum Quark das Problem mit 7.3 nicht einfach aus der Welt schafft, wenn sie eh nur vorhaben, einen Fix anzubieten, der ab 7.3 funktioniert, will mir zwar nicht in den Kopf. Ist mir inzwischen aber auch egal, da ich dem Spielchen "Gratis-Consulting Richtung Quark" nicht mehr allzu viel abgewinnen kann.
Obige Lösung funktioniert jedenfalls mit jeder Xpress 7.x Version und ohne Performance-Einbußen wie die Quarksche. Dafür halt mit dem ästhetischen Makel, daß je installiertem "AdobePDF"-Drucker noch eine zusätzliche Queue im Druckdialog auftaucht (diese kann aber aus jeder Anwendung heraus und nicht nur Xpress genutzt werden)
Ich habe dein Testdokument erhalten und versucht ein PDF zu exportieren. Ich muss sagen, dass ich egal mit welchen Einstellungen, immer zum gleichen Fehler komme wie du. Aber dann habe ich die gleiche Datei mal mit InDesign CS3 exportiert und siehe da: da geht's. Ich tippe also in der Tat auf ein Bug der PDF-Library die dann in der Version 8.0 behoben wurde. Aber du hast ja den Workaround gefunden die 1/8-Gevierte in der Euro Monospace zu setzen ...
ich arbeite auf einem G5 2x2GhZ mit 4GB RAM mit Indesign 5.0. Wenn ich einen aus einem PDF exportierten Text platziere und automatischen Textfluss aktiviere stürzt Indesign ab. Ich habe alle Importoptionen durch. Es passiert bei aus Acrobat 8.1 exportierten RTF, TXT und Word-DOC (was ja anscheinend auch RTF ist). Geht das nur mir so und ich kann etwas an der Installation verbessern oder geht das in Richtung Bug? ...
Frage zur Bearbeitung eines PDFs mit Callas pdfCorrect
UCR und Schwarzaufbau wirken sich nur aus, wenn es DeviceRGB im PDF gibt. Sie definieren Parameter fuer die Umrechnung von RGB nach CMYK. In der Praxis macht das fast niemand mehr. Alle professionellen Tools und Systeme verwenden statt dessen ICC-basierte Umrechnungen (und bei DeviceRGB wird halt ein default-RGB-Profil eingestellt bzw. angenommen).
Da in einem PDF/X-1a oder einem PDF/X-3 mit CMYK-Zielprofil sowieso kein DeviceRGB vorkommen darf, spielen diese beiden Parameter sowieso keine Rolle. Sie sind letztlich Ueberbleibsel aus einer PostScript-Zeit vor der Einfuehrung CIE-basierten Farbmanagements.
ich habe ein geliefertes PDF vom Kunden. Es ist eine Magazinseite aus InDesign-CS1. Blöderweise als PDF 1.4 mit Transparenzen. Und die Seite wimmelt nur so von Transparenzen wie Schlagschatten, Überblendungen usw. Im Hintergrund ist ein großes A4-Bild platziert, welches eine Auflösung von nur 223 dpi hat.
Wenn ich bei dieser Seite in Acrobat 7 oder 8 die Transparenz reduziere dann passiert folgendes: Das großes A4-Bild wird entsprechend der darüberliegenden Elemente gekachelt. Bereiche, die nicht von transparenten Objekten betroffen sind, behalten ihre ursprüngliche Auflösung von 223 dpi. Bereiche, über denen transparente Objekte liegen, werden neu berechnet und das gekachelte Bildfragment hat dann eine Auflösung von 300 dpi. Leider ist die Neuberechnung ziemlich schlecht. Es sieht dann so aus, als wenn in Photoshop der schlechteste Bildberechnungsmodus ausgewählt wäre und es entstehen deutliche Sägezahneffekte. Die Seite ist nach der Transparenzreduzierung eigentlich nicht mehr zu gebrauchen, da die Verschlechterung des Bildes indiskutabel ist.
Als Anlage mal ein Ausschnitt vor und nach der Transparenzreduzierung. Der screenshot wurde in Acrobat 7 bei 800% Vergrößerung geschossen. Das ist sicherlich sehr stark vergrößert, aber man sieht es auch schon bei 200%.
Ich komme einfach nicht dahinter, wo diese 300 dpi Bildauflösung herkommen. Meine Einstellungen der Transparenzreduzierung: Pixelbilder-Vektoren: 100 Auflösung von Vektorgrafiken und Text: 1200 ppi Auflösung von Verlauf und Gitter: 175 ppi diese Werte kann ich beliebig verändern und auch die darunter stehenden, es ändert sich im Ergebnis nichts (außer natürlich wenn man alles zum Pixelbrei rechnen lässt). Auch wenn ich bei Verlauf und Gitter die 223 dpi einstelle, kommen trotzdem 300 dpi raus nach der Reduzierung.
Wie kann ich das beeinflussen? Gibt es evtl. sogar einen versteckten Trick auf eine bessere Bildneuberechnungsmethode umzuschalten (z.B. bikubisch) ?
das ist ein bekanntes Übel der Transparenzreduzierungs-Funktion in Adobe Acrobat 7 Professional. Alle verflachten Seitenobjekte bekommen das aktuelle CMYK Arbeitsfarbraum-Profil angehängt (das deutet übrigens datrauf hin, dass Sie Ihre Acrobat Farbmanagement-Grundeinstellungen mal korrigieren sollten). Vermeiden läßt sich das problem meines Wissens nicht nur nachträglich beheben. So z.B. mit Hilfe der Acrobat-eigenen "Farben konvertieren" Funktion, indem Sie dem Eintrag "Kalibriertes CMYK" die Funktion "Dekalibrieren" zuweisen und "Profil nicht einbetten" aktivieren. ...
