Hi!
Ich bin auf der Suche nach einer Software, die mir einen Ordner mit beliebig vielen PDFs so konvertiert, dass ich jedes PDF in 4 unterschiedlich große PNGs gerechnet bekomme, die dann auch noch entsprechend benamst abgelegt werden.
Hat da jemand einen Tipp? Ich bin für jeden Hinweis dankbar.
Leider komme ich mit Automator nicht zurecht, und beim Erstellen einer Aktion in Photoshop komme ich auch gerade nicht weiter…

Die Software darf ruhig was kosten!

Sind die PDFs einseitig oder mehrseitig?

Wenn Du Platypus nimmst und dieses kleine Skript, das ich eben zusammengehackt habe (funktioniert mit allen Grafiktypen, die OS X unterstützt ab 10.6 oder 10.7 -- bei PDF natürlich nur immer die erste Seite), dann kannst Du das Ganze als Droplet abspeichern und anschl. einfach PDFs draufziehen. Die werden dann in einem Ordner unterhalb Benutzer Für alle Benutzer in den 4 Größenvarianten abgelegt, die Du in der 4. Zeile einstellen kannst.


Bzw. per pastebin:

Probier ich gleich mal aus! Besten Dank!

PDFs sind immer in diesem Fall immer Einseitig

Hat es geklappt? Ansonsten könnte ich Dir bei Photoshop und Automator helfen.

Das muß klappen, wenn man in Platypus die richtigen Settings wählt (siehe unten bzw. als Screenshot hier: ). Das Skript als pdf2png.sh abspeichern, dann in Platypus App-Name vergeben, dann als Typ "Bash" auswählen, dann per Drag&Drop das Skript in das Feld "Script Path" ziehen, einen eindeutigen Identifier vorgeben und dann noch mittels "Create" unten recht als Anwendung abspeichern -- mit default Settings). Und anschl. kann man auf das entstandene Programm alles Mögliche draufziehen und erhält -- so das Dateiformat unterstützt wird -- je 4 PNGs in den entsprechenden Größen.

Die Aussage vorhin, damit könne man nur Bildtypen umwandeln, war übrigens Quatsch, weil das Mini-Skript an QuickLook andockt. D.h. damit können von egal welchem Dateityp PNGs in den vorgegebenen Pixeldimensionen erzeugt werden, für die man auch QuickLook aufrufen kann.

Habs noch ein wenig anpassen lassen, und gut war es.

Nochmals vielen Dank.

Entwickler hat seine Spende bereits erhalten.

Danke für das Angebot. mit Automator könnt ich wirklich mal Hilfe oder einen Workshop gebrauchen. Das Programm kann angeblich so viel und fristet bei den meisten Leuten (wie auch bei mir) ein Mauerblümchen-Dasein. Gibt es da eine vernünftige Dokumentation dazu, oder muss man sich auf das beschränken, was der Support von Apple dazu anbietet?

Tutorials/Workshops (inkl. Screenshots), Beispiele und fertige Scripte für alle möglichen Anwendungsfälle für Automator und Services zum Runterladen und sofortigem Gebrauch zum Beispiel:

Mac OS X Automation , ,

Automator Leopard , ,

Automator Actions for Mac OSX Tiger

Automated Workflows

Besten Dank für Eure Hilfe!

Wünsche Euch schon mal ein schönes Wochenende.

Leider manches veraltet und für Leute, die sich Neuem gerne eher konzeptionell nähern, evtl. zu sehr "learning by doing".

Ich kombinier meistens beide Ansätze und schnapp mir ein (meist ja leider immer bocklangweiliges) Grundlagenbuch und stürz mich parallel auf konkrete Aufgaben. Bzgl. Automator-Grundlagen fand ich Ben Waldies Buch zu Automator in 10.5 tauglich. Gibt's inzwischen fürn Fünfer inkl. Versand:

10.5 klingt uralt, das Wesentliche ist aber: Automator kam mit OS X 10.4 in Version 1.0 raus. In 10.5 wurde massiv geändert bzw. Konzepte ergänzt (bspw. Loops -- eher was für Fortgeschrittene) und demzufolge war das völlig zu recht dann Automator 2.0. Und seitdem wurde konzeptionell nicht(s) mehr (viel) geändert, weshalb Automator in 10.9 auch nur die 2.4 als Versionsnummer trägt. Das Konzept ist ausreichend und stabil. Die spannenden Dinge passieren an anderen Stellen: den Automator Actions, mit denen man seine Workflows modelliert.

Danke!

Batch-Konvertierung von PDFs in PNGs ginge übrigens auch auf Basis von ImageMagick mittels des enthaltenen convert tools. Nur mal der Vollständigkeit halber, damit es ebenfalls genannt sei (und nicht, um es jetzt in den Vordergrund zu rücken). Ich denke, die bordeigenen Tools bzw. eine geschickte Kombination derselben sind schon ein guter und richtiger Weg.

Abgesehen davon scheint es auch die eine oder andere kostenfreie oder für kleines Geld erhältliche kleine App im AppStore zu geben, die batchmäßig PDFs in Bilder umwandeln kann (macht wahrscheinlich auch nix anderes als die systemeigenen Werkzeuge dafür zu nutzen).

Oder auch mit dem bordeigenen sips geht so eine Batch-Konvertierung ebenso ziemlich einfach und in wenigen Zeilen:

apfelquak: sips – Bildbearbeitung via Terminal

Stray Link: OS X Command line Image Manipulation

Hier wird anhand mehrerer Beispiele (Einzeiler) erläutert, wie man verschiedene Bildformate ineinander umwandelt oder auch z.B. ein PDF in PNGs umwandelt mittels sips.
Ich könnte mir vorstellen, dass auch obig verwendetes Quicklook unter der Haube auf sips zurückgreift, um obige Aufgabe zu erfüllen.

Example 1 – Convert PDF to PNG



Ebenso vom selben Autor auch: OS X Image Manipulation – Convert Multi-page PDF with sips and pdftk



Manpage sips: man sips
Apple sips Manpage online:

NAME
“sips — scriptable image processing system”
DESCRIPTION
This tool is used to query or modify raster image files and ColorSync ICC profiles. Its functionality
can also be used through the "Image Events" AppleScript suite.

Auch wenn ich jetzt wieder den Stempel Klugscheißer aufgedrückt bekomme Aber IM dafür zu nehmen (bzw. IM generell zu nehmen -- GraphicsMagick existiert seit über 11 Jahren und ist teils um mehrere Faktoren flotter) ist die denkbar schlechteste Idee (und speist sich meist aus einer Linux-Sozialisation und "so machen wir das schon immer").

IM hat für PDF früher auf GhostScript als "delegate" zurückgegriffen, sollte das PDF intern "kreativ" bzw. auch nur ein kleines bisschen von ColorManagement Gebrauch machen, dann sind die IM-Ergebnisse meist fehlfarbenbedingt der Brüller und außerdem ist das Ganze auch noch lahm (besser gleich GhostScript ab 9 nehmen, das enthält eine interne Colormanagement-Engine und kommt auch mit verschiedenen Farbmodellen im PDF um Welten besser zurecht und ist zudem deutlich schneller, wenn man es richtig parametrisiert, siehe bspw.

CoreGraphics in OS X, das für das Rendering von PDF zuständig ist (OS X' Darstellungs-Engine Quartz basiert ja zu 100% auf PDF) erbt automatisch die ColorManagement-Fähigkeiten von OS X als auch vollautomatisch Optimierungen unter der Haube, um von systemweiten Ansätzen, CPUs/GPUs effizienter zu nutzen, Gebrauch zu machen (Grand Central Dispatch und OpenCL -- je höher die OS X Version, desto flotter rendern PDFs bei gestiegener Qualität, Stichwort Antialiasing).

Grad unter OS X sollte man für den Zweck PDF-Rendering einen riesigen Bogen um unoptimierte 3rd-Party-Software machen außer man hat spezielle, respektive Prepress-Bedürfnisse (dann sollte man auf die Adobe-Libraries zurückgreifen, die in Acrobat Pro oder Callas' pdfToolbox stecken). D.h. anstatt convert (bzw. "gm convert", wenn man sinnigerweise statt Image- auf GraphicsMagick setzt) auf sips (CLI ), "Image Events" (AppleScript ) oder Automator setzen.

Das Mini-Skript, das ich gepostet habe, geht übrigens einen Schritt weiter und dockt nicht direkt bei OS X' PDF-Rendering- (bzw. Bildkonvertier-)Engine an sondern nutzt QuickLook (und damit einen Mechanismus, der nicht nur für sämtliche von OS X nativ unterstützen Bildformate und PDF PNGs rendern kann sondern schlichtweg für jedes Dateiformat, für das ein QL-Plugin existiert, sei's dass Apple oder die Hersteller von 3rd-Party-Software welche für ihre Dateiformate mitliefern (bspw. Microsoft Word oder Quark Xpress) oder dass man sich frei verfügbare oder kommerzielle QL-Plugins nachinstalliert (siehe und -- anschl. kann man dann mittels des Skriptchens auch von InDesign-Dateien oder irgendwelchen CAD-Dateien hochwertige PNGs rendern lassen)

Und genau deshalb kann man den Zirkus auch wunderbar für lau per Automator abfrühstücken und lernt auch noch was dabei. "PDF-Seiten als Bilder rendern" ist eine Standard-Automator-Action.

Thomas Kaiser:

Genau das. Zumindest von mir Denn ich möchte meinen Beitrag gerne als Bestätigung und Unterstreichung bzw. Ergänzung Deines vorangegangenen Beitrags wissen und nicht als Ersatz oder gar Widerspruch.
Deine längliche Belehrung jetzt hättest Du Dir deswegen sparen können, denn das wusste ich auch schon ohne Dich. Und habe mir trotzdem erlaubt, noch nach Dir was zu schreiben bzw. Dein Gesagtes um eine Facette zu ergänzen.

Können wir hier eigentlich auch mal miteinander argumentieren und im Sinne einer Sache, einem Ziel (in diesem Fall der Hilfe für den Fragenden) bzw. im Sinne eines großen Ganzen statt regelmäßig gegeneinander und zu sagen "Meine Lösung ist aber besser als Deine!" = "Mein Schwanz ist aber länger als Deiner!"?

Von mir jedenfalls hast Du eine Handreichung. Magst sie annehmen?

Gerade den Punkt "dabei lernen" halte ich für sehr wichtig... Wenn man einmal die Mächtigkeit des - eigentlich nicht schwierig zu bedienenden - Automators begriffen hat... kann man viele Dinge die man zuvor händisch machen musste komplett automatisieren - natürlich auch außerhalb von Bildbearbeitung und zumeist auch ohne einen (optional möglichen) Skripteinsatz.
So habe ich z.B. lange ein eigenes Automator-Progrämmchen benutzt welches von meinem Webserver täglich die Datenbank-Datei herunterlädt, lokal dann komprimiert, umbenennt (mit Datum drin und so) und dann auf ein Archivlaufwerk verschiebt. Das ganze lief über Jahre problemlos (bis ich den Server irgendwann nicht mehr brauchte). Das Automator-Programm wurde durch den normalen Apple-Kalender gestartet. Alles absolut easy und Apple-like

O Mann, was für ein Mimosenverein hier. Wir führen doch keine private Diskussion sondern unterhalten uns in einem technischen Forum, das ein ziemlich hohes Google-Ranking hat, d.h. in der Öffentlichkeit! Das, was Du als Belehrung wahrnehmen willst, war eine allgemeine Ergänzung/Korrektur. Und IM -- speziell für das Rendering von PDFs -- zu nehmen, ist eben nunmal nichts weiter als eine Scheißidee, vor allem am Mac. Warum das so ist, hab ich bereits vorher ergänzt bzw. im Detail erläutert (und das aus dem Wissen diverser Projekte heraus, wo wir so ziemlich alle Varianten, PDF zu rendern, durchprobiert haben).

Richtig genial wird der Automator vor allem dann, wenn man den Workflow als "Dienst" abspeichert. Denn dann kann man bspw. ein Minitool systemweit zur Verfügung stellen, das in egal welchem Cocoa-Programm nach Rechts- bzw. -Klick für markierten Text zur Verfügung steht. Wir haben für einen Kunden auf dem Weg mit supersimplen Automator-Aktionen die Brücke zwischen zwei Webbasierten Systemen geschlagen, für deren Verbindung auf "normalem IT-Weg" ein Projekt im sechstelligen Euro-Bereich fällig gewesen wäre. Jetzt rechtsklicken die User einfach in der einen Webanwendung auf bspw. 'ne Artikelnummer und springen direkt in einem anderen Browser-Fenster in den Stammdatensatz der anderen Webanwendung. Und der Code dafür sind paar lächerliche Zeilen. Und die Essenz ist: OS X Frameworks richtig bzw. kreative zu nutzen, macht mächtig produktiv

Thomas Kaiser:

Ich halte Dir lediglich den Spiegel vor bzw. antworte Dir adäquat.

Ich erinnere daran, dass Du Dich selber der Klugscheißerei geziehen hast, Deinen Beitrag mit solchen Worten höchst selbst eingeleitet hast. Also hast Du wenigstens schon geahnt, wie es möglicherweise aufgefasst werden könnte. Jetzt sei Du nicht mimosenhaft, sondern halte das (fast erwartete?) Echo einfach mal aus.

Du überbewertest das, was ich zu IM gesagt habe. Nimm Dir meinen diesbzgl. kleinen Satz bitte nochmal vor ("Batch-Konvertierung von PDFs in PNGs ginge übrigens auch auf Basis von ImageMagick mittels des enthaltenen convert tools. Nur mal der Vollständigkeit halber, damit es ebenfalls genannt sei (und nicht, um es jetzt in den Vordergrund zu rücken)") und vergleiche bitte, welchen Raum ich hingegen der systemeigenen sips-Lösung gegeben habe.

Du überreagierst und ziehst Dich an einer Sache hoch, der ich viel weniger Raum eingeräumt habe als Du inzwischen (auf Deine für GM gegenüber IM werbenden Ausführungen mag ich gar nicht groß eingehen, weil ich sie so nicht teile und IMs Weiterentwicklung in den letzten Jahren deutlich lebendiger war als die von GM -- den GM-Fork hatte ich zwischenzeitlich sogar für tot gehalten, zumal auf MacPorts, das ich sehr viel nutze und das für mich seit Jahren nahezu unverzichtbar geworden ist).

Also mal bitte ruhig mit den Pferden. Und mal locker durch die Hose atmen. Alles wird gut.
Nach Rom führen der Wege mehrere. Und nicht nur ein einziger.


Und ja, der Automator ist im Allgemeinen unterschätzt und findet leider zu wenig Anwendung, weil nicht bekannt oder nicht genügend bekannt. Genauso wie sips.

Herrlich. Und ich antworte jetzt ein letztes mal inhaltlich auf das, was Du von Dir gegeben hast.

- GraphicksMagick tot? Aha:
- Problem mit MacPorts? Homebrew nehmen "brew install graphicsmagick"
- QuickLook auf sips basierend? Natürlich nicht.
- sips für PDF-Rendering? Wie Auflösung angeben? Wie auf 4 verschiedene Größen skalieren? Wie Aspect Ratio berücksichtigen?
- "Hilfe für den Fragenden"-Modus, den Du mir absprichst? Sag mal, dass ich dem Anfragenden gestern in paar Minuten eine schlüsselfertige Lösung hingehackt habe, die aus gutem Grund auf qlmanage aufsetzt (weil dort Skalierung auf Pixelmaße bei Beibehaltung des Aspect Ratio bamperlsimpel ist), haste schon mitbekommen?
- Schwanzvergleich? Weil ich sachliche Darstellungen, die Dritte auf den Holzweg führen könnten, ergänzen oder korrigieren will? Sind wir in einem technischen Forum oder nicht? Geht's hier um das Fachliche oder um persönliche Befindlichkeiten bzw. das Recht, nicht ergänzt oder kritisiert zu werden?

Das frage ich Dich. Ich halte mich ja bisher zurück, Dich zu verbessern, weil mir daran nicht liegt. Obwohl ich da durchaus die eine oder andfere Sache etwas anders sehe als Du und das auch gut begründen kann.

Zudem: ausgerechnet mit Homebrew kommst Du mir da und hast mir zuvor Linux-Denke vorgeworfen. Nein, ich bin und bleibe bei MacPorts. Weil's nativer ist, von Apple gehostet, von Apple-Mitarbeitern getragen, von Apple selber bevorzugt, von FreeBSD-Gründer und langjährigem Unix-Beauftragen, Apples, Jordan K. Hubbard von FreeBSD auf den Mac gebracht. Ich bevorzuge aus gleich mehreren Gründen diesem nativen MacPorts gegenüber dem Fremdprojekt HomeBrew, habe mich ganz bewusst für MacPorts entschieden und bleibe dabei, ich finde, es fügt sich viel besser in die OSX-Umgebung ein, kollidiert mit nichts, bietet mehr ports an, und die ports sind unterm Strich insgesamt auch besser gepflegt.

Ja, habe ich. Und? Habe ich Dir da, was Deine Bash-Lösung und Platybus angeht, irgendwo auf irgendeine Weise widersprochen? Nein!
Ich finde, Du reagierst grad' nicht sehr professionell, weil zu unrecht echauffiert über etwas, das gar nicht zur Debatte steht und der eigentliche Anlass im Grunde eine Nichtigkeit ist. Was habe ich Dir getan? Niemand spricht Dir hier irgendwas ab, ich schon gar nicht. Im Gegenteil. Komm' mal bitte wieder runter und entspanne Dich!

Ich komme mir ja fast vor, als hätte ich Majestätsbeleidigung begangen, als hätte ich Dich irgendwie bei der Ehre gepackt, Deine Kompetenz angezweifelt, den Versuch unternommen, Dich vom Sockel zu stoßen oder dergleichen. Nichts dergleichen habe ich getan, nichts dergleichen habe ich vorgehabt, nicht dergleichen habe ich im Sinn. Sollte fälschlicherweise der Eindruck entstanden sein, tut es mir leid.

Wie im Kindergarten hier… *kopfschüttel*

Thomas Kaiser

Danke! GraphicsMagick kannte ich noch nicht!

Dann eine Bitte: Mach das einfach. Gib mir fachliche Rückmeldungen und erspar mir Schwanzvergleich-/Majestätsbeleidungs- und sonstiges psychosoziales Gesülze als auch Spekulationen, warum ich wohl was wie und überhaupt... Weil mich an der Teilhabe in einem Technik-Forum neben dem Teilen meines Wissens nur interessiert, noch was dazuzulernen (gerne und vor allem durch Korrektur/Richtigstellung meines Geschreibsels)

Dann zum Beispiel der Umstand, dass ich das Perl-Interface zu ImageMagick, das CPAN-Modul PerlMagick, mit dem Namensraum Image::Magick brauche (ich benutze so Einiges aus dem CPAN, sowohl systemseitig vorhanden und wenn nicht, dann per MacPorts nachinstalliert oder direkt aus dem CPAN per perl -MCPAN -e shell) bzw. einige Perl-Module wollen das, brauchen das, haben diesbzgl. eine Abhängigkeit. Und ich das nicht einfach so durch die Variante von GraphicsMagick ersetzen kann bzw. eine Menge Software aufgrund von Abhängigkeiten nun mal eben ImageMagick bzw. dessen Perl-Modul Image::Magick haben will und nicht den GraphicsMagick-Fork. Zur Nutzung vom zu GraphicsMagick passenden Perl-Modul müsste eine Menge Software entsprechend angepasst sein und den GraphicsMagick-Namensraum verlangen statt den von ImageMagick, und das ist sie (leider) nicht (zumindest bei den Perl-Moduln, die mir bisher so untergekommen ist und der Software, die ich so verwende).


Siehe dazu u.a. auch die Ausführungen betreffend das Per-Modul auf der zugehörigen GraphicsMagick-Seite: :

Es kann also gute Gründe geben, auf ImageMagick bzw. dessen Perl-Interface Perl-Magick zu setzen bzw. aufgrund nicht beeinflussbarer Abhängigkeiten und Forderungen bestimmter eingesetzter Software darauf setzen zu müssen statt auf GraphicsMagick und dessen Perl-Interface. Und wenn ich mich recht erinnere, war das auch damals der Grund, warum ich, obwohl ich von der Existenz von GraphicsMagick wusste und mich damit auseinandergesetzt hatte mit diesen beiden Projekten, mich dann pro ImageMagick und contra GraphicsMagick entschieden habe bzw. musste.

Zumal auf verschiedenen Webservern von der Häufigkeit eher ImageMagick vorinstalliert ist und eher seltener GraphicsMagick, was dann wiederum auch die Zugeschnittenheit und Ansprache verschiedener Software eher auf ImageMagick denn auf GraphicsMagick erklären hilft. Ist halt so; und sicher auch historisch so gewachsen.

Hoffe, das ist Dir Begründung genug, warum man es evtl. anders sehen und machen kann oder gar muss als von Dir bislang so konstatiert und mit Verve anempfohlen.
Aber das nur am Rande und Off-Topic.