hallo zusammen

in letzter zeit wird hier gegenüber anwendern ziemlich lautstark gegen das erzeugen von postscript-dateien via drucken geschimpft. ich kann diese aufregung nicht nachvollziehen. ja, die fehlenden informationen für pdf-boxen sind ein mangel -- der aber mit bekannten methoden einfach eliminiert werden kann.

Antwort auf [ Detlev Hagemann ]

Die zusätzlichen Seitenstands-Ungenauigkeiten sind im PS über Druckdialog von 7 zwar kleiner geworden, aber immer noch vorhanden. Sie basieren angeblich auf den nur Punkt-genauen Angaben über die Papiergröße in den PPDs.

detlev, hast du mir ein beispieldokument? bei meinem versuch mit xpress 7.2 und acrobat pro 7.0.9 (und natürlich impresseds registration mark patch ;-)) kann ich keinerlei unregelmässigkeiten feststellen.

was entgeht mir, was diese aufregung rechtfertigt?

Hallo gremlin,

wenn Du mit Passkreuzen arbeitest und dem Patch, dann ist alles ok. Denn hier rettet der Patch und "berechnet" zusammen mit dem Distiller für die entstehende PDF-Datei auf Basis der Beschnittzeichen den Seitenstand neu.

Aber was machst Du bei Dokumenten ohne Passmarken? Was machen PDF-Erzeuger ohne den Patch?

Erzeuge mal eine 100x100-Anzeige und schreibe PS-Code ohne Passmarken und ohne Anschnitt.

hallo detlev

Antwort auf [ Detlev Hagemann ]

Erzeuge mal eine 100x100-Anzeige und schreibe PS-Code ohne Passmarken und ohne Anschnitt.

dokument 100x100mm, fläche 100x100mm, einmal über drucken, einmal über export > ps ausgegeben, distillieren (diesmal ohne irgendwelche patches ;-)).

media box (beim export auch trimbox) bei beiden:
100x100mm (283.465x283.465 pt)

fläche
via export: stand x 0.01 y 0.00, b 99.99 h 100.00
via druck: stand x 0.00 y 0.01, b 99.99 h 99.99

ich bin mir nicht nicht sicher, was ich daraus folgern soll...?

Hallo gremlin,

erste Anmerkung:
Die "gedruckten" PS-Dateien lassen sich nicht mit PDFX-ready-Settings distillieren.


Meine typische 100x100-Anzeige (ich variiere natürlich auch die Größe) hat für optische Kontrollzwecke immer einen 0,1pt-Rand. Vergleiche ich in Acrobat optisch bei stärkster Vergrößerung die Ränder der "gedruckten" mit der "exportierten" Datei sind die schlechtere Positionierung der "gedruckten" PDF-Datei zu sehen, aber es ist schon wesentlich (!) besser als in älteren XPress-Versionen. Der Hauptungenauigkeit scheint jetzt in der abmaskierenden Box zu liegen.

hallo detlev

Antwort auf [ Detlev Hagemann ]

Der Hauptungenauigkeit scheint jetzt in der abmaskierenden Box zu liegen.

stimmt, eine maske war da auch noch...
via export: stand x 0.01 y 0.00, b 100.00 h 100.00
via drucken: stand x 0.00 y 0.01, b 99.99 h 99.99

die differenzen, die ich finden konnte (auch in verschiedenen formaten), betrugen bisher jeweils +/-0.01 mm. in dem 100x100-beispiel fängt die differenz damit an, dass die beinhaltete fläche (auf beiden ausgabewegen) eine ungenaue grösse und positionierung aufweist, genauso wie die sie umschliessende maske.

fazit: lassen wir die kirche im dorf -- 0.01 mm ist keine wirkliche differenz. und wenn doch, entsteht sie auf beiden wegen. dies scheint also kein grund gegen drucken zu sein.

Hallo zusammen,

das gefällt mir. :-)

Ich bin erst seit kurzem am Testen der Ausgabe von QXP 7. Habe mich bislang lieber auf QXP 6.52 verlassen. :-)

Dabei haben mich verschiedene Wissende davon überzeugt, den Weg über den PDF-Export vorzuziehen. Nur wenn ich dies hier lese, komme ich ins Grübeln...

Wenn es Thomas mit seinem Virtual Printer Dingens (VPD) ;-) schafft, den Distiller-Abbruch zu beseitigen und wir die entsprechenden XTs und/oder Patches verwenden, sollte doch der PDF-Erstellung über den Drucken-Dialog nichts mehr im Wege stehen?

Gruß
Bernhard

Hi Bernhard,

Antwort auf [ Bernhard Werner ]

Wenn es Thomas mit seinem Virtual Printer Dingens (VPD) ;-) schafft, den Distiller-Abbruch zu beseitigen

Da gibt es "eigentlich" nix zu beseitigen (bis auf zwei kleine Fixes, einer wegen MacOS X > 10.2 und einer wegen auf einmal lokalisierter Joboptions-Bezeichnung seitens aktueller Distiller-Versionen), denn die Funktionalität steckt in dem Backend seit mehr als 4 Jahren bereits drin. Wenn Du den "Virtual Printer" bei werkflow.ch geladen hast, dann hast Du mein CUPS-Backend mit Stand vom 20. 3. 2003, bei dem eben nur eine einzige Funktionalität "freigeschalten" ist.

Das mit den Distiller-Hotfoldern ist simpel zu aktivieren. Distiller öffnen und einen (oder mehr -- besser für den "Aha-Effekt") überwachte Ordner unterhalb

    Benutzer:Für alle Benutzer:PS-Files

anlegen. Anschl. ab in Terminal.app und das Folgende eingeben (schaltet "distiller-Modus" frei, patcht die zwei oben erwähnten Probleme und startet den CUPS-Scheduler neu, damit die neuen "Drucker" auch dem System zur Verfügung stehen):

Code

cd /usr/libexec/cups/backend 
sudo sed -e 's/^#!\/bin\/sh/#!\/bin\/bash/' -e 's/folder\.joboptions/\*\.joboptions/' <postscriptfile >distiller 
sudo chmod 755 distiller 
sudo killall -SIGHUP cupsd 

Das wär's bereits (für das erste "sudo" wird allerdings ein Paßwort eingefordert... und funktionieren tut es so nur, wenn man mit einem Admin-Account angemeldet ist. Ansonsten müsste noch ein "su [Name des Admin-Accounts]" vorneweg.)

Anschl. im "Drucker Dienstprogramm" mit gedrückter [alt]-Taste auf "Weitere Optionen" gehen und einen der vorher im Distiller eingerichteten Hotfolder auswählen, PPD auswählen (keine von Adobe, weil sich sonst Adobes "Printer Dialog Extension" jedesmal beim Drucken einmischt -- siehe Beschreibung im Usenet), fertig.

Anschl. kann man da reindrucken und das Backend agiert nun im "distiller-Modus", d.h. transportiert das PS-File in den passenden Hotfolder, verschiebt ihn ganz am Ende in den "In"-Ordner und der Distiller kümmert sich um den Rest.

Da das da oben aber immer noch zu aufwändig ist, gibt's die Tage eine Betaversion, die all das von alleine macht, ein GUI für die Konfiguration mitbringt, auf PPD-Probleme hinweist, Postprocessing-Mechanismen (bspw. via Automator) einbinden kann, paar Bugfixes und einige neue Features enthält (die dann hoffentlich auch mal wer nutzt), etc. etc.

Aber die Grundfunktionalität des Dingens mit all den verschiedenen Betriebsarten existiert seit bald 'nem halben Jahrzehnt -- nutzt bloß niemand ;-)

Gruss,

Thomas

Antwort auf [ Thomas Kaiser ]

Aber die Grundfunktionalität des Dingens mit all den verschiedenen Betriebsarten existiert seit bald 'nem halben Jahrzehnt -- nutzt bloß niemand ;-)

Gar nicht wahr ;-)

Hi Thomas,

ohne es getestet zu haben, gibt es (für mich) noch drei unschöne Dinge:
- der Distiller muss immer laufen/gestartet sein
- die erzeugte PDF-Datei wird nicht direkt nach dem Distillen geöffnet
- die erzeugte PDF-Datei tummelt sich in irgendwelchen Hotfoldern

Oder sehe ich das falsch?

Gruß
Bernhard

Servus Bernhard,

Antwort auf [ Bernhard Werner ]

ohne es getestet zu haben, gibt es (für mich) noch drei unschöne Dinge:
- der Distiller muss immer laufen/gestartet sein
- die erzeugte PDF-Datei wird nicht direkt nach dem Distillen geöffnet
- die erzeugte PDF-Datei tummelt sich in irgendwelchen Hotfoldern

Oder sehe ich das falsch?

Nö, alles korrekt. Aber ein paar Anmerkungen:

1. Der Distiller muß aktuell laufen und im Hotfolder-Betrieb agieren (zur Erinnerung: Ich hab die Lösung zu einem Zeitpunkt programmiert, als gerade 10.2 frisch rausgekommen war, ein paar Verrückte schon unter MacOS X mit DTP-Anwendungen gearbeitet haben aber der Distiller nur in der Classic-Umgebung zur Verfügung stand --> genau dafür und für paar anschl. hinzugekommene Anforderungen war dieser Hotfolder-Modus gedacht)

Es gibt dazu Alternativen, d.h.

* Distiller selbst ansteuern und ihm Pfad zu PS-Datei und Settings direkt übergeben (hat ein Anwender mal gemacht, weil in irgendeiner Kombi aus Distiller und MacOS X die Hotfolder nur sehr schleppend liefen). Anbei Dieter Mays Skript ("Ordneraktion", d.h. auch nur Hotfolder aber eben mit MacOS X Bordmitteln anstatt Distiller-Bordmitteln), unkommentiert und ungetestet -- das Wesentliche fürs Verständnis bzgl. Distiller-Aufruf kann man sich aber rauspuhlen:

Code

property PDF_Settings : "/PDF/Settings/PDF_Settings/DIGI.joboptions" 
property KeepPS : false 
 
on adding folder items to this_folder after receiving these_items 
	repeat with i from 1 to number of items in these_items 
		set this_item to item i of these_items 
		set PosixFile to («event SystPsix» of this_item) 
		if (this_item as text) ends with ".ps" then 
			tell application "Acrobat Distiller 6.0.2" 
				Distill adobePDFSettingsPath PDF_Settings sourcePath PosixFile 
				set s to the result 
			end tell 
			if KeepPS is false and s is true then 
				set theCommand to "/bin/rm -f " & (quoted form of (POSIX path of this_item)) 
				do shell script theCommand 
			end if 
		end if 
	end repeat 
end adding folder items to 

* Dann gäbe es die Möglichkeit, die DistillerLib zu nutzen, so wie es bspw. Helios macht -- dafür muß der Distiller als Anwendung nicht klassischerweise laufen sondern es wird einfach ein eigenes Progrämmchen gegen die Lib gelinkt und die Distiller-Funktionalität ausgeliehen. Das werde ich aber nicht machen, da man dazu mit C oder anderen Hochsprachen agieren müsste aber das CUPS-Backend ein simpel zu durchblickendes Skript bleiben soll.

* Dann schließlich gäbe es die Möglichkeit, aus dem Backend heraus Adobes pdf- (Distiller 6 oder 7) bzw. pdf800-Backend (Distiller 8) anzusteuern. Nur wozu? Die Funktionalität hat man ja heute auch schon so (wenn sie denn funktionieren würde -- siehe weiter unten)

2) Mit ein Feature des Distiller-Hotfolder-Ansatzes ist ja, daß man nicht bei jedem Druckvorgang von der Adobe-PDE genervt wird, die fragt, wohin die PDF-Datei gespeichert werden soll (wichtig, v.a. für automatisiertes Drucken per Skript, wo einem die "Printer Dialog Extension" jedesmal in die Suppe spucken würde). Wenn man die Ziel-Datei nicht im Hotfolder haben will, kann man ja am Ende von meinem Backend einfach ein Postprocessing-Skript aufrufen lassen, daß das PDF sonstwohin verschiebt (in der Version, die ich jetzt gerade baue, alternativ zu Unix-Skripten auch mittels Automator-Workflows, d.h. Nutzer von MacOS X ab 10.4 können sich nahezu beliebige Funktionalität in Automator zusammenklicksen und die dann automatisch vom Backend im Anschluß ausführen lassen (bspw. PDF kopieren oder PDF zippen lassen und irgendwohin mailen oder Bilder in PDF komprimieren und Wasserzeichen drauf setzen, PDF in Acrobat öffnen lassen, etc. etc.)

Zur Vertiefung: Apfelwiki-Artikel, v.a. Links am Ende checken

3. Was Du offensichtlich willst, ist schlichtweg Adobes PDF-Erstellung in funktionierend, oder? Also daß Du nach dem Speicherort gefragt wirst, die DistillerLib im Hintergrund die Arbeit übernimmt und anschließend das PDF in Acrobat geöffnet wird?

Falls ja, dann soll das halt Quark und/oder Adobe fixen. Ich meine, es ist ja schon ein Witz... da haben die ersteren 600 Mann in Indien sitzen und die letzteren alleine 1100 für Acrobat (auch in Indien)... und die scheitern an so einer Trivialität?

Wie im Thread schon angemerkt:

* Quark schiebt die entstandende PS-Datei wohin, wo sie eigentlich nach meinem Wissen gar nicht hin sollte (direkt ins Spool-Verzeichnis und nicht in CUPS' $TempDir)

* Dann wird die PDF-Datei nicht an stdin beim pdf-Backend von Adobe abgeliefert (was Adobe den schwarzen Peter zuschieben würde, sich um den weiteren Ablauf inkl. passender Permissions, etc. zu kümmern) sondern als zus. Dateiargument

* Das Adobe-Backend prüft seinerseits nicht die Berechtigungen der temporären Datei und fällt auf die Nase

Quark könnte das [b]einen Neustart überdauernd fixen, indem sie so ein StartupItem, wie hier im Thread schon von mir aufgemalt, ins Spiel bringen würden.

Oder sie würden ein Mini-CUPS-Backend ins Spiel bringen, das von der reinen Funktionalität her wirklich nur eine Zeile Code enthalten müsste:

Code

if [ $# -ge 5 ]; then cat "$6" | "$(dirname "$0")"/pdf800 "$1" "$2" "$3" "$4" "$5" && rm "$6"; fi 

und schon würde das Permission-Problem nur noch alleine Sache von Adobe bzw. gelöst sein, weil besagte seltsame Konstellation gar nicht mehr auftreten könnte...

Oder Adobe würde innerhalb ihres pdf/pdf800-Backends vorher einfach prüfen, ob ein übergebenes Spoolfile überhaupt die für ihre eigenen Weiterverarbeitungs-Mechanismen nötigen Berechtigungen aufweist und diese dann halt in Herrgottsnamen ebenfalls vorher korrigieren. Das ist doch alles keine Hexerei sondern eigentlich nur ein Klacks.

Obiger Einzeiler könnte natürlich leicht modifiziert auch aus meinem Backend aus als Postprocessing-Mechanismus aufgerufen werden. Würde dann vermutlich auch einen Workaround für das Problem mit dem nicht funktionierenden Standardweg, PDF aus dem Druckdialog per Distiller zu erstellen, darstellen.

Wie auch immer... ich denk mal drüber nach und bin gespannt, ob Dave von Quark sich diesbzgl. äußert (hab im US-Forum mal nachgefragt)

Gruss,

Thomas

Hi Thomas,

besten Dank für die ausführliche Antwort.

Antwort auf [ Thomas Kaiser ]

Was Du offensichtlich willst, ist schlichtweg Adobes PDF-Erstellung in funktionierend, oder?

Bingo. :-)

Ich find's halt besch..., dass man nun 'neue' Workflows aufbauen muss, nur weils wohl an einer fehlenden Code-Zeile scheitert. Nichts gegen Neuerungen - aber dann bitte produktive!

Und, nein der PDF-Export aus QXP ist nicht schlechter - nur sollte man trotzdem die Wahl haben.

Gruß
Bernhard

Hi Bernhard,

Antwort auf [ Bernhard Werner ]

Antwort auf [ Thomas Kaiser ]

Was Du offensichtlich willst, ist schlichtweg Adobes PDF-Erstellung in funktionierend, oder?

Bingo. :-)

OK, dann Hausaufgaben für Quark Inc., zweiter Teil (nach dem StartupItem, das sie auch nur 1:1 übernehmen müssten).

Code

#!/bin/sh 
GUIUser=`ps acx -o command,logname | grep loginwindow | awk -F" " '{print $2}'` 
 
if [ "X${GUIUser}" = "X" ]; then 
        GUIUser=lp 
fi 
 
case $# in 
        0) 
                echo "direct $(basename "$0") \"Unknown\" \"Adobe PDF 8.0 fixed\"" 
                echo "direct $(basename "$0")://distiller \"Adobe PDF 8.0 fixed\" \"Adobe PDF 8.0 fixed\"" 
                ;; 
        5) 
                exec su ${GUIUser} -c cat | "$(dirname "$0")"/pdf800 "$1" "$2" "$3" "$4" "$5" 
                ;; 
        6) 
                exec su ${GUIUser} -c cat "$6" | "$(dirname "$0")/pdf800" "$1" "$2" "$3" "$4" "$5" && rm "$6" 
                ;; 
esac 

Als /usr/libexec/cups/backend/pdf800-fixed abspeichern, analog zu Beitrag von gestern abend per chmod auf ausführbar setzen und anschl. ein killall -SIGHUP cupsd hinterher. Im Druckerdienstprogramm auf "Hinzufügen" klicksen, "Adobe PDF 8.0 fixed" auswählen, dazu Adobes-Distiller-PPD bzw. besser generell Impressed' modifizierte Distiller-PPD nehmen, fertig?

Gruss,

Thomas

Hallo Herr Kaiser,

das neue "fixende" Backend funktioniert wunderbar.
Vielen Dank für Ihre Mühe.

Hallo,

Antwort auf [ Robert Zacherl ]

das neue "fixende" Backend funktioniert wunderbar.

Naja, daß die Variante funktionieren muß ist ja klar. CUPS funktioniert halt nunmal so schrecklich simpel

Elegant war der vorherige Ansatz trotzdem nicht sondern eher Untermauerung der vorher von mir postulierten Wirksamkeit des "Einzeiler"-Ansatzes.

Antwort auf:

Vielen Dank für Ihre Mühe.

Kein Problem. Betatester Bernhard Werner hat einen universellen Installer (mit einem ebenso universellen Backend bzw. dreien) vor paar Minuten erhalten, der einerseits die PDF-Generierung effizienter mittels des Distiller-Backends abwickelt (macht sich gerade bei fetten Druckjobs doch zeitlich deutlich bemerkbar) und selbständig erkennt, für welche Distiller-Versionen er seine Heilkräfte ins Spiel bringen soll (also mit Distiller 6 - 8.1 funktioniert).

Ich warte nun auf Berhards Feedback und auf Rechnungsadresse von Quark D, denn ein Manntag Consulting, Analyse und Entwicklung sollten da schon drin sein

Dafür gibt's das dann gleich als fertiger Apple-Installer nebst Uninstaller, etc. ... Was sagt denn Matthias Günther dazu? Die offiziellen Quarkler lesen doch auch mit, oder?

Vielleicht geht das aber auch alles zu schnell und das Problem muß noch paar Monate zwischen Quark, Adobe und Apple hin- und hergeschoben werden *g*

Gruss,

Thomas

Hallo zusammen,

habe auch das Problem, dass beim Drucken über den Adobe PDF-Writer keine PDF-Datei erstellt wird.

Gibt es da zwischenzeitlich schon eine perfekte Lösung. Export über Quark kommt nicht in Frage, muss schon den Umweg über den Distiller sein.

Vielen Dank für Eure Hilfe.

Bonsai24