Skript: PDF Skalieren

Waldbär

Ontario
Registriert
13.08.06
Beiträge
351
Hallo Apfeltalk-Skripter, Programmierer und ähnliche Spezialisten,
ich habe in letzter Zeit oft folgenden (manuellen) Arbeitsablauf:
- PDF öffnen (Vorschau)
- Drucken-Dialog: Größe auf 200%, PDF sichern auf Desktop
- schließen
Kann man das irgendwie automatisieren?

Meine Versuche bisher: Ich habe es mit AppleScript GUI-Scripting versucht, komme aber nur bis zum Druck-Dialog (mittels keystroke p), für die dann nötigen Klicks kriege ich es aber trotz Accessibility Inspector irgendwie nicht hin, die Verweise auf die Objekte richtig zu basteln... vielleicht sollte ich dazusagen, dass ich noch nicht viel mit AppleScript gemacht habe... ist das also überhaupt ein Erfolg versprechender Ansatz? Oder kann man irgendwie direkter einen Druckbefehl mit Attributen geben à la "drucke PDF auf 200% Größe", ohne Einbezug des Vorschau-Programms? Ist evtl. der Adobe Reader oder ein anderes Programm sogar besser mit Skripten zu bedienen und empfiehlt sich auch für mein Problem? Wenn ihr sagt, besser nicht AppleSkript sondern XXX bin ich dafür auch offen.

Ich danke euch für eure Hilfe, Ideen, und Vorschläge im Voraus!
Viele Grüße
Waldbär


Ursprung des Problems: Ich habe einige mehrseitige Dokumente, die ich gerne mit doppelter Auflösung (600dpi) scanne, das dann runterrechne auf 300dpi und als JPGs speichere, aus denen ich dann wieder mittels Automator-Aktion ein PDF baue. Dummerweise hat das dann immer nur die halbe Ausgabegröße (k.A. warum, ich stelle ganz offiziell die Auflösung runter bei gleichbleibenden Meter-Maßen, beim JPG-Export scheint das wieder auf 600dpi hochgestellt zu werden, wohl ein Bug in Affinity Photo). Meist ist die falsche Auflösung kein Problem, aber Windows hat scheinbar keine Skalierungsfunktion beim Drucken, was es ziemlich umständlich macht in der weiteren Verwendung...
 

sedna

Galloway Pepping
Registriert
22.10.08
Beiträge
1.358
Hallo,

es gibt virtuelle Drucker (heißt das so?) z.B. RWTS PDFWriter und andere ...

So ganz habe ich dein Problem nicht verstanden, aber du scheinst die JPGs mit Affinity Photo "runter zu rechnen" ... ist das überhaupt nötig?
Und ich denke, das Ganze ließe sich mit dem Automator alleine gut realisieren:
Falls dir die PDFs zu "schwer" sind, kannst du nach der Aktion Neues PDF aus Bildern die Aktion Quarz Filter auf PDF-Dokumente anwenden hinzufügen.
Erstelle dir dazu mit dem Color-Sync Dienstprogramm einen eigenen Filter, füge dort als Komponente Bild-Anpassung hinzu und trage deinen Auflösungs-Wunschwert ein (z.B. 300 Pixel/Zoll)
Falls dann immer noch zu "schwer", füge noch die Komponente Bild-Komprimierung hinzu.

Um den Filter auch in Vorschau zu nutzen, müsste er aus ~/Library/Filters nach /Library verschoben werden ... aber das braucht es hier ja nicht.

Gruß
 

Waldbär

Ontario
Registriert
13.08.06
Beiträge
351
Hallo Sedna,
vielen Dank für deine Antwort! Die Filter kenne ich schon, nutze ich auch immer wieder. Beim Skalieren der Scans nehme ich lieber Affinity Photo, weil ich da dann sowieso gerade drin bin (Farbanpassungen u.ä.) und dann mehr Kontrolle habe. Die PDFs haben schon meine Wunschbildgröße/Auflösung in Pixeln und sind auch sehr überschaubar in der Größe. Das einzige Problem ist der dpi-Wert, der nicht stimmt und deswegen die Seitengröße im Druck kleiner macht. Der ist also zu ändern OHNE die Bilder neu zu rechnen.
Das kann ich machen, indem ich ein PDF auf 200% wiederum als PDF drucke bzw. speichere. Der Vorgang an sich klappt also, ich bekomme nur nicht hin, das zu automatisieren.

Das Problem in Affinity Photo habe ich übrigens mittlerweile gefunden (Haken "Meta-Daten speichern" beim JPG-Sichern entfernen), zukünftige von mir erstellte PDFs werden also die richtige Druck-Auflösung eingetragen haben. Wenn das mit dem UI-Skripten funktionieren würde, fände ich trotzdem super, weil sich das ja sicher auch auf andere Dinge übertragen ließe, ganz davon abgesehen, dass ich jetzt schon so einige PDFs mit dem falschen Auflösungswert habe.

Ich habe gerade gesehen, dass "Bilder drucken" in Automator auch eine "Größe anpassen" Funktion hat (wenn auch nur als Häkchen ohne Einstellungen). Die scheint aber mit PDFs nicht zu funktionieren; habe sie mit PDFwriter getestet und sie zeigt sich wirkungslos (Output=Input), wobei es manuell direkt funktioniert (scheint also nicht an PDFwriter zu liegen)...

EDIT: Habe ein Programm gefunden, um PDFs stapelweise zu skalieren, ohne Qualitätsverlust: PDF-BatchScale. Damit kann ich zumindest meine vorhandenen PDFs sehr schnell auf A4 bringen. Die zukünftigen werden ja hoffentlich jetzt ohne diesen Schritt auskommen.
 

sedna

Galloway Pepping
Registriert
22.10.08
Beiträge
1.358
Ah und ok :)

Schön, dass du da eine Lösung gefunden hast!
Btw: GUI Scripting ist eh blöd und nur die letzte Lösung und wo immer möglich, zu vermeiden.

Und -wie mir gerade auffällt - in meinem Beitrag habe ich mal schön dpi und ppi in einen Topf geworfen *hüstel
Da ich damit eher selten zu tun habe und den Unterschied daher nicht wirklich gefressen habe, möge es mir verziehen sein :p
 

Waldbär

Ontario
Registriert
13.08.06
Beiträge
351
Warum ist GUI Skripting eigentlich blöd? Funktioniert es nicht oder ist es nur umständlich+langsam? Wenn man es zum Laufen kriegt, sollte man doch damit so ziemlich alles automatisieren können, oder?

Bzgl. ppi vs. dpi: Ich halte den Unterschied auch für spitzfindig, ist doch nur einer des Mediums, oder? PPI sage ich maximal wenn es um Bildschirmleistungsmerkmale geht, ansonsten dpi... im Affinity Forum habe ich ganze Threads dazu gesehen, das halte ich echt für übertrieben. Es geht halt um die Dichte der gespeicherten Bildpunkte eines gerasterten Bildes, nicht mehr und nicht weniger. :rolleyes:
 

sedna

Galloway Pepping
Registriert
22.10.08
Beiträge
1.358
Danke für die kurze Zusammenfassung :cool:

Zu GUI Scripting: umständlich und vor allem unsicher!
Läuft nicht wirklich immer rund ... hier und da müssen auch mal delays eingebaut werden

Hier zum üben (mit dem Accessibility Inspector ...wobei der in der deutschen Fassung für AppleScript eventuell etwas verwirrend ist und ich den alten daher praktischer finde)

Code:
tell application "Preview" to activate
tell application "System Events" to tell process "Preview"
    click menu item 23 of menu 1 of menu bar item 3 of menu bar 1
    --oder:
    --click menu item "Drucken …" of menu 1 of menu bar item "Ablage" of menu bar 1
    set ps to sheet 1 of window 1
    click radio button 1 of radio group 3 of ps
    set value of text field 4 of ps to "200"
    click menu button "PDF" of ps
    click menu item 2 of menu 1 of menu button "PDF" of ps
    --keystroke return
end tell
 

Waldbär

Ontario
Registriert
13.08.06
Beiträge
351
Cool, dein Skript funktioniert! Aber wo zum Teufel kriegst du die Indexnummern der Objekte her? Teils ist es ja logisch abgezählt, aber warum z.B. "Drucken = 23" oder radio group "3"? Ich finde die Indizes im Accessibility Inspector nicht wieder. Den UIElementInspector habe ich von deinem Link runtergeladen, finde jedoch keinen Unterschied in den dargestellten Informationen.
Danke für die Infos, hier lerne ich gerade einiges! :)

PS: Mit so einem Indexbasierten Skript müsste es doch auch sprachunabhängig funktionieren, mit den Namen "Drucken..." u.ä. eher nicht, oder?
 

sedna

Galloway Pepping
Registriert
22.10.08
Beiträge
1.358
Die Indexnummern sind tatsächlich abgezählt :p
Drucken… ist der 23.te Menüpunkt ...
PS: Mit so einem Indexbasierten Skript müsste es doch auch sprachunabhängig funktionieren, mit den Namen "Drucken..." u.ä. eher nicht, oder?
Ja!
Hierzu mal ein passendes Statement aus einem anderen Thread und von einer kompetenteren Quelle:
[…] hat ja bereits darauf hingewiesen, dass wir hier die UI Scripting Funktionalität nutzen, was zunächst einmal ein recht spezieller Fall im Vergleich zu gewöhnlichen Applescripts ist. Da dein Skript programmatisch auf die Benutzeroberfläche der Anwendung zugreift, ist solch ein Skript in der Regel wenig robust gegenüber irgendwelchen Änderungen in der UI. Wenn Du Pech hast, nicht aufpasst, und sagen wir mal davon ausgehst, dass der Index eines bestimmten Knopfes in der Symbolleiste konstant bleibt, zerschießt es Dir das Skript bereits, wenn der Benutzer nur die Position des Knopfes änderst. Schlimmstenfalls kann dann bspw. statt des “Empfangen”-Knopfes mal eben der Knopf zum Löschen einer Mail gedrückt werden. Es ist somit in der Regel ratsam, die Elemente möglichst präzise anzusprechen um unvorhergesehene Verwechslungen zu vermeiden, so dass eine geänderte UI in einer Fehlermeldung resultiert, statt in einem geänderten Verhalten des Skripts. Dieses Vorhaben wird leider dadurch erschwert, dass die UI-Elemente mit lokalisierten Namen angesprochen werden, was dazu verführt, den Index von Elementen zu nutzen um das Skript universell benutzen zu können.

Nun, jedenfalls ist das UI Scripting immer eine Notlösung gegenüber gewöhnlichen AppleScripts, die auf von einer Anwendung speziell zur Verfügung gestellten Befehlen aufbauen, welche direkt auf das Modell der Anwendung zugreifen können. Dazu kommt es darauf an, dass das vorliegende Programm ein eigenes Scripting Dictionary (bzw. die darin aufgeführte Scripting-Funktionalität) anbietet. Wie schon […] erwähnt, kannst du im Applescript-Editor im Fenster-Menü die Bibliothek aktivieren, um dort für beliebige Programm zu überprüfen, ob ein Scripting Dictionary existiert, bzw. wie sein Inhalt aussieht.

Übrigens kann man mit AppleScript die UI Elemente abfragen:
Code:
---z.B.
tell application "System Events"
tell process "Preview"
get UI elements of menu bar item 3 of menu bar 1/ window 1/ usw.
end tell
end tell

- - - - - - - - - - - oder

tell application "System Events" to tell process "Preview"
properties of every/some/first radio button of every/some/second radio group of sheet 1 of window 1 --whose value is 1/2/0
end tell