Hallo,

das in Acrobat die o.g. Korrektur nur beim Droplet funktioniert ist mir bekannt. Erstaunt bin ich aber, dass auch in der Callas Toolbox 4 nach Abschluß des Preflights der Dateiname des PDFs nicht erweitert wurde. Ein Droplet der Toolbox ist mir nicht bekannt. Wie kann ich also den PDF-Dateinamen dahingehend erweitern, dass ein Dritter weiß, was gemacht wurde? Oder geht das nur mit Toolbox-Server?

Gruß

Das geht nur bei Batch/Droplet/Serververarbeitung.

Grund: z.B. unter Windows kann man einen Dateinamen nur ändern, wenn das Dokument nicht grad irgendwo geöffnet ist. Sprich: ist das Dokument interaktiv geöffnet in Acrobat oder pdfToolbox oder... - lässt sich der Name nicht ändern.

Olaf

Hallo,

diese Erklärung kann aber nur die halbe Wahrheit sein. Natürlich kann man als Sofwarehersteller das OS nicht überlisten, aber man könnte es ja auch intelligent lösen. Denn die Software fordert mich als Anwender doch sowieso auf, das PDF unter einem anderen Namen zu speichern (sozusagen als speichern unter). Wenn ich Programmierer wäre, dann würde ich da den Appendix schon in den Dateinamen einfügen. Denn der ist ja definiert im Preflight-Profil und somit bekannt.

Gruß

Hallo,

hatte sowas nicht auch bei den alten Preflight-Profilen von Acrobat 7 bei der Konvertierung zu PDF/X geklappt?

Okay, da hatten keine Ergebnisse angezeigt werden müssen, aber man könnte ja automatisch die Datei erst umbenannt Speichern, dann Öffnen und dann die restlichen Profile drüberjagen.

soviel von mir

Zitat

Das geht nur bei Batch/Droplet/Serververarbeitung.

hm, funktioniert bei mir im aktuellen Server 5.0.134 aber auch nicht
wird auch nicht im log-file als Aktion aufgeführt
Das PDF im Erfolgsordner hat den identischen Namen wie das Eingangs-PDF.

Was mache ich hier falsch? Das Preflight-Profil habe ich im Acrobat-PlugIn definiert und dann im Server einer neuen Warteschlange zugeordnet. Ist ja prinzipiell nicht so schwer und auch kein Hexenwerk.

Gruß

Hallo rohrfrei,

in dem Kommentar, der beim Auswählen des Fixups angezeigt wird, steht: "... Dieses Fixup wird nur bei Verwendung im Stapelverarbeitungs-Modus oder Droplet angewandt." Leider wird es also im Server oder in der CLI (Kommadozeile) nicht berücksichtigt. Wäre das ein wichtiger Feature-Wunsch? Wenn ja: Für Server oder Switch? (Wir werden uns die Funktionalität ohnehin ansehen müssen, da es Droplets in der pdfToolbox ja gar nicht gibt, das haben wir nur für das Preflight Werkzeug in Acrobat gebaut.)

Grüße,

Hallo Herr von Seggern,

das mit dem fehlenden Droplet der Toolbox hatte ich ja in der Ausgangsfrage erwähnt. Und Herr Drümmer hat in seiner Antwort den Server mit aufgezählt, daher meine Nachfrage. Ich muss gestehen, dass ich das bisher auch nie verwendet habe, da ich die Prüfprofile ja bisher auch nur standalone unter Sichtkontrolle in Acrobat und/oder Toolbox angewendet habe.

Da ich nun aber vor der Investitionsentscheidung einer Serveranwendung stehe, würde ich die Unterstützung dieser Funktion im Toolbox-Server schon begrüßen, da es bei den verarbeiteten Daten sicherlich für mehr Transparenz sorgen würde.

Gegenwärtig plane ich ohne Switch, würde also zuerst eine Lösung im Server direkt favorisieren. Eine späterer Nachkauf ist aber denkbar und möglich ob der vielfältigeren Automatisierungslösungen, die Switch bietet.

Gruß

Hallo rohrfrei,

dann habe ich auch diesmal noch Rückfragen: Wie wäre denn das gewünschte Verhalten: Im Droplet etc. wäre es so, dass die verarbeitete Datei IMMER ein Suffix erhält. Der Grund ist eigentlich, dass man die verarbeiteten Dateien dadurch nicht zwingend in einem anderen Ordner speichern muß, sondern die Resultate direkt neben die Originale legen kann. Daher würde eine Datei auch dann ein Suffix erhalten, wenn sonst gar keine Änderungen an dem PDF vorgenommen worden wären (weil z.B. bei einem Fonteinbettungs-Profil schon alle Schriften in dem PDF vorhanden waren). Bei Ihnen höre ich heraus, dass das so wohl nicht erwartet wäre, oder doch? Weiterhin wäre es so, dass ein PDF auch dann das Suffix erhalten würde, wenn bei einer in dem Profil vorhandenen Prüfung Fehler gefunden würden, so dass das PDF in den Fehler Ordner gelangen würde. Wie wäre denn hier das von Ihnen erwartete Verhalten?

Danke und Grüße,

Zitat

Daher würde eine Datei auch dann ein Suffix erhalten, wenn sonst gar keine Änderungen an dem PDF vorgenommen worden wären (weil z.B. bei einem Fonteinbettungs-Profil schon alle Schriften in dem PDF vorhanden waren). Bei Ihnen höre ich heraus, dass das so wohl nicht erwartet wäre, oder doch?

eigentlich doch, denn wenn ich mich bewußt dafür entscheide, diese Korrektur im Preflight-Profil zu hinterlegen, dann möchte ich auch, dass es entsprechend ausgeführt wird. Auch wenn sonst alle Prüfungen ohne Fehler abgearbeitet wurden und/oder sonst keine anderen Korrekturen ausgeführt wurden. Ich möchte mit dem Suffix einem Kollegen signalisieren, dass das angelieferte Kunden-PDF bereits gepreflightet wurde. Also eigentlich egal, was dabei im Preflight passiert, auf jeden Fall wurde das PDF entsprechend geprüft.

Wenn ich das Suffix nicht haben will, dann baue ich es nicht in mein Preflight-Profil ein, ganz einfach. Oder man macht es dynamisch wie im heutigen Newsletter behandelt. Aber auch das kann dann derjenige entscheiden, der das Preflight-Profil definiert. Von Callas als Hersteller sollte, das "nur" entsprechend funktionsfähig implementiert werden, die Verwendung bestimmt der Anwender selbst.

Zitat

Weiterhin wäre es so, dass ein PDF auch dann das Suffix erhalten würde, wenn bei einer in dem Profil vorhandenen Prüfung Fehler gefunden würden, so dass das PDF in den Fehler Ordner gelangen würde. Wie wäre denn hier das von Ihnen erwartete Verhalten?

ja, hier muss man zunächst mal wieder zwischen Info, Warnung und Fehler unterscheiden. Also bei Info und Warnung sollte das Suffix meiner Meinung nach auf jeden Fall angefügt werden, da es sich hierbei ja nicht um einen Fehler handelt (siehe andere Diskussion hier. Da sind sich ja wohl alle einig mittlerweile) und die Datei gemäß des Preflight-Profils ja scheinbar grundsätzlich OK ist.

Bei einem Fehler würde ich persönlich gemäß der o.g. Argumentation auch ruhig das Suffix anwenden, damit man auf jeden Fall sieht, was da mit der Datei passiert ist. Die Einsortierung in den Fehlerordner ist dann eine zusätzliche Hilfe.

Gruß

Wenn an der Suffix-Funktion schon gearbeitet wird...
... dann kann ich doch gleich noch optional Einstellen, dass im Fehler-Fall das eine Suffix, bei Warnungen wieder ein anderes und wenn alles OK ist die dritte Variante des Suffix angehangen wird.

Zusätzlich wären natürlich noch Möglichkeiten denkbar, das unterschiedliche Suffixe möglich sind, je nach "Andere Korrekturen durchgeführt" oder "Keine weiteren Korrekturen durchgeführt"

Viele Grüße