Hallo,

ich habe immer wieder das Problem, daß mir der Acrobat Preflight Fehler/Warnungen meldet, die im gedruckten Produkt nicht zum Tragen kommen. Meistens passiert das, wenn in einem Magazin Anzeigen platziert sind. Ich versuche mal, daß zu beschreiben.

Also wenn eine Anzeige als PDF vorliegt mit Schneidezeichen und Auszugsbeschriftung. Diese dann im Layoutprogramm platziert wird, dann wird ja i.d.R. der Bildrahmen für das PDF auf die Trimbox der Anzeige beschnitten, so daß die Schneidezeichen im Magazin-Layout nicht mehr zu sehen sind. Wenn man nun aus dem Magazin-Layout ein PDF erzeugt und einen Preflight drüber laufen lässt, dann kommt z.B. immer eine Meldung, daß die Paßkreuzfarbe "All" innerhalb der Trimbox ist. Stimmt natürlich, da ja die Schneidezeichen der Anzeige im Layout drin sind, allerdings abmaskiert und damit unsichtbar. Spielt für den Druck also keine Rolle.

Wie erstelle ich eine Prüfregel, die diesen Umstand berücksichtigt? Also nur das prüft, was tatsächlich sichtbar ist.

Gruß

Hallo rohrfrei,

kann ich bitte mal dieses PDF bekommen. Würde das gerne mit einem angepassten Prüfprofil testen.

Wie Peter Kleinheider geschrieben hat, wäre eine Beispieldatei interessant. Theoretisch wäre es möglich z.B. über Metadaten alle platzierten Anzeige zu kennzeichnen und diese dann von der Prüfung auszuschließen. Das würde natürlich von dem konkreten Workflow abhängen und voraussetzen, dass diese Metadaten 1. eingefügt werden und 2. in dem finalen auch noch "ankommen".

Gruß,

Herr Kleinheider hat Daten von mir bekommen. Kann Ihnen aber gerne einen ganzen Sack zur Verfügung stellen.

Metadaten funktioniert nicht. Es muss geprüft werden, ob was sichtbar ist, oder nicht. Keine Ahnung wie das im PDF sortiert ist. Entweder innerhalb einer Maske oder innerhalb eine Beschneidungspfades?

Gruß

Hallo

Antwort auf [ Dietrich von Seggern ]

Wie Peter Kleinheider geschrieben hat, wäre eine Beispieldatei interessant.

Ich schicke dann gleich mal eine Datei an Ihre Mail-Adresse.
Das nervt mich nämlich auch seit gefühlter Ewigkeit.
Unsere Kunden bekommen eine Meldung, dass die Registerfarbe innerhalb der TrimBox ist und sehen das nicht und könnens nicht nachvollziehen.
Über die Umrißdarstellung von PitStop ist es dann wunderschön erkennbar, dass dies die Marken aus einem platzieren PDF sind. Doch man sieht es mit Bordmitteln nicht.
In pdfToolBox und Acrobat.

Das Thema haben wir uns bei callas schon mehrfach angesehen, es ist aber ein einigermaßen diffiziles Thema, weil an sich vorhandene Objekte auf unterschiedlichste Weise 'unsichtbar' sein können:
- durch Beschneidungspfad (clipping path)
- durch Maske
- durch Transparenzeffekte (z.B. "Aufhellen" mit Registerfarbe)
- durch Überlagerung eines aussparenden Objektes
- durch Farbübereinstimmung mit dem Hintergrund
- durch Angrenzen an gleichfarbiges Objekt
Weiterhin verkomplizierend kommt hinzu, dass o.g. Punkte auf Teile eines Objektes zutreffen können, dass es Genauigkeits-Grenzfälle gibt (gibt es eine Überlappung zwischen einer Tangente und einer Kurve?), und dass o.g. Aspekte kombiniert sein können. Wenn ich noch ein bisschen nachdenke, kommen bestimmt noch ein paar Komplikationen hinzu (z.B. Pattern, Type 3 Fonts, ...). Ich will aber jetzt eigentlich nicht jammern....

... sondern mich und Euch fragen: welche Teilmenge an Praxisproblemen ist wirklich wichtig? Aus den bisherigen Beiträgen entnehme ich, dass u.a. folgende Punkte oft Ärger machen, weil sie 'vorhanden' aber 'unsichtbar' sind:
- Schnitt- und Passermarken, Problem: Registerfarbe innerhalb TrimBox,
- dto., Problem: zu geringe Strichdicke
- ...

Was gibt es für weitere häufigere Vorkommnisse von blindem Alarm wg. an sich unerwünschter Objekte, die aber - da unsichtbar - gar nicht zum Tragen kommen?

Olaf

Hallo Olaf,

hier meine Favoritenliste (Reihenfolge ist wertungsunabhängig, dafür sehr kurz)

1. Berücksichtigung komplett abgedeckter Objekte (das beschriebene Beispiel mit Schneidmarken) - also ausschließen bei Prüfung
2. abgedeckte Textfragmente, die bei Transparenzreduzierung entstehen - im Prinzip das gleiche wie Fall 1

und - nicht unsichtbar, aber trotzdem nervig

3. Überdrucken Prüfung soll keinen Hit erzeugen, wenn das Objekt kein anderes Objekt überlagert

Hallo Herr Drümmer,

Zitat

Was gibt es für weitere häufigere Vorkommnisse von blindem Alarm wg. an sich unerwünschter Objekte, die aber - da unsichtbar - gar nicht zum Tragen kommen?

bin gerade über noch so einen Punkt gestolpert, der bei den Preflights immer Fehlalarme verursacht. Leerzeichen als Leerzeile!
Besonders beliebt aus Office-Applikationen um ein bisschen Platz zwischen den Texten zu bekommen, einfach ein, zwei oder drei mal Enter. Im PDF erscheinen dann Fehlermeldungen, wenn die Schrift (das Leerzeichen) zu klein ist.
Vielleicht könnte man das noch mit Abfragen.

Wenn gewünscht kann ich da auch zu Ihnen oder Hr. von Seggern ein Beispiel-PDF schicken.

Hallo,

ich kann das gar nicht so genau festmachen. Sicherlich ist das Beispiel mit der platzierten Anzeige und der Passkreuzfarbe "All" ein echter Klassiker, aber es gibt auch noch haufenweise andere Fundstellen, z.B. zu dünne Linien. Letztlich ist das ja direkt vom Prüfprofil abhängig.

Ich kann das ja jetzt nicht programmieren, aber mal einen Denkanstoß geben. Beim iPad-Magazin-Publishing habe ich aufgeschnappt, dass man Seitenelemente mit ihrer Seitenposition in einer Datenbank abspeichern kann. Um festzustellen, ob ein Objekt sichtbar oder unsichtbar ist, muss die Seite im Prinzip fertig "gerendert" bzw. "gerastert" werden, z.B. in der Ausgabevorschau. Alles andere scheint wohl tatsächlich zu komplex zu sein. Wenn man jetzt die Darstellung der Ausgabevorschau mit den abgespeicherten Objekten in der Datenbank vergleicht, dann könnte man evtl. einen Quervergleich herstellen. Und wenn ich mich recht erinnere, dann war doch im Toolbox-5-Webinar die Rede davon, dass für den Dokumentvergleich eine Seite bereits jetzt gerastert werden kann. Evtl. kommt man über die Verknüpfung dieser beiden Technologien zu einem Ergebnis. Wobei ich mir die Performanceprobleme noch gar nicht ausmalen mag.

Gruß

Guten Morgen

Zitat von rohrfrei

Evtl. kommt man über die Verknüpfung dieser beiden Technologien zu einem Ergebnis.

Genau das war auch mein Gedanke.

Antwort auf [ rohrfrei ]

Wobei ich mir die Performanceprobleme noch gar nicht ausmalen mag.

Wenn Du Dir aber den Server der ToolBox kaufst, dann wäre es doch eigentlich auch egal, ob er 10 Sekunden braucht oder eine ganze Minute. Du sitzt ja normalerweise nicht davor und wartest.
Und für die Desktop-Variante könnte man ja eine Voreinstellung einbauen:
[ ] Gute und schnelle Überprüfung
[x] Gründliche und langsamere Überprüfung

Hallo rohrfrei,

bis auf die Linien funktioniert das doch jetzt schon in der pdfToolbox und in PitStop Pro 10!

Die Prüfungregel in der Toolbox lautet "effektiver Gesamtfarbauftrag", in PitStop findet sich die Prüfung im Profil-Editor - Prozessfarbe - vollständige Überprüfung.

Da beide Programme die PDF-Datei rendern, werden so auch nur die Objekte bei der Überprüfung berücksichtigt, die sichtbar sind.

Gruß,
Karsten

Hallo Karsten,

genau an die Prüfung "effektiver Gesamtfarbauftrag" aus der Toolbox habe ich gedacht, als ich weiter oben das mit der Performance geschrieben habe. Ich denke, du weißt, was ich meine ;-)

Gruß

Hallo Polylux,

Antwort auf [ Polylux ]

bin gerade über noch so einen Punkt gestolpert, der bei den Preflights immer Fehlalarme verursacht. Leerzeichen als Leerzeile!
Besonders beliebt aus Office-Applikationen um ein bisschen Platz zwischen den Texten zu bekommen, einfach ein, zwei oder drei mal Enter. Im PDF erscheinen dann Fehlermeldungen, wenn die Schrift (das Leerzeichen) zu klein ist.
Vielleicht könnte man das noch mit Abfragen.

Wenn gewünscht kann ich da auch zu Ihnen oder Hr. von Seggern ein Beispiel-PDF schicken.

Beispieldatei wäre sehr erwünscht. Solche "falschen Fehler" müsste man bereits aussortieren können, wenn die Prüfung auf zu kleine Schrift mit der Prüfung "Zeichen referenziert Glyph mit Kontur | trifft zu" kombiniert wird. Dann werden nur Texte gefunden, die auch tatsächlich etwas zeichnen.

Gruß,

Hallo Herr von Seggern,

Antwort auf [ Dietrich von Seggern ]

Beispieldatei wäre sehr erwünscht. Solche "falschen Fehler" müsste man bereits aussortieren können, wenn die Prüfung auf zu kleine Schrift mit der Prüfung "Zeichen referenziert Glyph mit Kontur | trifft zu" kombiniert wird. Dann werden nur Texte gefunden, die auch tatsächlich etwas zeichnen.

Datei liegt in Ihrem Postfach.
Bei der Prüfung mit den Glyphen haben Sie Recht, könnte funktionieren. Doch nachdem ich mit diesen ganzen "notDef Glyph" blöde Erfahrungen gemacht habe, und nun auch bei unserem Heidelberg-Workflow da nur Ärger mit sinnlosen Glyphen-Meldungen gibt, bin ich da immer skeptisch, was Fehler oder Warnungen mit Glyphen betrifft.
Ich vertraue da den Meldungen nciht mehr...

Hallo,

das mit der zusätzlichen Prüfung, ob ein Text auch wirklich "zeichnende Buchstaben" verwendet sollte funktionieren, habe Ihnen eben das Prüfprofil geschickt.

Ich nehme an, Sie meinen das Problem eines direkt referenzierten .notdef Zeichens. Das ist eine andere Baustelle. Das Problem tritt glaube ich häufiger mit InDesign CS 3 generierten PDFs auf. Es ist eigentlich eine Unsauberkeit bei der Fonteinbettung in ein PDF, die aber wohl in der Praxis nur selten zu echten Problemen führt und daher in vielen Fällen als "falscher Fehler" eingestuft wird. Allerdings ist diese "Konstruktion" in PDF/X-4 ausdrücklich verboten, so dass die Fehlermeldung bei einer PDF/X-4 Prüfung immer kommen wird. Das ist aber wohl eigentlich ein anderes Thema und sollte bei Bedarf auch woanders weiter diskutiert werden.

Viele Grüße,