Hallo,
ich habe ein mir unerklärliches Problem mit dem automatischen Konvertieren einer bereits existierenden PDF-Datei, bei dessen Lösung ich auf Ihre Hilfe oder neuen Input hoffe:
Vorhanden ist ein durch ein Drittanbieter (nicht Acrobat Reader) digital signiertes PDF, welches nach dem Signieren erneut Konvertiert werden muss (Hintergrund: Die Unterschrift soll nur als Bild vorhanden sein und nicht als Signaturobjekt. Außerdem sollen alle Formfelder in Text “umgewandelt” werden - sprich nicht mehr editierbar…)
Sowohl bei Verwendung der COM-Schnittstelle der PDFCreator Version 1.7 als auch einer neueren 3.x habe ich unter Verwendung des Late-Binding (.NET-Code) auf Windows10 das Problem, dass manche Formfelder einfach die Position verändern und damit andere PDF Inhalte verdecken, als auch dass leere Formfelder eigentlich dahinterliegende Tabellenlinien übermalen. Bei Formfeldern mit Text passiert dies wohlgemerkt nicht.
Interessanterweise tritt dieses Problem auch nicht auf, wenn ich das signierte Dokument im Acrobat Reader DC öffne und dort manuell einen Druckvorgang mit dem PDFCreator als zu verwendenden Drucker starte.
Im PDFCreator ist lediglich ein Standardprofil hinterlegt. Dieses wird jedoch nicht explizit im .NET-Code angewählt (gehe davon aus, dass die Schnittstelle das automatisch macht?)
Kann es sich hier um ein Problem mit den Druckertreibern in Windows 10 handeln? Habe ich bei der Verwendung der COM-Schnittstelle etwas vergessen?
Besten Dank,
Ima.NetDev
Hallo,
spontan kann ich mir das Verhalten leider auch nicht erklären; vermutlich wird die Datei unter Verwendung der COM-Schnittstelle aus einer anderen Anwendung heraus gedruckt, kann das sein? Tritt das Problem auch auf, wenn Du die Datei mit PDFCreator.exe /PdfFile=“Dateiname.pdf” konvertierst?
In dem Fall wird die Datei gar nicht gedruckt, sondern direkt überarbeitet, was oftmals bessere Ergebnisse liefert.
Beste Grüße
Robin
Hallo Robin,
die Datei wird tatsächlich aus einer anderen Anwendung heraus “gedruckt”. Bei Verwendung des von Dir beschriebenen Befehls öffnet sich bei mir das (manuelle) PdfCreator-Konvertierungsfenster… hier wird die Datei aber 1a überarbeitet und sieht anschließend genau so aus, wie ich das haben möchte.
Der manuelle Schritt ist an dieser Stelle allerdings ein Nogo für meine Anwendung, weshalb ich ja die COM-Schhnittstelle ausprobiert hatte…
Gibt es eine Möglichkeit diese Überarbeitung automatisch durchführen zu lassen?
Beste Grüße,
Ima.NetDev
Kurze Änderung zu meinem vorherigen Eintrag: Ich habe das Standardprofil jetzt so eingestellt, dass es die Konvertierung automatisch durchführt und die konvertierte Datei im gleichen Verzeichnis ablegt…
Starte ich die Konvertierung jetzt über den Befehl PDFCreator.exe /PdfFile=“Dateiname.pdf” führt dies ebenfalls zu meiner initial beschriebenen Problematik!
Hallo Ima.NetDev,
das ist sehr seltsam, da PDFCreator.exe /PdfFile=“Dateiname.pdf” die Datei in jedem Fall direkt konvertieren sollte, während bei der Konvertierung über die COM-Schnittstelle diese in jedem Fall gedruckt wird.
Hast Du noch zusätzliche Einstellungen im Standardprofil geändert / hattest Du bei der manuellen Konvertierung ggf. ein anderes Profil verwendet?
Beste Grüße
Robin
Hallo Robin,
ich finde das auch seltsam. Nach einer Neuinstallation der aktuellen Version werden zwar die Linien korrekt gedruckt, aber dafür verschwinden jetzt die Inhalte bzw. komplette Formfelder sowohl beim Konvertierungsprozess über die Kommandozeile als auch über die Verwendung der COM-Schnittstelle.
Ich habe nach der Neuinstallation keine Änderung an irgendwelchen Einstellungen vorgenommen und bei mir ist auch nur das Standardprofil verfügbar (keine anderen Guids mitinstalliert). Könnten hier irgendwelche Einstellungsleichen in der Registry seitens Version 1.7 zurückbleiben, die jetzt komische Konvertierungen hervorrufen?
Gibt es eine Möglichkeit den Konvertrierungsprozess zu tracen oder zu loggen, um hier weitere Infos zu erhalten?
Beste Grüße
Hallo nochmal,
ich habe die Logging-Funktion mit etwas Recherche hier im Forum gefunden und das Logging-Level auf Debug gesetzt... Ich erhalte tatsächlich etliche GS-Errors, die ich hier mal auszugsweise angehängt habe.
Das Programm welches ursprünglich das zu konvertierende PDF erzeugte hat einige transparente Hintergründe für die entsprechenden Formfelder gesetzt. Ich habe hier im Forum auch schon gelesen, dass GS damit ein echtes Problem hat.
Sind transparente Felder nicht PDF-Standard-konform? Diese Meldung erhalte ich nämlich am Ende des PDFCreator.logs von der GS-Komponente.
Besten Dank,
Ima.NetDev
Hi,
für PDFs ist Transparenz an sich kein Problem, aber da Ghostscript in erster Linie ein Postscript-Interpreter ist und Postscript keine Transparenz unterstützt (da man diese ja nicht richtig drucken kann), treten hier Probleme auf.
Die Frage ist, warum das Problem nicht auftritt, wenn Du den Speicherort manuell auswählst; der Workflow und der Ghostscript Aufruf sollten abgesehen von der Angabe des Speicherorts identisch sein.
Könntest Du von beiden Vorgängen jeweils ein “Trace” Log erstellen und an support(at)pdfforge.org schicken? Dann sehen wir uns das Problem gerne im Detail an.
Beste Grüße
Robin
