Hallo druggabeda

Du kannst innerhalb eine gewissen Zeit, deinen Beitrag noch ändern (Button "ändern" sichtbar) - danach nicht mehr.
Siehst du den Button noch ?

Antwort auf [ Drienko ]

Hallo druggabeda

Du kannst innerhalb eine gewissen Zeit, deinen Beitrag noch ändern (Button "ändern" sichtbar) - danach nicht mehr.
Siehst du den Button noch ?

nein sorry
wo soll der sein?

Hallo druggabeda

Egal, jetzt ist es eh zuspät.

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?

Hallole

Hier noch ein Beitrag über das Thema aus dem US-Forum von Quark.
http://www.quark.com/...iewtopic.php?t=17353

Hallole Zusammen

Hier ein Link zu einem CUPS-FAQ, wenn jemand näheres über das CUPS Printsystem wissen möchte.

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!

Hallo druggabeda

Antwort auf [ druggabeda ]

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.

Antwort auf [ druggabeda ]

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.

Antwort auf:

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

hallo druggabeda

Antwort auf [ druggabeda ]

das problem mit PDF erstellung ist allerdings noch vorhanden
zur erinnerung
(PDF optionen sind in apple druckdialog durchgestrichen)
(( ich hab den Acrobat 7))

betreffend druchgestrichene pdf-optionen: http://www.hilfdirselbst.ch/...orum.cgi?post=257583
beiträge mit titel "durchgestrichene pdf-optionen ...", nicht "verschwundene ..."!

bitte benutze die vorschau-funktion, um die setzung der formatierungstags zu prüfen, damit wir deine beiträge nicht immer korrigieren müssen.

Antwort auf [ gremlin ]

hallo druggabeda

Antwort auf [ druggabeda ]

das problem mit PDF erstellung ist allerdings noch vorhanden
zur erinnerung
(PDF optionen sind in apple druckdialog durchgestrichen)
(( ich hab den Acrobat 7))

betreffend druchgestrichene pdf-optionen: http://www.hilfdirselbst.ch/...orum.cgi?post=257583
beiträge mit titel "durchgestrichene pdf-optionen ...", nicht "verschwundene ..."!

bitte benutze die vorschau-funktion, um die setzung der formatierungstags zu prüfen, damit wir deine beiträge nicht immer korrigieren müssen.

ist das so besser?
gebt mir noch etwas zeit

Hallo, zusammen,

Antwort auf [ Drienko ]

Hier noch ein Beitrag über das Thema aus dem US-Forum von Quark.
http://www.quark.com/...iewtopic.php?t=17627

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:

Zitat

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.

Gruß
Matthias

Die letze Aussage von Quark finde ich ganz toll:

Zitat

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.

Hallo Markus,

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).

Hallo Detlev

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.

Aber moment mal.

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.

Hallo, Pippalu,

dazu gibt es einen weiteren, interessanten Beitrag von Dave Ebersole, Technischer Produktmanager bei Quark.

Vielleicht helfen ja die Lösungsvorschläge, die weiter unten beschrieben in diesem Beitrag beschrieben sind?

Gruß
Matthias

Hallo,

kurzes Followup nach langer Zeit, weil ich da gestern mit Bernhard Werner kurz drüber diskutiert habe...

Antwort auf [ Robert Zacherl ]

Quark hat sich dabei für den Pfad

Zitat

/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

Code

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 

und die Anmerkungen in den CUPS Manuals:

    http://www.cups.org/doc-1.1/spm.html#4_1_1

Antwort auf:

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).

Antwort auf:

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

Zitat

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:

Code

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:

Code

{ 
  Description     = "Xpress 7 PDF creation permission fix"; 
  Provides        = ("Xpress7PDFCreationPermissionFix"); 
  Requires        = ("PrintingServices"); 
  Uses            = ("NetworkTime", "Resolver"); 
  OrderPreference = "Last"; 
  Messages = 
  { 
    start = "Applying Permission Fix for Xpress 7 PDF creation"; 
    stop  = "Nothing to do"; 
  }; 
} 

und als ausführbares Skript "Xpress7PDFCreationPermissionFix" dann eben nur

Code

#!/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.

    http://labs.idefense.com/...es/display.php?id=30

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?

Gruss,

Thomas

Antwort auf:

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.

Hallo Detlev,

Antwort auf [ Detlev Hagemann ]

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?

Dank' und Gruss,

Thomas

Hallo,

gute Idee, tu das.

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

Hallo,

wie hast Du es geschafft, den PDF-Writer gemeinsam mit XPress 7 laufen zu lassen?

Bei mir funktioniert nur der PDF-Maker, und das nur mit den Office-Programmen.

Hallo Herr Zacherl,

Antwort auf [ Robert Zacherl ]

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 ;-)

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)

* Paar kleinere Fixes

Gruss,

Thomas Kaiser

Salü zusammen

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.

hallo

Antwort auf [ MCMessagemaetens3D ]

Ich hab schon von binär auf ASCII und zurückgewechselt und s'geht beides nicht.

und nr. 3 -- clean-8-bit -- geht auch nicht?

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...

hallo

ich fürchte, da hast du halt die postscript-emulations-a***karte gezogen...

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...

Hallo MCMessagemaetens3D

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.

Ahh...

SW-Druckereinstellungen mit ASCII-Code bei Schlagschatten geht. Bei Bilder schon nicht mehr.

HILFEE!

hallo bernd

Antwort auf [ Drienko ]

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 ;-)).

Antwort auf [ Drienko ]

Aber ob die Drucker echten Postscript oder nur PS-Emulation können,
das ich weis ich nicht bzw. gibt die Webseite nicht her.

siehe:
http://www.lexmark.ch/...84325_de_0_6,00.html
http://www.lexmark.ch/...85497_de_0_6,00.html

Hallo gremlin

Antwort auf [ gremlin ]

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.

Antwort auf [ gremlin ]

http://www.lexmark.ch/...84325_de_0_6,00.html
http://www.lexmark.ch/...85497_de_0_6,00.html

Tja, PS-Emulation. Damit sind Probleme nie ausgeschlossen, weis ich aus eigener Erfahrung.

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...

Danke euch

Matthias

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

Peter Henrich

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?

Matthias