Open-Source PythonLib zum PDF für Druckvorstufe erstellen

[ferix]

Ganz kurze Frage:
Gibt es eine kostenfreie Python-Bibliothek mit der es möglich ist PDF's für die Druckvorstufe zu erstellen!?

[jerch]

Kurze Antwort: Ja - http://www.reportlab.org/

[ferix]

Danke. Auf der Seite war ich schon, aber ich finde nirgends Angaben, ob man PDF's für die Druckvorstufe erstellen kann wie PDF/X3:2002!?!?

[jerch]

Die PDF/X-Spezifikation unterstützt reportlab mMn nicht explizit. Die meisten Festlegungen sind aber nutzbar (Schriften einbetten, CMYK-Bilder etc.). Probleme dürftest Du wohl mit dem "Output Intent" bekommen.

[ferix]

Wenn die PDF/X-Spezifikation nicht unterstützt werden bringt es mir doch garnichts oder? Die meisten Druckereien wollen doch nach diesen Spezifikationen angelieferte PDFs.

Was ist "Output Intent"?

[problembär]

Die meisten Druckereien wollen doch nach diesen Spezifikationen angelieferte PDFs.

Warum willst Du denn einer Druckerei ein PDF übergeben, das automatisch von/mit einem Python-Skript erzeugt wurde?

Gruß

[ferix]

Es muss nicht zwingend mit Python sein, PHP wäre sicher auch möglich.
Ich biete die Gestaltung von Printmedien an und erstelle die PDFs normal aus InDEsign heraus.
Allerdings würden einige Kunden gerne die Variationen der z.B. Visitenkarten selbst erstellen.
Hier würde sich dann eine Web2Print-Lösung anbieten, bei der die Blanko-Visitenkarte eingebunden ist und der Kunde sich seine druckfähige personalisierte Visitenkarte erstellen kann.

Leider bin ich auf der Suche noch auf kein kostengünstiges System gestoßen.
Auch auf der Suche nach Bibliotheken bin ich bisher nur auf PDFlib gestoßen, was das Erstellen druckfähiger PDFs definitiv unterstützt.
Allerdings ist diese Bibliothek eben nicht ganz billig.

[Leonidas]

Du könntest auch InDesign in Python skripten, da es zumindest unter Windows eine COM-Schnittstelle hat und PDF/X unterstützt. Das das mit Python funktioniert, steht sogar in CS3-Skripting-Tutorial.

[ferix]

Dass es eine InDesign Skriptsprache gibt war mir bis eben neu, aber hab das Tutorial eben gesehen. Nur erzeuge ich doch dann ein InDesign-Dokument und noch kein PDF!?!? Hmmm ich sehe schön das wird wohl ne größere Sache ^^

[Leonidas]

InDesign kann PDF-Export, das sollte doch auch über das Scripting-Interface ebenfalls ansprechbar sein.

[jerch]

"OutputIntent" und "RenderIntent" sind Formatierungsanweisungen in PDF/X, die aus dem portable ein unportable machen. Damit kannst Du gezielt die Ausgabe festlegen (ICC-Profile, Drucktechnik, Rasterung etc.), was eigentlich nicht im Sinne des Erfinders von PDF ist, da die gewünschte Plattformunabhängigkeit negiert wird. Das geht dann soweit, das Druckereien, die ein PDF/X-Dokument mit ihrerseits nicht unterstützten OutputIntent-Angaben bekommen, das nicht drucken können, d.h. es ist wichtig, die Vorgaben der Druckerei zu beachten (was ja sowieso der Fall ist).

Der von Leonidas vorgeschlagene Weg, die Sache via InDesign zu skripten, klingt für Deine Anforderungen am vielversprechendsten. Dummerweise zieht das halt einen ziemlichen Ball an weiteren Voraussetzungen nach sich, Windows-Server, Nebenläufigkeit von InDesign?, COM-Scripting, Sicherheitsaspekte etc.
Andererseits kostet PDFlib in der Grundversion 800€ und bietet sicherlich eine nette API. (InDesign ist ja auch nicht gerade billig)

[Leonidas]

Dummerweise zieht das halt einen ziemlichen Ball an weiteren Voraussetzungen nach sich, Windows-Server, Nebenläufigkeit von InDesign?, COM-Scripting, Sicherheitsaspekte etc.

Nicht unbedigt. Man kann es möglicherweise als Batch-Job einrichten, so dass die Kunden ihre Kärtchen einschicken und das einmal pro Tag auf einen Windows-PC kopiert wird und die PDFs erstellt werden. Oder ein Linux-Server der irgendwie mit einer Windows-Workstation kommuniziert.

Achja, weitere Möglichkeiten: Da ich mich mit GhostScript beschäftigt habe, könnte ich noch den Tipp geben, sich GhostScript 8.53 anzusehen, das hat Unterstützung für PDF/X3, außerdem kann man ein paar pdflatex-Hacks nutzen um es halbwegs PDF/X1-kompatibel zu bekommen (ich nutze tatsächlich pdflatex um Kataloge aus Python-Programmen zu generieren, aber da ist es mir herzlich egal ob die PDF/X oder was anderes sind).

[ferix]

Vielen Dank für eure Rückmeldungen. Jetzt habe ich mal einen groben Überblick, was es für Möglichkeiten gibt. Ich tendiere zum einen zu der PDFlib, die ja eigentlich dafür gemacht ist. Da man sich die Library ja auch herunterladen kann und somit erstmal alles entwickeln und testen kann ist das nicht schlecht. Sofern nach der Entwicklung alles so funktioniert wie gewünscht, leistet man sich dann eben die Lizenz

Auch die Variante über GhostScript und PDFLatex klingt sehr interessant und werde ich sicher mal genauer unter die Lupe nehmen.

[fhoech]

Auch wenns etwas OT ist, aber:

(...) die aus dem portable ein unportable machen.

Das ist nicht richtig, das Gegenteil ist der Fall. Erst durch klare Vorgaben, wie sie z.B. die PDF/X-Standards vorsehen, wird ein PDF erst wirklich "portable" und dadurch sicher reproduzierbar.

Damit kannst Du gezielt die Ausgabe festlegen (ICC-Profile, Drucktechnik, Rasterung etc.), was eigentlich nicht im Sinne des Erfinders von PDF ist, da die gewünschte Plattformunabhängigkeit negiert wird.

Die Plattformunabhängigkeit wird dadurch nicht negiert, sie wird dadurch erst hergestellt. Der PDF/X OutputIntent (nicht zu verwechseln mit dem ICC Rendering Intent bei Farbkonvertierungen) beschreibt mittels ICC-Profil (oder zur Not auch per Verweis auf z.B. eine ISO-Standard-Druckbedingung), wie die im Dokument enthaltenen Farbwerte zu interpretieren sind. Rastereinstellungen dürften in typischen PDF/X übrigens eher selten anzutreffen sein (auch wenn die Standards das zulassen). BTW, der "Erfinder von PDF" (Adobe) hat recht ausgereifte Unterstützung von PDF/X in seinen Produkten, von "nicht in seinem Sinne" kann also nicht die Rede sein

Das geht dann soweit, das Druckereien, die ein PDF/X-Dokument mit ihrerseits nicht unterstützten OutputIntent-Angaben bekommen, das nicht drucken können, d.h. es ist wichtig, die Vorgaben der Druckerei zu beachten (was ja sowieso der Fall ist).

"Nicht drucken können" stimmt so auch nicht, es gibt schliesslich keine technischen Hürden. "Nicht ohne weitere Verarbeitung (z.B. Konvertierung mittels Color Server und DeviceLink-Profilen in den Druckerei-'Hausstandard') drucken sollten" triffts wohl eher, schliesslich möchte kein Auftraggeber, der ein PDF für Druck auf (z.B.) gestrichenem Papier generiert, dieses auf ungestrichenem gedruckt sehen.

[jerch]

Das ist nicht richtig, das Gegenteil ist der Fall. Erst durch klare Vorgaben, wie sie z.B. die PDF/X-Standards vorsehen, wird ein PDF erst wirklich "portable" und dadurch sicher reproduzierbar.

Da muß ich Dir klar widersprechen, eine sichere Reproduzierbarkeit zieht eben hardwarenahe Angaben nach sich, die die Portabilität einschränken.

BTW, der "Erfinder von PDF" (Adobe) hat recht ausgereifte Unterstützung von PDF/X in seinen Produkten, von "nicht in seinem Sinne" kann also nicht die Rede sein

PDF und PDF/X haben unterschiedliche Zielsetzungen. Während Ersteres möglichst ubiquitär funktionieren soll (eben portable), ist Zweiteres auf möglichst getreue Ausgabe via Industrienormierung getrimmt.

"Nicht drucken können" stimmt so auch nicht, es gibt schliesslich keine technischen Hürden.
...

Hatte ich überspitzt dargestellt, da man bei nötigen Konvertierungen dann nachbessern muß und sich lieber gleich an den Druckereistandard hält.

[fhoech]

Da muß ich Dir klar widersprechen, eine sichere Reproduzierbarkeit zieht eben hardwarenahe Angaben nach sich, die die Portabilität einschränken.

Das musst du mir jetzt aber schon erklären , bzw. ohne ein konkretes Beispiel fällt mir da jetzt nichts Hinderliches ein (ausser eventuell Trapping befindet sich in einer PDF/X-Datei i.d.R. nichts hardwareabhängiges, aber das Trapping wird bei PDF/X eh meist weggelassen und hin zum Ausgabesystem verlagert). Eher im Gegenteil: Angenommen du hast ein PDF mit bestimmten Eigenschaften (Schrift, Farben, etc.). Einmal speicherst du es als PDF/X und einmal nicht. In der PDF/X Datei ist jetzt schonmal sichergestellt (unabhängig vom Ausgabesystem), wenn sie korrekt erstellt wurde (zwei Beispiele):

- Schrift sieht identisch aus wie das, was der Ersteller gesehen hat, denn PDF/X schreibt die Einbettung von Schriften vor (ok, in manchen PDF-Viewern lässt sich die Verwendung von Systemschriften erzwingen, aber das lassen wir mal aussen vor).
- Die Farbe ist eindeutig charakterisiert, so dass ein Ausgabesystem die korrekte farbliche Darstellung sicherstellen *kann*, wenn es dazu die Voraussetzungen erfüllt (diese Möglichkeit besteht erst gar nicht, wenn keine Profile eingebettet wurden).

Sicher, die Beispiele oben lassen sich theoretisch auch ohne PDF/X erreichen. Nur verstehe ich nicht, was daran die Portabilität einschränken soll. Wie gesagt, ein konkretes Gegenbeispiel wäre hilfreich. Hardwarenahe Angaben werden ausserdem imho in einer PDF/X-Datei eher verhindert, z.B. dadurch, das eingebettetes PostScript nicht zugelassen wird.

[jerch]

Ich kenne das Problem nur aus Kunden-, nicht aus Druckereisicht. Vor kurzem hatten wir das Problem mit einem CD-Cover+booklet, die Angaben waren nicht kompatibel, es wurde konvertiert, revidiert - es ziemliches Hin und Her bis die Farben und die Offsets stimmten. Problem war, daß die Druckerei mehrmals andere Angaben machte, die dann wieder nicht paßten. Mit den InDesign- und Illustratordateien war der Spuk dann vorbei.
Falls Dich technische Einzelheiten interessieren, frage ich gern mal unseren Graphiker, was da genau schief ging.

[fhoech]

Ok, interessant fände ichs schon (bin halt neugierig ). Eilt ja nicht.