ich habe das Problem, nicht aus Quark drucken zu können. Arbeite mit Mac OS X Intel, Quark 7. Aus allen möglichen Programmen kann man auf dem Drucker (Kyocera FS1118) drucken, nur aus Quark nicht. Auch ein Update auf 7.02 hat nichts gebracht. Der Drucker liest die Daten ein, dann verschwindet der Job aus dem Druckerfenster und es passiert nichts. Kann es an irgendwelchen Einstellungen im Farbmanagement liegen? Teilweise funktionierten nämlich Ausdrucke von nur-Text-Seiten, sobald ein Bild auf der Seite ist, werden nur kryptische Zeichen gedruckt.
Auch das Schreiben von PDF´s funktioniert nicht, PDF´s kann ich nur über "Ablage-Export-Layout als PDF" erstellen. Wenn ich eine Datei über das Druckerfenster mit Adobe PDF erstellen möchte, passiert folgendes: Apfel+P, Drucken... Adobe PDF auswählen, dann möchte ich PDF-Optionen auswählen, da steht aber nur ein durchgestrichener Adobe... Was hat sowas zu bedeuten?
Ich habe schon alle möglichen Threads durchgelesen, eine Lösung aber nicht gefunden. Bin auch nur Anwender und habe keine Hintergrund-IT-Kenntnisse. Bin am verzweifeln...
Danke für einen Tipp ________________________________________
Kann es vielleicht sein, dass eine "falsche" Einstellung des Bildschirmprofils der Auslöser ist? -> unter QuarkXPress - Einstellungen... - Programm-Anzeigen - Bildschirmprofil. Da habe ich "QuarkXPress Legacy RGB" ausgewählt, da bei dieser Einstellung die Farben im Dokument richtig dargestellt werden, bei anderen Einstellungen war z. B. ein blau eher lila. Kann so eine Einstellung das Drucken irgendwie "verhindern"? Aber habe auch schon alle möglichen durch... ________________________________________
Nicht wirklich. Dieses "Phänomen" habe ich erst seit 7.02 --> siehe anderer Thread. Schau Dir mal die Lösungshilfen dort an, vielleicht kannst Du so das Problem eingrenzen.
Schöne Grüße Manfred ---------------------------------------------------------------------------------------- iMac intel | OS X 10.10+10.11.3.x | Quark Xpress 9.5 | Adobe CS 6 | Acrobat X
(Dieser Beitrag wurde von embela am 12. Okt 2006, 08:20 geändert)
das Phänomen gibt es exakter gesagt seit 7.01 --> siehe zahlreiche andere Threads... Ein Lösung gibts es zumeist nur durch andere PPDs bzw. das Arbeiten mit einem PPD-losen Drucker (allg. Postscript).
Für den AdobePDF-Drucker z.B. gibt es keine Lösung und der Steinzeitrückschritt über die PS-Dateierzeugung ärgert zumindest viele meiner Support-Kunden.
Schönen Gruß Jürgen ------ Mues+Schrewe GmbH Agentur für Kommunikation • www.mues-schrewe.de
... weil ich Quark von Beginn an einsetze und Quark noch nie (wenige Programmversionen in der Druckausgabe ausgenommen) Postscript richtig im Griff hatte, geschweige denn die Exportfunktion. Sieht man in diesem Fall ja auch: Wenn die Druckausgabe nicht korrekt funktioniert mit Standardfunktionen (den AdobePDF-Drucker sehe ich als "Standard") ist es wohl nur verständlich, dass ich der Exportfunktion überhaupt kein Stück traue... In 6.5 waren die PDFs "nicht optimal" über den Exportweg. Ich verlasse mich nicht auf Quarkaussagen nach dem Motto "Der PDF-Export ist jetzt ganz toll" und gehe lieber den sicheren und etablierten Weg über den Distiller. Zudem kann ich z.B. keine benutzerdefinierten Seitenformate angeben (+10mm rundum und dann zentriert setzen).
Ich nehme das aber mal zum Anlass, die Exportfunktion mal genauer wieder zu testen.
Schönen Gruß Jürgen Mues ------ Mues+Schrewe GmbH Agentur für Kommunikation • www.mues-schrewe.de
schon seit XPress 6.5 ist der "PDF-Export als PS-Datei" bei geladener PDFBoxerXT von Quark der bessere und sicherere Weg, eine PS-Datei für den Distiller herzustellen – außer sie setzen die XTensions MediaBoxXT von www.Jolauterbach oder MadeToPrint von axaio ein. Nur dann wird für den Distiller optimierter PS-Code geschrieben. Nur dann steht der Seiteninhalt exakt auf der Seite und nicht bis zu 1 Punkt in Höhe oder Seite verschoben.
In den dann benutzten Distiller-Settings darf keinesfalls ein Haken bei "Erweitert > Überschreiben der Adobe PDF-Einstellungen" gesetzt sein.
Weitere Infos zum PDF-Export in den Rezepten von PDFX-ready unter http://www.pdfx-ready.com/index.php?show=390
Diese Settings als Ausgangspunkt nehmen und eventuell leicht abwandeln
... meines Wissens gibt es nur unzufriedenstellende Lösungen: 1) PPD des Druckers rausnehmen und mit der Standard-Postscript PPD arbeiten 2) evtl. funktioniert: PS-Datei schreiben und den Job manuell auf das Druckersymbol schieben? 3) PDF erstellen und dieses Drucken.
Schönen Gruß Jürgen ------ Mues+Schrewe GmbH Agentur für Kommunikation • www.mues-schrewe.de
hast du mal mit den kodierungen gespielt? ich denke, die gibt es in xpress7 auch noch (ich hab gerade keines vor mir). in xpress<7 im druckdialog unter optionen/bilder/daten/ zu finden: binär, ascii, clean-8-bit.
gruss. gremlin "geht nicht" ist keine problembeschreibung...
ja, das habe ich auch schon hinter mir. Bei allen drei Möglichkeiten (ASCII, binär, Clean-8-Bit) kein Unterschied. Er druckt einfach NICHTS. Auch wenn ich alle Bilder lösche, es wird gar nichts mehr gedruckt.
Habe den Drucker schon neu angelegt, einmal als "Drucken mit:" PostScript Drucker und einmal als "Drucken mit:" Kyocera FS-118MFP (KPDL), was ja der korrekte Drucker sein müsste. Wenn ich dann aus Quark auf dem PostScrip Drucker drucken will, verschwindet der Job nun nicht mehr aus dem Druckerfenster (wow, welcher Fortschritt :), sondern es kommt dann die Fehlermeldung "Network host ´192.167.1.251´ is busy; will retry in 30 seconds". Es passiert dann gar nichts mehr, die Meldung bleibt stehen. Wenn ich auf dem anderen neu angelegten Drucker drucken will, verschwindet der Job aus dem Druckerfenster und es passiert nichts.
Danke fürs Grübeln... Katrin ________________________________________
also plötzlich passiert folgendes: wenn ich über ablage exportieren als pdf gehe, entsteht eine .ps-datei, also eine postscript-datei, die speichere ich auf dem desktop, ziehe sie in das druckerfenster und der drucker läuft kurz an, druckt aber nichts. dann verschwindet der job wieder aus dem druckerfenster. aber abgesehen jetzt mal von dem druckerproblem, normal ist ja auch nicht, dass er über das exportieren jetzt keine pdf mehr erstellt sondern ps-dateien. heute morgen ging das noch mit pdf über exportieren ganz normal. vllt. sollte ich besser aufhören hier, bevor gleich gar nichts mehr geht...
distillieren, also pdf schreiben? funktioniert auch nicht, beschreibung des problems siehe mein eröffnungs-thread. ________________________________________
kommando zurück, das mit eportieren als pdf funktioniert doch wieder ganz normal. also das ist der einige weg für mich, eine pdf zu erstellen. über apfel+p, drucker, adope pdf 7.0 geht nicht. (siehe eröffnungs-thread). ________________________________________
wie hast Du denn unter Einstellungen > Programm > PDF den PDF-Workflow konfiguriert? Soll Dein XPress 7 direkt ein PDF erzeugen oder hast Du das Programm auf "optimale PS-Erzeugung für Distiller" (ich habe die 2. Option mal in Deutsch übersetzt) gestellt?
ich habe jetzt wieder die Einstellung "direkt als pdf". jetzt funktioniert das exportieren als pdf ja auch wieder. da hatte ich vorhin die andere option, da kamen dann die ps-dateien her. hatte ich vorher noch nie drauf geachtet, was da für eine einstellung drin war. aber das geht jetzt wieder eine pdf auf diesem weg zu erstellen.
mein problem ist eher das mit dem drucken...
gruß Katrin ________________________________________
Es wird wohl so sein, dass in der ppd des PS Clones sein eigenes Postscript erklärt ist. Das versteht dann Quark wohl falsch und schickt falsches PS zum Drucker. Der macht einen Fehler, den er nicht ausgibt, da dies ja immer im Windowstreiber ausgeschalten wird. Der selbe Fehler wird auch beim PS erzeugen dazu führen, dass Akrobat damit nu nix anzufangen weiss. Hier müsste die Fehlermeldung aber im log stehen. Hilft wohl nur pdf exportieren und dann wo anderst ausdrucken.
Oder neuen Drucker kaufen. Mit richtig Postscript
Schönen Gruss mac mini, imac, Macbook im Büro und Verlag dazu jede Menge Zeuchs
dann erstellt der mir fein säuberlich eine pdf. ganz normal. Wenn ich aber eine PDF über das Druckerfenster mit Adobe PDF erstellen möchte, passiert folgendes: Apfel+P, Drucken... Adobe PDF auswählen, dann möchte ich PDF-Optionen auswählen (z. B. "Kleinste Dateigröße"), das kann ich aber nicht auswählen, dort steht nur "AdobePDFPDE700" und zwar durchgestrichen.
Aber das kann doch nichts damit zu tun haben, dass ich auf dem Kyocera-Drucker nichts drucken kann.
das hier:
das kapier ich nicht so recht. zumal es ja mal funktionierte, aus Quark auf diesem Kyocera zu drucken. ist ja nicht so, als ob es nie gegangen hätte, daher weigere ich mich ein bisschen, die situation so hinzunehmen...
danke an alle! katrin ________________________________________
Wir haben genau das gleiche Problem Aber erst seit 7.02. Es gibt auch noch einen anderen Bug das habe ich hier schon in einem anderem Thema geschrieben. Quark hat es bestätigt.
PDF schreiben geht aber das Drucken auf unserem Fiery geht nicht mehr. Der job verschwindet!
Wenn wir aber den Tipp aufgreifen im Drucker Dienstprogramm den Fiery als Standard Postr. zu nehmen kommt der Druck raus. Auch wenn wir im Quark Druckmenü die PPD für den Fiery auswählen.
(Dieser Beitrag wurde von Pippalu am 12. Okt 2006, 14:20 geändert)
du meinst damit, dass du das export-ps distillierst, oder?
dass xpress 7.01+7.02 offenbar nicht mit dem adobe-pdf-drucker klar kommt bzw. dessen pdf-optionen nicht freigibt, wurde bereits als definitiver bug festgehalten. darüber muss man wohl derzeit nicht mehr diskutieren.
was ich mich aber noch immer zu glauben weigere, ist, dass es nicht möglich ist, halt statt pdf-optionen zu wählen den druck in datei umzuleiten und so ein ps-file zu erhalten.
das brauchst du auch nicht zu kapieren, denn es ist ziemlich wirres gerede ;-) was die grundaussage eigentlich wäre: mit einem klon-ps-interpreter im drucker (also nicht original adobe cpsi) läuft man immer das risiko, dass ein ps-erzeuger-programm eine absolut standardkonforme formulierung benutzt, die diese "billigen kopien" nicht verstehen. ganz salopp ausgedrückt ;-) dann wird ein bugfix seitens psi-hersteller fällig. schönes beispiel hatte man damals beim xpress-6.5-update und gewissen nicht brandaktuellen jaws/global graphics-interpretern.
ob bei deinem problem sowas der fall ist, ist meiner ansicht nach noch nicht raus. deshalb grübeln wir ja.
bitte nimm mal sämtliche druckeinstellungen so vor, als würdest du auf deinen kyocera drucken. dann leite aber die ausgabe in datei um und distilliere diese.
gruss. gremlin "geht nicht" ist keine problembeschreibung...
Hallo Katrin, ich habe hier die Antwort aus dem anderen Thread hiernochmals eingefügt und weiter kommentiert:
A) An der Stelle, wo die PDF-Datei entstehen soll, befindet sich schon eine PDF-Datei gleichen Namens. Ich drucke "in den Drucker Adobe PDF 7.0". Die vorher bestehende PDF-Datei wird gelöscht. Ich meine zu wissen: das bedeutet, dass die PS-Datei von XPress 7 geschrieben wurde und die PDF-Library vom Distiller die Arbeit aufgenommen hat und zur Konvertierung die bestehende PDF-Datei gelöscht hat. Aber eben kein neue erzeugt hat. (Also wahrscheinlich Fehler in der Verarbeitung der PS-Datei durch die Distiller-Library. Grund könnte sein, dass PostScript-Befehle von der Library des Distillers nicht richtig verarbeitet werden können. Grund könnte auch sein, dass "Quark an MacOS X-Befehle zum Starten der Distiller-Library" nicht richtig weiter gegeben werden.)
B) Ich drucke "in den VirtualPrinter" (also "in PS-Datei") von Dave Uhlmann (kostenlos – www.werkflow.ch), in den die Acrobat 7 PPD eingebunden ist. Es wird eine PS-Datei erzeugt, die dann problemlos vom Distiller verarbeitet werden kann. (Das ist der Druckdialog. Apfel+P. Der Fehler kann also nicht in der Adobe PDF-PPD sein. Der von XPress erzeugte PostScript-Code kann also direkt vom Distiller verarbeitet werden.)
C) Wähle ich die Verzweigung zum PDF von OS X, wird ein OS X-PDF erzeugt. (Druckdialog. Apfel+P. Hier spielt keine Adobe-Komponente mit.)
D) Mit installierter MediaBoxXT von JoLauterbach und hinterlegter Adobe PDF-PPD drucke ich in PS-Datei (in der MediaBox ist auch ein Optionenknopf für sofortiges Distillieren), und erhalte wieder direkt ein gutes PDF. (Druckdialog. Apfel+P. Beteiligt sind wieder die Adobe PDF-PPD und der Distiller. Wenn XPress also direkt PostScript für den Distiller schreibt, ist der PostScript-Code ok)
Der PDF- oder PS-Export funktioniert bekanntermaßen.
Nun zum Kyocera-Drucker. Nach den Meldungen, die Du bisher erlebt hast, kann auch hier sein, dass "Quark an Mac OS X an Kyocera" nicht richtig übergeben wird.
bitte nimm mal sämtliche druckeinstellungen so vor, als würdest du auf deinen kyocera drucken. dann leite aber die ausgabe in datei um und distilliere diese.
das mit den druckeinstellungen ist klar, aber wie geht "leite die ausgabe in datei um"? wie macht man das? ________________________________________
also das hab ich gemacht, hat funktioniert. die ps-Datei hab ich auf den distiller geschmissen und er hat mir dann eine einwandfreie pdf-datei erstellt.
aber das ist ja nicht das problem, das prob. ist, dass ich eben auf dem kyocera drucker nicht ausdrucken kann. ich kann einfach nicht glauben, dass es keine möglichkeit gibt, aus quark auf diesem drucker zu drucken. auf einem epson stylus color 740, den ich auch noch hier stehn hab, kann ich ja drucken. nur eben auf diesem kyocera FS-1118MFP nicht. :((
es ist etwas schwierig, in diesem thread die übersicht zu behalten. es werden verschiedene problem durcheinander behandelt, neue eingebracht und widersprüchliche aussagen gemacht. deshalb versuche ich, etwas strukturiert an das problem ranzukommen.
was haben wir nun mit dem versuch "kyocera-druckdatei distillieren" erreicht? wir wissen, dass das problem nicht fehlerhafter postscript-code ist. ein original adobe cpsi (distiller) verarbeitet ihn anstandslos. das "produkt" von xpress ist einwandfrei.
was geschieht, wenn du dieselbe ps-datei (ich hoffe, du hast sie noch nicht ins nirwana geschickt ;-)) auf das druckerfenster des kyocera ziehst?
gruss. gremlin "geht nicht" ist keine problembeschreibung...
(Dieser Beitrag wurde von gremlin am 12. Okt 2006, 16:09 geändert)
was geschieht, wenn du dieselbe ps-datei (ich hoffe, du hast sie noch nicht ins nirwana geschickt ;-)) auf das druckerfenster des kyocera ziehst?
hi, doch ich hatte sie schon gelöscht, aber ist ja kein ding, sie neu zu erstellen. also die datei druckt der drucker einwandfrei, wenn ich sie in das fenster ziehe. versteh ich nicht. wieso druckt er die und nicht aus quark direkt??? ________________________________________
das sagt aus meiner Sicht aus, dass die Kommunikation XPress 7.02 - Mac OS X - Kyocera nicht funktioniert, denn der PostScript Code von Xpress ist ja in Ordnung.
... die Kommunikation XPress 7.02 - Mac OS X - Kyocera ...
ich würde sogar mal sagen, das darf man auf "xpress 7.02 - mac os X" reduzieren, nicht? "mac os X - kyocera" geht ja (druckerfenster-test). allerdings bin ich nun ratlos, was man da unternehmen könnte... :-( gibt es irgendwelche druckertreiber-cups-was-weiss-ich-präferenzen im system, die man probeweise mal entfernen könnte?
gruss. gremlin "geht nicht" ist keine problembeschreibung...
... die Kommunikation XPress 7.02 - Mac OS X - Kyocera ...
ich würde sogar mal sagen, das darf man auf "xpress 7.02 - mac os X" reduzieren, nicht? "mac os X - kyocera" geht ja (druckerfenster-test). allerdings bin ich nun ratlos, was man da unternehmen könnte... :-( gibt es irgendwelche druckertreiber-cups-was-weiss-ich-präferenzen im system, die man probeweise mal entfernen könnte?
Schau doch bitte mal in den anderen Thread, wo diese "Cups-Sache" geändert wurde. Wenn es denn das gleiche Problem ist.
Schöne Grüße Manfred ---------------------------------------------------------------------------------------- iMac intel | OS X 10.10+10.11.3.x | Quark Xpress 9.5 | Adobe CS 6 | Acrobat X
(Dieser Beitrag wurde von embela am 12. Okt 2006, 18:04 geändert)
auch in Katrins Fall ist wieder ein von Kyocera eingesetzter CUPS-Filter die Fehlerursache. Es scheint also so zu sein, dass QuarkXPress 7.02 ein Problem beinhaltet, welches die korrekte Ausführung dieser Filter verhindert. Filter sind ausführbare Programme und dienen normalerweise dazu den an CUPS übegebenen PostScript-Code in die jeweilige Drucker-Steuersprache zu übersetzen. Da die betroffenen Geräte aber eh alles PostScript-Ausgabegerät sind, gibt es da eigentlich nichts mehr zu übersetzen. Deswegen ist die Ausführung der Filter eigentlich nicht zwingend erforderlich (ohne Gewähr!).
Wie schon im Fall des Fiery-Druckers ist auch hier das Problem dadurch lösbar, dass man der Drucker-Instanz im Drucker-Dienstprogramm von Mac OS X eine modifizierte PPD-Datei zuweiset, in welcher der Aufruf des CUPS-Filters entfernt wurde.
Dazu muss im PPD eine Zeile gesucht werden die mit *cupsFilter: "application/vnd.cups ... beginnt. Diese modifiziert man indem man hinter dem führenden "*" ein "%" einfügt und damit die ganze Zeile zum Kommentar macht: *%cupsFilter: "application/vnd.cups ...
Diese PPD-Version speichert man (am besten unter einem modifizierten Namen um sie später noch vom Original unterscheiden zu können) und weist sie im Drucker-Dienstprogramm per Schaltfläche "Informationen", Popup-Menü "Druckermodell" und "Andere..." der betroffenen Drucker-Instanz zu.
Dieses Vorgehen löst NICHT das "Adobe PDF 7.0" Problem, da dieses gänzlich anders geartet ist.
....Dieses Vorgehen löst NICHT das "Adobe PDF 7.0" Problem, da dieses gänzlich anders geartet ist.
Haben Sie schon eine Ahnung, was hier das eigentliche Problem ist. Ich habe langsam den Eindruck Quark weis selber noch nicht, warum der Drucker "Adobe PDF 7.0" nicht mit 7.01 und 7.02 funktioniert.
ich habe nun herausgefunden warum der Druck über "Adobe PDF" aus QuarkXPress 7.0x heraus nicht funktioniert. QuarkXPress ruft beim Druck über "Adobe PDF" das "pdf700" (und natürlich auch das "pdf800") CUPS Backend mit 6 anstelle der ansonsten meist gebräuchlichen 5 Parameter auf. Der sechste Parameter ist dabei der Pfad der temporären Datei, die die zu konvertierenden PostScript-Daten beinhaltet. Quark hat sich dabei für den Pfad
/private/var/spool/cups
entschieden. Unglücklicherweise sind die Standard-Zugriffsrechte auf dieses Verzeichnis recht restriktiv (710) und ganz offensichtlich zu restriktiv als dass die Acrobat Distiller Library ihrem Job nachkommen könnte, was zum Scheitern der PDF-Erzeugung führt. Gott sei Dank ist das Problem aber, nachdem es erkannt ist, leicht lösbar. Man passt einfach die Zugriffrechte des obigen Ordners an. Durch Eingabe von
sudo chmod 755 /private/var/spool/cups
im Terminal und Eingabe des Administrator-Passworts werden die Zugriffsrechte so angepasst, dass nun der Distiller Zugriff auf die Daten bekommt und diese wie gewohnt konvertieren kann.
Ich denke, dass diese Änderung der Zugriffsrechte auf diesen Ordner keine nachteilige Auswirkung auf andere Prozesse mit sich bringt. Und selbst wenn, dann sind sie schnell wieder auf den ursprünglichen Wert von 710 zurückgesetzt.
sensationell! ich erlaube mir dreist, ein fettes dankeschön im namen der hds-community auszusprechen. ich hoffe, quark weiss ihren einsatz, deren probleme zu lösen, ansprechend zu würdigen...
gruss. gremlin "geht nicht" ist keine problembeschreibung...
Ich hatte am Wochenende Gelegenheit, mir im Kino das neueste Pixar-Wunder »Cars« ansehen zu dürfen. Wenn man sich mal vorstellt, was dabei wohl für Probleme gelöst werden mussten, die sich während der Umsetzung einer solch phantastischen Produktion auftaten, kommen einem die QXP-Probleme für kurze Zeit ziemlich mickrig vor. Insbesondere nach dem grandiosen Debugging durch Robert Zacherl.
Danke, Robert, das hat Pixar-Klasse!
gruss xpressio
Phantasie ist wichtiger als Wissen, denn Wissen ist begrenzt. Albert Einstein
vielen Dank für Ihre Hilfe zum Thema Drucken mit Quark 7. Dank Ihrer Hilfe kann ich jetzt auf unseren Farbdrucker wieder ausdrucken. Nur Ihre Beschreibung der Lösung zum PDF-Erstellen kann ich leider nicht genau nachvollziehen. Was muß ich wo eingeben? Entschuldigen Sie meine Unkenntnis von den genauen systemtechnischen Zusammenhänge....
einfach genau das machen, was robert zacherl geschrieben hat ;-)
programm "terminal" starten (zu finden in programme/dienstprogramme/), die zeile "sudo chmod 755 /private/var/spool/cups" (ohne anführung) eingeben, return, gefragtes admin-passwort eingeben, fertig.
aber man sollte sich schon bewusst sein, WAS man da macht...
gruss. gremlin "geht nicht" ist keine problembeschreibung...
auch von meiner seite ein ganz herzliches DANKESCHÖN!. ich konnte bisher keine drucke aus dem neuen quark aus meiner dc 12 xerox verbunden mit dem splash rip drucken. mit ihrer hilfe konnte ich das problem sehr schnell lösen.
erstmals danke ich ihnen für die ausführliche Beschreibung des Problems und dessen Lösung. Allerdings funktioniert diese Option (welche ja einmalig sein müsste) nur bis zum nächsten Neustart, weshalb ich mich bei unseren Grafikern jeden morgen als ADMIN einloggen muss, um ihnen die korrekten Berechtigung bzgl. des CUPS Ordners zu geben.
Gibt es auch eine fixe Lösung, welche nur einmalig durchgeführt werden muss?
das Mac OS X kontrolliert beim Start seine System-Bereiche auf korrekte Rechtevergabe. Ich habe bei mir ein Shell-Script eingerichtet, welche automatisch die Rechte des betroffenen Ordner zurechtbiegt.
Können sie mir den Inhalt des Shell-Scripts posten, oder per Mail zukommen lassen. Nur um in die einzelnen Schritte der Konfiguration einsehen zu können.
Wenn möglich, können sie mich unter mab@reichl.cc erreichen.
Diesen Text pasten Sie in eine Textdatei, speichern diese und machen Sie im Terminal ausführbar, indem Sie ein Terminalfenster öffnen, folgendes eintippen
chmod 710
(Leerzeichen hinter "710" nicht vergessen) und die Textdatei per Drag & Drop ins Terminal-Fenster ziehen.
Nun können Sie die ausführbare Scriptdatei in der Mac OS X Benutzerverwaltung als Startobjekt angeben.
Da ich nicht der Shell-Profi bin, kann es durchaus sein, dass es elegantere Lösungen gibt. Vom Sicherheitsaspekt her betrachtet ist die Lösung natürlich alles andere als optimal, weil in der Scriptdatei Ihr unverschlüsseltes Admin-Passwort steht.
kleine Ergänzung. Die oben angesprochene Script-Datei muss so gespeichert werden, dass sie automatisch im Terminal geöffnet wird. Am einfachsten öffnet man dazu deren Informationen-Fenster (Datei auswählen und APFEL + I drücken) und wählt die Terminal Applikation bei "Öffnen mit" aus.
in Beitrag Nr. 41 hier beschreibt Herr Zacherl ja die Vorgehensweise bei einer Laserdrucker-PPD.
Ich hatte bei einem Kunden einen ähnlichen Fall auf einem etwas älteren Ricoh-Farblaserdrucker. Einfache Seiten wurden aus XPress 7 gedruckt, etwas komplexere (wobei das überhaupt nicht komplex war) blieben im Drucker hängen. Ein per Distiller erstelltes PDF von den Seiten ließ sich problemlos aus Acrobat drucken.
Die installierte PPD war von 2002, die neueste auf der Ricoh-Homepage von 2004. Mit beiden war der Fehler reproduzierbar. Der von Herrn Zacherl beschriebene Eintrag war in der PPD nicht zu finden. Ich habe daraufhin im Druckendialog von XPress 7 die Ricoh-PPD durch die Adobe-PDF-PPD ersetzt. Das führte zum Erfolg. Nun kommen die Seiten genauso schnell aus dem Drucker, als wenn man aus Acrobat druckt. Auf Betriebssystemebene habe ich nichts verändert, d.h. da ist im Druckertreiber nach wie vor die Ricoh-PPD zugeordnet. Das macht ja auch Sinn, damit man die verschiedenen Optionen des Druckers beim Drucken anwählen kann. Für mich eine einfache und schnelle Lösung. Vielleicht hilft es dem einen oder anderen noch, wenn er auch nicht den Eintrag von Herrn Zacherl in seiner Drucker-PPD findet.
das sind aber zwei gänzlich unterschiedliche Probleme, die nichts miteinander zu tun haben. Wenn der "*cupsFilter:" Eintrag in der PPD vorhanden ist, dann kommt kein einziger Druckauftrag, egal ob einfach oder komplex, aus QuarkXPress 7.02 ausgegegeben aus dem Drucker, da die Übergabe der zu druckenden PostScript-Datei gestört ist.
das sind aber zwei gänzlich unterschiedliche Probleme, die nichts miteinander zu tun haben.
Ok, danke für die Info. Vielleicht lag es dann auch am Drucker bzw. dessen RIP. Dafür war die Zeit beim Kunden zu kurz, um da tiefer vorzudringen zu können. Hätten Sie aus der Ferne dafür eine Erklärung, warum die Ricoh-PPD im Drucken-Dialog den Prozess so stark ausbremst bzw. blockiert, wobei die Adobe-PDF-PPD den Job problemlos und schnell ausgibt? Der Kunde hatte einen Intel mit 10.4.8 und XPress 7.02.
Erst einmal vielen Dank für diese tollen Lösungen. Aber wie das so ist, gibt es prompt neue Probleme. Nach dem PPD-Hack vervielfältigt sich hin und wieder (d.h. nicht immer!) ein Druckjob. Meint: Ich schicke 80 Seite A4 los und der gleiche Job rechnet sich andauernd wieder in die Warteschlange. Ohne Fehlermeldung etc.
Kennt jemand das Problem? Kann mir jemand einen Tipp geben?
Wir drucken auf: Linium 450C gesteuert über eine Fiery X3eTY_794F Die PPD heißt: "Fiery X3eTY 35C-KM PS v1.0 eu"
es ist bekannt, das bei manchen Druckern die Anzahl der ausgedruckten Kopien nicht korrekt gehandhabt wird, wenn die geforderte Anzahl ungleich 1 ist. Der Effekt bei manchen Xerox-Druckern ist dann z.B., dass die eingegebene Anzahl von Kopien im Quadrat ausgegeben wird (aus 5 Kopien weren also 5x5=25). Bei einer Kopie ist mir ein solches Problem aber noch nicht zu Ohren gekommen.
Aber hängt das nun mit Quark zusammen (Lösung: Quark-Support kontaktieren) oder ist das ein Problem der PPD bzw. des Druckers (Lösung: Drucker-Support kontaktieren)?
es ist ein Seiteneffekt der Entfernung des CUPS Filters aus dem Ausgabeprozess durch den notwendigen Eingriff in die PPD-Datei (um überhaupt drucken zu können). Sobald Quark das grundsätzliche CUPS Filter-Problem gelöst hat und wieder die originale Geräte PPD-Datei (mit aktivem *cuspFilter: Eintrag) zum Einsatz kommen kann, sollte das Problem gelöst sein.
an dieser Stelle, auch wenn etwas weiter unten im Text, vielen Dank für Ihren Lösungsansatz. Funktioniert!!!! :-) Wir arbeiten mit einem Bizhub C352 von Minolta und haben seit kurzem Intel Macs und Quark 7.02...
Allerdings hat sich bei uns ein weiteres Problem aufgetan. Wir arbeiten mit EPSON 4800 und 7800 Proofs und dem Programm EFI Colorproof XF zusammen. In Verbindung mit Quark 7 tut sich hier das Problem auf, dass wir über das Drucker-Menü -> Drucker... keine Verbindung (Auswahl des Workflows) zu unserem RIP (also zum o.g. Programm) aufbauen können, was in Quark 6.5 ohne Probleme funktioniert. Die dazugehörige PPD enthält keine cupsFilter! Lösungsansatz? Sie sind hierzu im Kommentar #58 kurz darauf eingegangen.
heißt dass, das die betroffenen Drucker/Queues gar nicht in dem Auswahl-Dialog von QuarkXPress 7 angeboten werden, oder dass der Druck als solches gestört ist? Wenn letzteres der Fall ist, was sagt dann die Mac OS X Konsole dazu? Schicken Sie einen Druckauftrag los und schauen Sie in der Konsole im Abschnitt /var/log/cups/ welche Meldungen im error.log auftauchen.
der Drucker ist nicht gestört, die Queues stehen nicht zur Auswahl, d.h. sind im Pop-Up Menü nicht vorhanden. In Quark 6.5 ist dies überhaupt kein Problem. Die Verbindung zum genannten Drucker und den Queues kann ohne Probleme aufgebaut werden......
das ist aber sehr ungewöhnlich, da es sich hierbai ja eigentlich um eine Betriebssystem-Funktion handelt. Beinhalten die Queuenamen denn irgendwelche Sonderzeichen? Welches Protokoll (PAP, TCP/IP, ...) verwenden Sie um die Queues anzusteuern?
Ja in der tat... Nein, die Queuenamen entahlten keinerlei Sonderzeichen, aber Leerzeichen. Der Drucker wurde als TCP/IP Drucker im Drucker-Dienstprogramm angelegt, folglich müsste das Protokoll TCP/IP sein. Vorallem spricht die Tatsache, dass es in Quark 6.5 funktioniert, nicht gerade für Quark 7...
Diesen Text pasten Sie in eine Textdatei, speichern diese und machen Sie im Terminal ausführbar, indem Sie ein Terminalfenster öffnen, folgendes eintippen
chmod 710
(Leerzeichen hinter "710" nicht vergessen) und die Textdatei per Drag & Drop ins Terminal-Fenster ziehen.
Nun können Sie die ausführbare Scriptdatei in der Mac OS X Benutzerverwaltung als Startobjekt angeben.
Hallo Herr Zacherl,
nach einigem Hin und Her habe ich ein sicheres Skript für diesen Workaround entwickelt, der ohne Terminal etc. auskommt - in dem Wissen, dass Ihr Ansatz derzeit das einzig wahre Debug ist; dazu muss man einfach einen neuen Schlüssel "Manfred" im Schlüsselbund mit admin-Nutzer und admin-passwort anlegen. Anschließend folgendes Skript als ausführbares Programm speichern und in Systemeinstellungen->Benutzer->Startobjekte definieren. (Beim ersten Neustart fragt Schlüsselbund mehrmals um Erlaubnis, danach ist OK.)
Das Skript also lautet (bis auf Manfred – Manfred durch eigenen Dateinamen im Schlüsselbund ersetzen): tell application "Keychain Scripting" set theKey to first key of current keychain ¬ whose name is "Manfred" set theUser to account of theKey set thePassword to password of theKey end tell do shell script ¬ "chmod 711 /private/var/spool/cups" user name theUser password thePassword ¬ with administrator privileges
habe mich mal ein Weilchen mit dem Problem beschäftigt, wir haben nämlich das gleiche Problem bei uns auf Arbeit auch.......gehabt!
Deshalb habe ich mit Hilfe von den Code-Zeilen von Herrn Zacherl ein kleines Programm gebastelt, welches das Script automatisch ausführt, sobald man es startet (ist natürlich nach jedem Neustart auszuführen).
Bitte achtet darauf, dass euer Benutzer-Account kein Kennwort besitzen darf, damit das Tool funktioniert... zur Not müsst Ihr es während der Arbeit mit Quark zeitweise entfernen...
Ob es auch mit Kennwort funktioniert weiss ich nicht - wenn dann probiert es einfach aus!
hallo herr zacherl! anscheinend sind sie hier die quelle aller erkenntnis!
ich klink mich da mal mit ein paar ähnlichen problemen ein! ich hoff das passt so, da ich das erste mal in so einem forum bin!
zunächst habe ich schon probiert diese cups geschichte, leider ist bei meiner ppd diese gar nicht zu finden. (fiery Fiery X3e 31C-M PS v2.0 eu) ausdrucken möchte ich auf einem minolta CF 2002
aber leider kommt nichts nur mit der allgemeinen ppd (Im druckerdienstprogramm) und da sind dann die ganzen druckeroptionen nicht verfügbar!
selbes problem mit ADOBE PDF im druckdialog sind die pdf optionen durchgestrichen!
da ich als anwender arbeite habe ich nur mangelhafte erfahrung mit dem ganzen shell zeugs gibts da mittlerweile eine einfachere lösung!?
(PS (den fiery CUPS uodater hab ich auch schon probiert (ohne erfolg
im druckdialog sind die pdf optionen durchgestrichen!
"durchgestrichen" heisst normalerweise, dass Mac OS X den CUPS-Filter als nicht kompatibel einstuft, das passiert meistens, wenn dieser nur Laserwriter8-kompatibel ist und nicht (auch) die Filepath-Methode unterstützt, die gerade bei Intel-nativen Programmen notwendig geworden ist (und schon länger von Apple empfohlen wird).
Daher: Zuerst die neuesten CUPS Filter installieren.
(fiery Fiery X3e 31C-M PS v2.0 eu) PS (den fiery CUPS uodater hab ich auch schon probiert (ohne erfolg
"durchgestrichen" heisst normalerweise, dass Mac OS X den CUPS-Filter als nicht kompatibel einstuft, das passiert meistens, wenn dieser nur Laserwriter8-kompatibel ist und nicht (auch) die Filepath-Methode unterstützt, die gerade bei Intel-nativen Programmen notwendig geworden ist (und schon länger von Apple empfohlen wird).
Hallo Herr Günther,
ich glaube nicht, dass das zutrifft. Durchgestriche PDF-optionen wurden hier schon zig-fach disktiert. Die Ursachen liegen normalerweise darin begründet, dass mehrere Acrobat-Versionen parallel installiert wurden und sich egegenseitig in Gehege kommen (weil die Aliases der Preference com.adobe.print.AdobePDFx auf die falsche Distiller-Version verweist bzw. die com.adobe.print.AdobePDFx.Defaults.xml Datei falsche Verweise beinhaltet) und/oder daran, dass z.B. Joboptions Verwendung finden, welche Sonderzeichen wie Umlaute im Dateinamen beinhalten.
Daher: Zuerst die neuesten CUPS Filter installieren.
Die da wären für einen "Adobe PDF" Drucker? Bei physikalischen Ausgabegeräte, die herstellerseitig einen oder mehrere *cupsFilter Einträge beinhalten trifft das sicher zu aber sicher nicht für Adobe PDF.
selbes problem mit ADOBE PDF im druckdialog sind die pdf optionen durchgestrichen!
"durchgestrichen" heisst normalerweise, dass Mac OS X den CUPS-Filter als nicht kompatibel einstuft, das passiert meistens, wenn dieser nur Laserwriter8-kompatibel ist und nicht (auch) die Filepath-Methode unterstützt, die gerade bei Intel-nativen Programmen notwendig geworden ist (und schon länger von Apple empfohlen wird).
ich glaube nicht, dass das zutrifft. Durchgestriche PDF-optionen wurden hier schon zig-fach disktiert.
Ich hatte "selbes" so verstanden, dass auch im angesprochenen Fiery-Problem die Option durchgestrichen ist, dadurch vermischen wir hier zwei Probleme. Meine Antwort bezog sich ausschliesslich auf das angesprochene Fiery-Problem. Vielleicht kann druggabeda das nochmal klar stellen, ob ich das falsch verstanden habe.
Allerdings wird auch beim PDF-Problem das "Durchgestrichen" nicht von QuarkXPress durchgeführt wird, sondern dies vom Betriebssystem rückgemeldet wird.
Daher: Zuerst die neuesten CUPS Filter installieren.
Die da wären für einen "Adobe PDF" Drucker? Bei physikalischen Ausgabegeräte, die herstellerseitig einen oder mehrere *cupsFilter Einträge beinhalten trifft das sicher zu aber sicher nicht für Adobe PDF.
Genau darauf bezog sich meine Aussage, daher hatte ich auf die Fiery-Zeile mitzitiert. Neu ist nicht der 2.0, sondern der 2.2, der die filepath-Methode bereitstellt und somit das Druckproblem mit QuarkXPress 7/Intel behebt.
toll das ihr reagiert! ich glaube ich werde meine probleme nochmal genauer beschreiben! villeicht finde ich dann die lösung in ihrer antwort! also die umgebung:
ein neuer intel macpro/neustes betriebssystem/quark 7.2 dann ein Minolta CF 2002 mit (Fiery X3e 31C-M PS v2.0 eu)PPD Quark druckt nicht!!! nach telefonat mit quarksopport... 1 ter lösungvorschlag war die cups filter in der PPD umzschreiben (wie auch in diesem vorum mehrfach vorgeschlagen. !!!DIESE FINDEN SICH ABER NICHT!! 2 ter lösungsvorschlag diesen fiery updater zu installieren heute vormittag auf einer eigens installierten platte probiert !KEINE VERÄNDERUNG!!! Xpress druckt noch immer nicht so wie es sollte!
bzw. sind die druckeroptionen nicht verfügbar
ähnliches ist dann eben auch beim erstellen eines PDFs (ADOBE 7 läuft bei mir)
im systemdruckdialog sind die pdf optionen durchgestrichen
meine derzeitige lösung siehr für 2 tes problem so aus: im druckdialog/PDF/ PS füe PDF erstellen und dann mit dem distiller ein pdf erzeugen! allerdings weiß ich auf diesem wege noch immer nicht genau welche PPD er verwendet und ob das PDF für die belichtungsausgabe 100% in ordnung ist. denn da schlummert dann das nächste problem! ich muß mit diesen files dann ab morgen wieder auf meinen SCITEX belichter filme machen (PPD ist PSM 5)
Ich hatte "selbes" so verstanden, dass auch im angesprochenen Fiery-Problem die Option durchgestrichen ist, dadurch vermischen wir hier zwei Probleme. Meine Antwort bezog sich ausschliesslich auf das angesprochene Fiery-Problem. Vielleicht kann druggabeda das nochmal klar stellen, ob ich das falsch verstanden habe.
also im fiery sind die druckoptionen da, sie druckt einfach nicht sind die maschine druckt einfach nicht dieses problem wurde hier im forum schon mehrfach erwähnt allerdings half eben nichts lg druggabeda
(Dieser Beitrag wurde von gremlin am 26. Apr 2007, 18:41 geändert)
Was Matthias über deine Fiery wissen wollte war: 1. Wie heißt dein Druckertreiber und welche Version? 2. Wie heißt die PPD-Datei und welche Version?
Denn grundsätzlich könnte man ja auch eine andere PPD-Datei zum Drucken verwenden, nur das dann nicht alle Optionen im Druckdialog zur Verfügung stehen.
Aber bei einer Fiery kannst du doch auch nachträglich die Einstellungen vornehmen, verwendest du die Command Workstation um auf die Fiery zukommen?
ebenfalls hallo alle zusammen so die gute nachricht zuerst
meine minolta (fiery) scheint wieder mit allen verfügbaren druckeroptionen(duplex, papierlade, ect. zu drucken!
zum nachvollziehen nur soviel dieser CUPS filter von fiery scheint notwendig zu sein! (leider sehe ich nicht was er wo installiert)
interesanter weise hatte ich nun plötzlich eine fiery PPD mit diesem cups filter aber irgendwo auf einer meiner datensicherung!!! hat da der cups updater dort was installiert! ich weis es nicht
nur soviel den PS code habe ich nicht umschreiben müssen (wurde mehrfach in diesem forum vorgeschlagen)
was ich noch gemacht habe ist die drucker neu angelegt und im xpress über PPD manager nochmal aktualisiert!
jetzt scheints zu funken!
herzlichen dank erst mal für eure hilfe!!!!
das problem mit PDF erstellung ist allerdings noch vorhanden zur erinnerung (PDF optionen sind in apple druckdialog durchgestrichen) (( ich hab den Acrobat 7)) den 8 ter bekomme ich hoffentlich demnächst! glaubt irgendwer das das problem dann behoben ist???
den sonst arbeite ich weiter über: PDF als PS sichern... und dann in den distiller ziehen allerdings möchte ich gerne wissen ob er hier tatsächlich die ausgewählte PPD verwendet.
Kann mir das irgendwer bestätigen?
aber weiter mit Xpress problemen:::. auch schon mehrfach in einem dieser foren angesprochen Die Tastaturkürzel!!!
frage an den moderator: soll ich mich nun dort wieder neu enloggen oder könne wir das hier weiterdiskutieren?
Problem ist folgendes: einige der mir beliebten Tastaturkürzel wie zun beispiel An gleicher stelle einfügen funktioniern nicht!!! im Menü ist er vorhanden und dort geht er auch!
aber weiter mit Xpress problemen:::. auch schon mehrfach in einem dieser foren angesprochen Die Tastaturkürzel!!!
frage an den moderator: soll ich mich nun dort wieder neu enloggen oder könne wir das hier weiterdiskutieren?
Problem ist folgendes: einige der mir beliebten Tastaturkürzel wie zun beispiel An gleicher stelle einfügen funktioniern nicht!!! im Menü ist er vorhanden und dort geht er auch!
Klick oben im Forum auf "quarkuser.net", dort findest du eine PDF-Datei mit allen Tastenkürzeln in QXP 7 mit dem Hinweis ob das Kürzel funktioniert oder nicht.
allerdings möchte ich gerne wissen ob er hier tatsächlich die ausgewählte PPD verwendet.
XPress 7 ist beim PDF-Export (sei es als PS oder PDF) vollkommen unabhängig von irgendwelchen weiteren Komponenten, die auf dem Rechner sind. Du kannst also einen Rechner neu aufsetzen, Xpress 7 installieren, eine Postscript-Datei erstellen und sie auf einem anderen(!) Rechner destillieren. Es werden keine PPDs oder ähnliches benötigt. Das war bei älteren XPress-Versionen nicht der Fall.
Zum Thema "Tastatturkürzel" erstelle doch einen neuen Thread.
Klick oben im Forum auf "quarkuser.net", dort findest du eine PDF-Datei mit allen Tastenkürzeln in QXP 7 mit dem Hinweis ob das Kürzel funktioniert oder nicht.
schon gemacht! lt. liste funktioniert er! lg druggabeda
(Dieser Beitrag wurde von gremlin am 27. Apr 2007, 09:46 geändert)
das problem mit PDF erstellung ist allerdings noch vorhanden zur erinnerung (PDF optionen sind in apple druckdialog durchgestrichen) (( ich hab den Acrobat 7))
das problem mit PDF erstellung ist allerdings noch vorhanden zur erinnerung (PDF optionen sind in apple druckdialog durchgestrichen) (( ich hab den Acrobat 7))
ich hab mir mal die Mühe gemacht, das zu übersetzen, da der Beitrag von Dave Ebersole, seines Zeichen technischer Produktmanager bei Quark, genau beschreibt, was (und warum) hier passiert:
Beschreibung Der Grund dafür ist ähnlich gelagert wie die CUPS Druckprobleme, die nach Erscheinen der ersten Universal Binary Version von QuarkXPress auftraten. Da Apple bestimmte APIs (also Routinen im Betriebssystem) mit der Umstellung auf Intel-basierte Computer ausgemustert hat, musste Quark die Art der Druckansteuerung in QuarkXPress ändern. Diese Aussage soll keinenfalls Apple den schwarzen Peter zuschieben, sondern nur verdeutlichen, dass keine willkürliche Änderung war, sondern genau zu diesem Zeitpunkt notwendig war.
Technischer Hintergrund Wenn ein Druckjob an CUPS übermittelt wird, erstellt das Betriebssystem basierend auf den MIME-Types des Jobs eine Routingkette, z. B. so: Job Daten -> Beispielfilter 1 > Beispielfilter 2 > Backend
Jeder Filter muss im System (mittels MIME-Type in der Konfigurationsdatei) anmelden, welche Art Daten er verarbeitet und ausgibt. Darauf basierend, konsumiert jeder Filter in der Kette die Ausgabe des vorherigen Filters und gibt die Eingangsdaten für den nächsten Filter aus.
Eine Anwendung, die ihr eigenes PostScript erstellt, nutzt den MIME-Type "application-postscript" und die Routingkette sieht wie folgt aus: Job Daten -> pstops -> Backend
Der "pstops" Filter ist für alle Druckfunktionen zuständig, die nicht anwendungsspezifisch sind; wie z.B. Ausrichtung, Seiten pro Blatt, also alle Einstellungen, die im Papierformat- und Drucken-Dialog des Betriebssystems zu finden sind. Dieser Filter erzeugt immer Daten mittels "stdout", so dass das Backend die Daten via "stdin" erhält. Da QuarkXPress sein eigenes, vollständiges PostScript erzeugt, also auch die Einstellungen für Ausrichtung, Skalierung, Blattlayout etc. selbst erzeugt, können Konflikte mit dem "pstops"-Filter entstehen. Daher nutzt QuarkXPress für die Datenerzeugung den Dateipfad ("filepath") "application/vnd.cups-postscript" an Stelle von "stdout". Die Routingkette wird dadurch sehr einfach: Job Daten -> Backend
Problem beim Adobe PDF-Drucker Wenn nun ein Backend nur Druckdaten via "stdin" akzeptiert, tritt ein Problem auf. Viele CUPS-Filter akzeptieren Daten sowohl von "stdin" als auch via der "filepath"-Methode, daher treten Probleme nur mit manchen Geräten auf und mit anderen nicht.
Der Adobe PDF-Drucker bearbeitet Daten nicht direkt, sondern übergibt diese an einen weiteren Prozess. Das "pdf800" Backend übergibt die Daten an /Application/Adobe Acrobat 8.0 Pro/… und leider hat dieser Prozess keine Zugriffsrechte auf die Datei im Spoolordner des Systems.
Lösung Wie in Foren bereits beschrieben, kann das Problem mit dem Adobe PDF-Drucker temporär umgangen werden, indem die Rechte des Spoolordners des Betriebssystems umdefiniert werden.
Gerätehersteller wie OKI, Xerox, EFI, die wir auf die oben beschriebene Problematik ihrer CUPS-Filter angesprochen haben, haben alle mit Filterupdates reagiert, so dass hier keine Probleme mehr auftreten.
Uns ist bewusst, dass das Problem mit dem Adobe PDF-Drucker ein schwerwiegendes Problem für unsere Kunden ist, die einen solchen Workflow einsetzen. Daher haben wir Adobe kontaktiert, um schnellstmöglich eine Lösung zu finden.
Uns ist bewusst, dass das Problem mit dem Adobe PDF-Drucker ein schwerwiegendes Problem für unsere Kunden ist, die einen solchen Workflow einsetzen. Daher haben wir Adobe kontaktiert, um schnellstmöglich eine Lösung zu finden.
Ich finde es ziemlich arrogant von Quark, die Verantwortung diese Problems an die "Konkurrenz" abzuschieben. Wenn sie schon dermassen grossen Probleme in die Software programmieren, dann sollten sie sich selber den Kopf zerbrechen, wie sie diese wieder ausbügeln könnten. Gruss Markus
> P: MacBook Pro 2.4 GHz Intel Core 2 Duo, Mac OSX 10.6.6 PowerMac G4 350 MHz, Mac OSX 10.4.5
>G: Mac Pro Intel Xeon 2.66 GHz, Mac OSX 10.6.4 MacBook Pro 2.4 GHz Intel Core 2 Duo, Mac OSX 10.6.6 XServe 2x2 GHz Dual-Core Intel Xeon, Mac OSX Server 10.4.11
ganz so mag ich das nicht stehen lassen. Wir haben hier nur Quark durch Dave Ebersole gehört und Du hast darauf reagiert - mit gutem Recht.
Wir haben leider aber kein Statement von Apple und auch kein Statement von Adobe zu dieser angeblichen UniversalBinary-Problematik.
Ich zitiere hier nochmals mein Geschreibsel aus einem anderen Thread: >>>> 8. Die Schuldfrage des nichtfunktionierenden Druckens-in-den-Adobe-PDF-Drucker schieben sich Apple, Adobe und Quark gegenseitig zu. Apple soll angeblich die Richtlinie für UB-Programme geändert haben. Quark soll angeblich diese Richtlinie für UB-Programme befolgen (ab XPress 7.01 ist XPress UB). Mac OS X setzt die Zugriffsrechte für diesen Ordner sehr eng und repariert sie ständig (siehe Skripte hier von Robert Zacherl). Acrobat kann/will sich nicht gegen die Zugriffsrechte dieses Ordners durchsetzen. Quark will sich nicht gegen die Richtlinie von Apple hinwegsetzen. Und Apples MacOSX will ständig die Zugriffsrechte dieses Ordners wieder reparieren.<<<<
Was steht uns Usern zur Verfügung, um das zu überprüfen? - Und hat eventuell Dave Ebersole aus "politischen" Gründen Apple geschont? Es müsste also auf dem Markt ein weiteres UB-Programm geben, dass seinen PostScript-Code selbst(!) schreibt und nicht von Adobe stammt. Wenn es dieses Programm existieren sollte und aus diesem Programm bei der Ausgabe über den Adobe-PDF-Drucker dann tatsächlich eine PDF-Datei entsteht, dann wäre Quark der Schuldige. Wenn aber auch aus diesem von mir gesuchten Apple-konformen UB-Programm keine PDF-Datei entsteht, dann wäre der Schwarze Peter bei Apple (oder mit deutlich geringerer Wahrscheinlichkeit bei Adobe).
Ok, das ist richtig und ich habe vielleicht auch gestern Nachmittag aus dem Frust heraus, dass die Ausgabe auf unser efi Coloproof nicht funktioniert etwas voreilig gehandelt. Da aber auch andere Drucker wie Adobe PDF von Problemen betroffen sind und diese auch von den Herstellern gelöst wurden (werden mussten?) habe ich wohl etwas überreagiert.
Ich danke dir für die weiteren Hintergrundinfos, welche du hier veröffentlich hast. Aus dem Statement ging das für mich wirlich nicht hervor, dass sich Quark, Adobe und Apple in dieser Problematik den Schwarzen Peter gegenseitig zu schieben. Gruss Markus
> P: MacBook Pro 2.4 GHz Intel Core 2 Duo, Mac OSX 10.6.6 PowerMac G4 350 MHz, Mac OSX 10.4.5
>G: Mac Pro Intel Xeon 2.66 GHz, Mac OSX 10.6.4 MacBook Pro 2.4 GHz Intel Core 2 Duo, Mac OSX 10.6.6 XServe 2x2 GHz Dual-Core Intel Xeon, Mac OSX Server 10.4.11
es kann doch nicht aufgabe vom User sein QuarkXPressfehler zu beheben. Wir haben auch das Problem das wir nur auf dem Feiry Drucken können, wenn wir unter MacosX einen Drucker anlegen ohne PPD und dann in XPress7 diesen auswählen, und unter PPD dann die Fiery PPD nehmen. Leider können wir seit dies so ist nicht mehr die den Duplexdruck und andere Funktionen nutzen. Gehen wir auf XPress6 wo der Drucker mit PPD im Systemhinterlegt ist funktioniert es wie zu zeiten wo wir mit 6.5 gearbeitet haben. Quark lässt da etwas nicht mehr zu und sie müssen es auch beheben.
kurzes Followup nach langer Zeit, weil ich da gestern mit Bernhard Werner kurz drüber diskutiert habe...
Quark hat sich dabei für den Pfad
/private/var/spool/cups
entschieden.
Das wäre vermutlich gar nicht so falsch, wenn Quark noch einen Unterordner weiter stolpern würde, d.h. nach /private/var/spool/cups/tmp oder wo auch immer CUPS' "TempDir"-Variable aktuell hinzeigt. Siehe die Ausgabe von
powerbook-tk:~ tk$ grep "TempDir" /etc/cups/cupsd.conf # TempDir: the directory to put temporary files in. This directory must be #TempDir /private/var/spool/cups/tmp
Unglücklicherweise sind die Standard-Zugriffsrechte auf dieses Verzeichnis recht restriktiv (710) und ganz offensichtlich zu restriktiv als dass die Acrobat Distiller Library ihrem Job nachkommen könnte, was zum Scheitern der PDF-Erzeugung führt.
Schon erstaunlich, daß das bei Quark bis heute niemand gemerkt zu haben scheint und dort niemand daran denkt, daß da was schief laufen muß, wenn man ein Spoolsystem, das partiell auf root-Berechtigungen aufsetzt mit einem Prozeß zur PDF-Erzeugung verheiraten will, der im Kontext des lokal angemeldeten Benutzers läuft. Für solche Sachen wäre die Ablage temporärer Dateien unterhalb /Users/Shared eigentlich prima geeignet. Oder auch unterhalb /tmp mittels mktemp(3).
Gott sei Dank ist das Problem aber, nachdem es erkannt ist, leicht lösbar. Man passt einfach die Zugriffrechte des obigen Ordners an. Durch Eingabe von
sudo chmod 755 /private/var/spool/cups
im Terminal und Eingabe des Administrator-Passworts werden die Zugriffsrechte so angepasst, dass nun der Distiller Zugriff auf die Daten bekommt und diese wie gewohnt konvertieren kann.
Nur hat das ganze zwei Nachteile: Zum einen scheint der CUPS Scheduler bei jedem Neustart die Rechte des Verzeichnis wieder neu zu setzen -- kann man Ausprobieren, indem man ihm ein "SIGHUP"-Signal schickt und sich die Berechtigungen anschließend anschaut:
killall -SIGHUP cupsd
D.h. wenn dann müsste man die Änderung der Verzeichnisrechte in oder nach Apples CUPS-Aufruf-Skript unterbringen, also an zwei Stellen in /System/Library/StartupItems/PrintingServices/PrintingServices den chmod-Befehl einfügen und darauf hoffen, daß Apple niemals eine neue Version der Datei mit einem Systemupdate ausliefert oder ein eigenes StartupItem als bspw. "Xpress7PDFCreationPermissionFix" in /Library/StartupItems legen, das in seiner StartupParameters.plist Property List das da enthält:
und als ausführbares Skript "Xpress7PDFCreationPermissionFix" dann eben nur
#!/bin/sh chmod 755 /private/var/spool/cups
Zum anderen halte ich lasche Berechtigungen für das CUPS-Spoolverzeichnis grundsätzlich für keine so gute Idee, da die diversen CUPS-Exploits in der Vergangenheit immer wieder gezeigt haben, daß es eben auch in solchen Komponenten wie dem Spoolsystem immer wieder auszunutzende Lücken gibt. Und da zumindest ein Teil des Spoolsystems mit vollen root-Berechtigungen läuft (laufen muß), können die Konsequenzen fatal sein. Siehe bspw.
Zum Punkt PDF-Erzeugung aus PS-Datei direkt aus Xpress heraus per Druckdialog (was ja nicht so prickelnd sein soll, wenn man nicht Erweiterungen von Impressed oder Jo Lauterbach nutzt), fällt mir aber ein, daß man den hier als "Virtual Printer" bekannten Ansatz benutzen könnte. Der kann ja schon immer Distiller Hotfolder direkt erkennen und stellt die als stinknormale Drucker zur Verfügung in die dann auch direkt per Druckdialog hineingedruckt werden kann.
Kann man aber mit Xpress eh vergessen, oder? Da kommt man über den "intuitiven" Umweg "PDF-Export", wenn man eine PS-Datei will, eh nicht drumherum, weil sonst Informationen im PS-Code fehlen?
Kann man aber mit Xpress eh vergessen, oder? Da kommt man über den "intuitiven" Umweg "PDF-Export", wenn man eine PS-Datei will, eh nicht drumherum, weil sonst Informationen im PS-Code fehlen?
Genau. Xpress (ohne MadeToPrint oder MediaBoxXT) schreibt nur beim Export die Trim- und Bleedbox-Befehle in den Postscript-Code. 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.
Quarks interpretierte Aussage: Der Druckdialog ist zum Drucken da. Der PDF-Dialog ist für PDF-Generierung da – egal ob es intern Jaws macht oder extern der Distiller.
Mit freundlichen Grüssen Detlev Hagemann
(Dieser Beitrag wurde von Detlev Hagemann am 13. Jun 2007, 14:11 geändert)
Xpress (ohne MadeToPrint oder MediaBoxXT) schreibt nur beim Export die Trim- und Bleedbox-Befehle in den Postscript-Code. 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.
Hmm... klingt nicht wirklich plausibel (weil wenn sich die Xpress-Version ändert, ändern sich ja nicht die PPDs automatisch und es gibt ja auch welche, die Seitenformate bzw. die "ImageableArea" mit Nachkommastellen definieren aber zugegebenermaßen nicht von Adobe). Zudem verstehe ich nicht, was die PPDs mit benutzerdefinierten Formaten in Xpress zu tun haben sollen...
Aber sei's drum: Das Fehlen der Boxen reicht ja bereits, um den Druckweg nicht zu beschreiten.
Mich interessierte obige Fragestellung auch noch vor folgendem Hintergrund:
Mich ärgert (seit Jahren bereits) ein wenig, daß der Installer von Dave Uhlmann für mein "Virtual Printer" CUPS-Backend alle Möglichkeiten des Backends brach liegen läßt bis auf die unspannendste (PostScript-File in einen spezifischen Ordner schreiben). Jedenfalls arbeite ich da grad dran, überarbeite das Backend und stelle demnächst selbst einen Installer bereit, der die eh schon existenten zusätzlichen Betriebsarten (Distiller-, GhostScript-, PDF Enhancer- und PStill-Hotfolder) simpel mit in Betrieb nehmen läßt.
Bzgl. PostScript-Ausgabe aus Xpress und Distiller-Hotfoldern frage ich mich nun, ob es sinnvoll ist, in diesem Modus eine Notiz auf die erste Seite zu pappen (analog zu Impressed' Distiller Secrets), die davor warnt, PDFs auf diese Art&Weise zu erzeugen und zum PDF-Export-Weg rät.
Frage in die Runde: Ist das ein zuviel an Gängelung oder für unbedarfte Anwender ein wichtiger Hinweis?
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.
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?
gruss. gremlin "geht nicht" ist keine problembeschreibung...
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.
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.
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.
gruss. gremlin "geht nicht" ist keine problembeschreibung...
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?
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):
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 ;-)
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
(Dieser Beitrag wurde von Bernhard Werner am 14. Jun 2007, 13:37 geändert)
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:
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.)
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:
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)
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.
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?
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.
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*
Aber die Grundfunktionalität des Dingens mit all den verschiedenen Betriebsarten existiert seit bald 'nem halben Jahrzehnt -- nutzt bloß niemand ;-)
Gar nicht wahr ;-)
Mal blöd gefragt, da ich demnächst ein Update des "Virtual Printer" fertig habe, das ein paar nette neue Features mitbringen wird: Wird es nötig sein, auch die Hotfolder-Varianten upzudaten?
Aktuell plane ich nur für bisherige Nutzer der "Maximal-Simpel-Variante" des "Virtual Printer " (also das reine "In-Datei-Drucken") einen simplen Upgrade-Modus, so daß nach Installation der neuen Variante erstmal alle Settings identisch bleiben (also identischer Zielordner und Anpassung des eingerichteten "Virtual Printer" CUPS-Druckers automatisch im Zuge der Erstinstallation der neuen Version).
Sollten da draußen aber auch Anwender der Hotfolder-Varianten in relevanter Zahl existieren, wäre es wohl sinnvoll, denen auch eine automatische Migration der Settings anzubieten.
Ach ja, zu den neuen Features des "Virtual Printer":
* Ab MacOS X 10.4 Automator-fähig, d.h. man kann beliebige Automator-Aktionen automatisch auf die erstellten Dateien anwenden lassen
* Neuer Hotfolder-Modus (der ähnliche Strukturen wie Distiller-Hotfolder erwartet aber direkt Adobes pdf-Backend hijackt und dieses passend parametrisiert mit dem Druckjob aufruft und damit quasi "betreut" den Job destillieren läßt. (Vorteil: Alle möglichen Distiller-Versionen parallel verwendbar, kein Streß mit Umlauten in Joboptions oder "bösen" Zeichen in Druckjobnamen, keine durchgestrichenen oder fehlenden PDF-Optionen im Druckdialog --> it just works)
* "Per User"-Ausgabeordner (wenn das im Netzwerk eingerichtet wird, dann pro User eigenen Ordner, in dem die Druckjobs als PDF ankommen)
Ich hab mal diesen (und viele andere) Forumbeiträge zum Thema Drucken durchgesehen. Dabei war eigentlich immer das Problem, dass die Seite gar nicht rausgekommen ist.
Ich habe das Problem, dass mir ziemlich viele Seiten rauskommen (wenn ich nicht vorher notfallmässig das Papierfach rausreisse und dann möglichst schnell alle Druckjobs kille) und alle haben in der oberen Zeile so tollen ornamentalen ASCII-Code.
Das passiert mir aus dem Quark 7.2, OS 10.4.8 auf jegliche Lexmark-Drucker (C920 und E332n), aber nicht auf Xerox kaum hats irgendwo ein Bild drauf (bei nur Text ists ok). Ich hab schon von binär auf ASCII und zurückgewechselt und s'geht beides nicht. Zuerst eine Vorschau drucken und diese dann printen geht aber.
Ich weiss jetzt nicht, ob das hier auch noch reinpasst, aber herzlichen Dank schon mal.
Nö, geht auch nicht. Und Postscript 2 und 3 gehen nicht. Und nicht nur Bilder, sondern auch Schlagschatten gehen nicht...
Ach ja (Nachtrag): Heute Morgen hats einmal mit ASCII geklappt und meinte, das Problem sei behoben. Ich dachte das jedenfalls bis vor kurzem. Inzwischen habe ich das Gefühl, das ich da noch in einem Kafi-Delirium stand und sich das ganze nur in meinem Kopf abgespielt hat, denn ich kann das ganze mit selbigen Einstellungen und dem selben Doku nicht wiederholen und ich hab keine Beweise, dass es wirklich je geklappt hat...
(Dieser Beitrag wurde von MCMessagemaetens3D am 6. Aug 2007, 17:23 geändert)
Toll. Das freut mich. Ich liebe A***-Karten. Und was ist nun die Lösung des Problems? Oder ist die Lösung "geht nicht" -> neuer Drucker?
Übrigens: gestern Abend hab ich tatsächlich geschaft auf dem Lexmark einen Print mit Schlagschatten rauszulassen. Dabei hab ich einfach die Druckeinstellungen (Ausgabestile Xerox-Drucker mit allen Xerox-Einstellungen) benutzt. Heute geht das wieder nicht mehr. Ich bekomm langsam Hirnkrämpfe. Irgendwie wirke ich – so scheint mir – nicht wirklich glaubhaft, aber ich schwöre, es war so...
Soweit ich das auf der Homepage von Lexmark sehe, sind die Treiber und PPDs von 2005. Somit sehe ich den Ball eher bei Lexmark, das die endlich aktualisierte Dateien zu Verfügung stellen. Aber ob die Drucker echten Postscript oder nur PS-Emulation können, das ich weis ich nicht bzw. gibt die Webseite nicht her.
Soweit ich das auf der Homepage von Lexmark sehe, sind die Treiber und PPDs von 2005.
das alter eine ppd ist im prinzip egal. sie beschreibt ja einfach die fähigkeiten des druckers, und wenn dieser zehn jahre alt ist, ändern sich dessen fähigkeiten nicht (im gegensatz zu käse werden die dinger nicht reifer und besser ;-)).
Aber ob die Drucker echten Postscript oder nur PS-Emulation können, das ich weis ich nicht bzw. gibt die Webseite nicht her.
das alter eine ppd ist im prinzip egal. sie beschreibt ja einfach die fähigkeiten des druckers, und wenn dieser zehn jahre alt ist, ändern sich dessen fähigkeiten nicht (im gegensatz zu käse werden die dinger nicht reifer und besser ;-)).
Im Fall von QXP 7 als UB schon, siehe Punkt 7 unserer Bugliste.
Ok, das Problem ist einigermassen behoben. Neue Treiber (wenngleich die Versionsnummer die selbe ist) waren das eine. Das andere ist, dass ich die Printer weder über die IP-Adresse (C920) noch über das Bonjour-Protokoll (E332n) ansteuern kann (was vorher überhaupt kein Problem war) sondern nur noch über Apple-Talk. Mit dieser Bugfix-Kombo hatte ich jetzt während meinen Tests keine Probleme mehr. Mal schauen wie lange das anhält...
Bei mir ist etwas ganz komisches passiert bzw. nicht passiert:
Auf dem ersten Rechner 10.4.10 mit XPress 7.2 kann ich wunderbar mit der normalen PPD auf den OKI 9600 v2 drucken. Alles kommt bestens raus.
Auf den drei Rechern, die ich danach installiert habe (10.4.7, 10.4.8 sowie 10.4.10), laufen die gleichen Einstellungen nicht. Ich habe aus der ersten XPress-Version die Ausgabestile exportiert, auf Betriebssystem-Ebene ist alles richtig und vor allen Dingen auch gleich eingetragen. Auf allen Rechnern kann ich aber aus 6.5 heraus problemlos drucken.
Woran kann das den jetzt schon wieder liegen ? Fragt sich und Euch
Jetzt weiss ich auch, warum wir damals von AppleTalk auf IP ausgewichen sind. Machmal schluckt der Lexmark einfach die Jobs über AppleTalk.
@peterhenrich: Ich bin ja nicht so der Superuser, aber bei mir haben (wie in den letzten paar Einträgen beschrieben) die Quark-Versionen unterschiedlich auf Druckerprotokolle reagiert. Sind die Drucker wirklich überall gleich angesteuert?
Jetzt weiss ich auch, warum wir damals von AppleTalk auf IP ausgewichen sind. Machmal schluckt der Lexmark einfach die Jobs über AppleTalk.
@peterhenrich: Ich bin ja nicht so der Superuser, aber bei mir haben (wie in den letzten paar Einträgen beschrieben) die Quark-Versionen unterschiedlich auf Druckerprotokolle reagiert. Sind die Drucker wirklich überall gleich angesteuert?
Ich steuere teilweise über IP bzw. Bonjour an. Nützt aber beides nix. Habe sogar Screenshots von allen Einstellungen meines funktionierenden Druckers gemacht, diese ausgedruckt und an den anderen Rechnern nachvollzogen. Führe dies aber nochmal durch -vielleicht habe ich wirklich irgendwo ein Häckchen vergessen.
Jetzt weiss ich auch, warum wir damals von AppleTalk auf IP ausgewichen sind. Machmal schluckt der Lexmark einfach die Jobs über AppleTalk.
Sicher? Nicht eher umgekehrt?
Ich beschäftige mich berufsbedingt mit Druckern überwiegend nur noch im "Es druckt nicht!"-Fall. Und da haben sich im Netzwerk-Bereich zwei Fehlerquellen herauskristallisiert:
1) Drucker per TCP/IP (remote LPR oder TCP/IP Streams, "Bonjour" ist kein Druckprotokoll! -- vgl. mit http://kaiser-edv.de/...uckerprotokolle.html): Funktioniert manchmal nicht, d.h. Druckjob bricht ab oder Drucker friert ein. Reproduzierbar auf HP LaserJets, Canon ImageRunnern mit internem RIP, diversen Fiery-RIPs und Modellen einiger andere Druckerhersteller. Abhilfe: AppleTalk verwenden, wenn möglich. Hintergründiges bspw. unter http://groups.google.com/...msg/dad72dcf4dc37a95
2) Drucker werden per AppleTalk angesteuert aber Jobs verschwinden einfach ab und zu mal. In dem Fall ist höchstwahrscheinlich das AppleTalk-Netzwerk falsch parametrisiert in der Form, daß zwei AppleTalk-Router im Einsatz sind, die verschiedene Vorstellungen über die jeweilige sog. "Default Zone" haben. "Dumme" AppleTalk-Devices wie bspw. LaserDrucker-RIPs kommen dann leicht mal durcheinander und hängen sich einmal in die und einmal in die andere Zone. Wenn in dem Moment gedruckt werden sollte, versandet der Druckjob eben im Nirvana. Abhilfe: AppleTalk-Routing-Grundlagen anlesen, Settings geradeziehen und dafür sorgen, daß alle Clients das sauber übernehmen oder Experte anheuern.
@peterhenrich: Ich bin ja nicht so der Superuser, aber bei mir haben (wie in den letzten paar Einträgen beschrieben) die Quark-Versionen unterschiedlich auf Druckerprotokolle reagiert. Sind die Drucker wirklich überall gleich angesteuert?
Das ist leider tatsächlich Normalität, hat aber nicht direkt mit Xpress zu tun sondern tritt auch mit anderen Anwendungen auf, wenn TCP/IP verwendet wird, per PostScript gedruckt wird (und nicht per PCL oder andere primitivere Druckersprachen, wie sie meistens Windows-Clients einsetzen) und gewisse Zeichenfolgen im Druckjob vorkommen (die der Drucker dann bei Ansteuerung per TCP/IP als Kontrollsequenzen interpretiert, dabei abschmiert oder den Druckjob vorzeitig abbricht).
Ja, sicher. Jetzt hab ich das aber schon länger nicht mehr gehabt obwohl ich ja im Zusammenhang mit dem Quark7 wieder auf ATalk umsteigen musste. Vielleicht hat der Informatiker da mal was rumgebastelt. Kommt nur noch ganz selten vor.
"Bonjour" ist kein Druckprotokoll!
Was ist es eigentlich genau? Also ich kann meinen Drucker über Bonjour ansteuern. Auch andere Compis sind mittels Remote über Bonjour erreichbar.
Was ist es eigentlich genau? Also ich kann meinen Drucker über Bonjour ansteuern.
Nein, über Bonjour kann man nichts ansteuern. Man kann allenfalls was damit finden. Hinter Bonjour (genauer Zeroconf) verbirgt sich die Idee, die sprichwörtliche Idiotensicherheit der AppleTalk-Protokollfamilie Richtung TCP/IP zu transportieren.
Dazu gehört selbständige Konfiguration der im Netz beteiligten Gerätschaften (Rechner, Drucker, etc.) in Form von automatischer Adreßvergabe als auch die simple Lokalisierung von Services. Nichts anderes tut ein Drucker, der seine Fähigkeiten bzw. (Ansteuerungs-)Möglichkeiten per Bonjour im Netzwerk annonciert. Er wird leichter auffindbar. Aber welches eigentliche Protokoll gesprochen wird, weiß man noch lange nicht.
Dafür hilft ein Blick mittels Bonjour Browser ins Netz. Damit sieht man dann konkret, welche Protokolle verwendet werden -- alleine Apples offizielle Auflistung kennt schon mal deren vier:
Ich habe auf Thomas seiner Webseite einen für mich interessanten Beitrag gefunden und ich könnte mir vorstellen, das viele Problem durch diesen Beitrag behoben werden könnten. http://kaiser-edv.de/...s/druckprobleme.html