Hallo,

mal eine Frage. Ich hoffe, ich habe das jetzt richtig in Erinnerung.

Stimmt es, dass wenn man einen bestimmten Drucker über das Netzwerk angeschlossen an einem anderen Mac, man auf dem Druckauftrag absenden Mac den Treiber für den entsprechenden Drucker haben muss?

Wenn ja, warum ist das so?

Ich mein, wenn ich ein JPG von einer anderen Person ausgedruckt haben möchte, dann geb ich's ihm und muss ja nicht wissen, wie er das tut. Ähnlich dem Lagerhalter.


MfG

Äh ja…bis sowas wie K.I. aber mal funzt und die wäre dazu nötig…wird erstmal ganz rudimentär der Text in kompatibler Art und Weise vom Mac quasi formatiert und aufbereitet mit den ganzen Steuerbefehlen und an den Drucker geschickt, praktisch durch den anderen Mac…und nicht an den Mac mit dem Drucker und dort formatiert.

Hängt wohl auch mit den diversen Druckern zusammen, die u.a. nicht Postscript fähig sind und gerne kann sich jemand anderes noch dazu äussern.

Das passende Protokoll, Formatierung und Druckerwarteschlange, musst ja auch (eigentlich) bei Netzwerkdruckern eintragen, dito bei CUPS.

Wobei, so ganz ernst gemeint war die Frage wohl eh nicht *grins*

Nein, man kann auf dem Mac mit dem angeschlossenen Drucker einen virtuellen Postscript Drucker einrichten, so daß alle anderen Macs via CUPS auf einem Postscript-Drucker ausdrucken und nur der Host Mac das PS nach was-auch-immer konvertiert.

Weil der Begriff "Treiber" unter OS X seit 10.2 insg. mindestens 3 verschiedene Sachen umfaßt:

• Druckerbeschreibungsdatei (sog. PPDs, die in /etc/cups/ppd/ liegen)
• Ggf. Erweiterungen des Druckdialogs über sog. "Printer Dialog Extensions" (PDE -- werden in der PPD vermerkt und bedeutet, dass auf dem Mac, auf dem der Druckerdialog erscheint, soz. noch Plugins also "echte Programme" für den Druckdialog aufgerufen werden, siehe "grep APDialogExtension /etc/cups/ppd/*")
• Die eigentlichen Filter, die dann die Arbeit machen, d.h. aus dem Ursprungsformat -- unter OS X meist PDF -- dann ein gerendertes Seitenabbild erzeugen und in die Grafikprimitive des jeweiligen Druckers umwandeln. Auch diese Filter können durch die PPD soz. hartkodiert referenziert werden und sowas sorgt beim "simplen Rüberkopieren" von "Treibern" immer wieder für Ärger, weil's niemand weiß, dass das so ist

Der Filterkram könnte theoretisch egal wo laufen, da aber für das Einstellen der Optionen, für die Anzeige der Dialog Extensions und für ggf. hartkodierte CUPS-Filter aber eh auf dem Ursprungs-Mac Dateien gebraucht werden und kein User den ganzen Quatsch versteht bzw. sich damit beschäftigen will, ist das so wie's ist und der "Treiber" muß auf dem initialen Mac vorhanden sein (wenn Du mal in das Installer-Paket eines solchen "Treibers" reinschaust, dann wirst Du sehen, dass der/die CUPS-Filter, die die eigentliche Arbeit machen, der klitzekleinste Teil sind, der Rest sind Icons, Farbprofile, Druckerhilfsprogramme, PDEs, etc.)

Das Beispiel taugt hundertprozentig, wenn man's sich auch mal komplett in den Kopf schraubt. Denn nicht Du sondern die andere Person ruft den Druckdialog auf und entscheidet, welche Optionen des Druckers genutzt werden sollen (Normalpapier, Fotopapier, A4, A5, B6 lang, etc. pp.). Das Ganze ist kein technisches bzw. "Treiber"-Problem sondern eines der Parametrisierung, bzw. wo entschieden wird, mit welchen Einstellungen gedruckt werden soll. Und das sind happig viele Optionen, um die es geht. Von Papiergröße über -Art bis hin zu all den schicken Features über die sich die Druckerhersteller voneinander abheben wollen.

Nachgucken für eine konkrete Queue kann man per "lpoptions -d ...": und was eine konkrete Druckerbeschreibungsdatei ohne noch dazukommende PDEs alles einstellbar vorrätig hält, sagt einem "lpoptions -d ... -l":

Wir haben bei Kunden Workflows gebaut, wo die Settings einmal festgelegt werden und die Leute dann wirklich nur noch Dateien auf den Server schubsen, wo sie mit den vorher mal definierten Settings gedruckt werden. Technisch null Problem, denn die Problematik wohnt woanders: Definition konkreter Drucksettings und "User Experience"

Die PDEs sind eine proprietäre Mac Geschichte, und technisch für den Betrieb des Druckers nicht notwendig. Unter *I*X geht es auch PDEs, dafür gibt es etwas andere PPDs.

Die ganze Chose ist kein technisches Problem sondern in erster Linie eine der "Bedienbarkeit". Trifft auch auf Deine erste Antwort zu, es braucht keinen "virtuellen PostScript-Drucker" in der Situation, es reicht bereits, wenn Du auf dem abschickenden Mac dafür sorgst, dass dort nix gefiltert wird ("-o raw" bzw. die Queue gleich so passend anlegen), dann wird auf dem empfangenden Mac gefiltert.

Aber das ändert nichts dran, dass irgendwer die Druckparameter vorgeben muß -- Beispiel Tintenspritzer: Wenn Du da Fotopapier einlegst und in den Druckersettings "Normalpapier" auswälhst, sieht's Scheize aus und umgekehrt. Die Settings müssen passen und irgendwer muß die irgendwo halt nunmal vornehmen.

Dachte ich auch mal, stimmt aber nicht:

Die wirklichen Druckmonster mit ultrakomplexen Ausgabeoptinen wurden vermutlich nie direkt von *I*X aus nur per PPD angesteuert (bzw. dort mittels entsprechender Tools, ich kann mich noch konkret an was für IRIX erinnern)

Aber es ist ja "eigentlich" auch kein technisches Problem, wo der Treiber sitzt sondern eins der Bedienung und Beherrschbarkeit.

Wir haben das für einen Kunden auch mal so aufgebaut, dass er auf den Macs inkl. PDE Drucksettings definiert hat, dann unverändert auf den Druckserver gespoolt hat (Solaris mit Helios), dort die Druckdaten über einen dedizierten Mac geschleift wurden, auf dem der zur PDE passende CUPS-Filter aktiv war und die CUPS-Joboptions der PDE interpretiert und passend die Druckdaten modifiziert wurden, und dann die Druckdaten -- unter Solaris noch nach TBCP gewandelt -- auf einen von 2 an 'ner Windows-Büchse hängenden Drucker ausgegeben wurden. Muß wohl 2006/2007 gewesen sein, denn wozu der ganze Quatsch? Wegen PowerPC vs. Intel: Der CUPS-Filter crashte unter PowerPC ab paar hundert MB Daten, deshalb mussten wir alle Druckjobs über eine eigens für den Zweck angeschaffte Intel-Gurke (ich glaub ein MBP) schleusen.

Wusste bis jetzt nicht, dass man einen Druckauftrag so verkomplizieren kann!

Dann mach es doch so, nimm einen Stick, speichere am einen Mac das JPG da drauf, geh zum anderen Mac und druck es da aus.

PDEs gibt es auf anderen Systemen als OSX definitiv nicht. Die APIs dafür sind in CUPS nicht vorhanden.
Wie haben im Büro so ein Multifunktionsgerät von Kyo (in D steh TA drauf steckt aber Kyo drin), das ist so ein großer Klotz >100kg mit abkoppelbarer Ausgabeoption. Man kann alle Ausgabeschächte direkt ansteuern, man kann das Papierfach direkt angeben, man kann das Farbmodell verändern, man kann die Kostenstelle wählen usw.

Ok, man muß schon die passende Applikation öffnen, weil die meisten Linux Applikationen nicht die vollständigen Optionen im Druckdialog anbieten. AdobeReader ist in dieser Hinsicht optimal. Die Liste mit den Optionen wird zum Teil etwas lang, aber immerhin geht es.

Da staunste, nee? Und wie erst, wenn Du Dir vergegenwärtigst, dass da gar nix "verkompliziert" wurde sondern diese ganze Komplexität in der Aufgabenstellung "Drucken unter OS X" einfach schon immer drinsteckt. Das ist genau deshalb unter der Haube so kompliziert, damit Du bzw. der Anwender davon nix merkt. Und solange alles läuft wie's soll, muß man sich mit dem Quatsch zum Glück auch nicht beschäftigen.

Wenn dann aber mal Probleme auftreten, ist es ausgesprochen hilfreich, zu verstehen, wie OS X' Drucksystem funktioniert. Im konkreten Fall hat's den Kunden davor bewahrt, zwei sündteuere Drucker zu entsorgen oder auf einen Schlag alle PowerPC-Macs wegzuschmeißen und durch Intel-Macs zu ersetzen. Und unsere Lösung hat's wenigstens mit sich gebracht, dass für die Anwender alles beim Alten blieb (nur unter der Haube wurden die Vorgänge auseinandergezogen auf mehrere Maschinen).

Ja und? PDEs sind älter als "CUPS am Mac" (das Konzept wurde den Entwicklern schon vor dem Release von 10.0 aufgedrückt, bis einschl. 10.1 war die damalige TIOGA-Architektur die einzige und ab 10.2, als CUPS dann die Basis war, konnten Druckerhersteller immer noch bis IIRC 10.5 ihren Treiberkram samt PDEs auf TIOGA basieren lassen) und die ganze Herangehensweise an "Drucken in OS X" aus der Unix-Perspektive ist und war schon immer falsch.

Weil's darum ging, komplexen Kram für einfache Anwender beherrschbar zu machen, und weil damals als das Ganze entwickelt wurde, Apple ein riesiges Problem hatte dergestalt, nicht nur die Anwender vom ollen MacOS 9 rüber Richtung X zu ziehen sondern auch die Druckerhersteller. Die haben schon gekotzt bei der Umstellung vom alten MacOS auf OS X (im alten System wurden die Erweiterungen des Druckdialogs, die dann zu PDEs wurden, noch als Programmcode in die Ressourceforks der PPDs gestopft, das fing mit irgendeiner LaserWriter 8 Version an) und hätten um ein Haar hingeschmissen als Apple dann mit CUPS um die Ecke kam. 10.2 war die erste ernsthaft nutzbare OS X Version. Wäre ein schöner Sch... gewesen, wenn die keinen einzigen Drucker abseits reiner PostScript-Maschinen mehr unterstützt hätte mangels Treiber.

Und bzgl. APIs: In Applesprech gab's und gibt es vier Sachen:

• I/O modules (entsprechen CUPS' Backends)
• Printer browsers (entsprechen der "device discovery"-Funktionalität der CUPS-Backends wurden aber aus nachvollziehbaren Gründen in OS X völlig anders als in CUPS umgesetzt, weil CUPS zum damaligen Zeitpunkt noch 0 Gramm reif war für ein anwenderfreundliches Betriebsystem und sowas wie ständig wechselnde Umgebungen != Serverumgebung)
• Printer modules (entsprechen CUPS' Filtern)
• Printing dialog extensions (nutzerfreundliche Erweiterungen des Druckdialogs, die mehr können als ein reines PPD-basiertes UI)

Dankenswerterweise hat Apple dann das, was aus CUPS-kompatiblen PDEs rausgefallen ist (TIOGA-basierte machten das IIRC anders) so in CUPS bzw. IPP integriert, dass es auch über Plattformgrenzen hinweg funktioniert hat (der Kram wurde einfach als IPP-Job-Attributes definiert und auf dem Weg an das später aufgerufene "Printer module" bzw. CUPS-Filter verfüttert).

Simpelkram

Im Ernst: Man kann mit PPDs, grad in der letzten Version 4.3 'ne Menge kodieren (ich mußte schon vorher als gewisse Programme -- "Aldus" Freehand und Pagemaker bspw. -- noch eine Kombination aus PPD und .pdx-Datei wollten, öfter in PPDs rumfuhrwerken und damals war das teils noch echt gaga-umständlich, siehe Appendix E in ).

Aber der ganze PPD-Zauber resultierte im UI am Ende immer nur in einer endlosen Abfolge von Auswahllisten, ergo ein anwenderunfreundliches Mist-GUI.

Und genau dafür waren PDEs und deren Vorläufer gedacht: Komplexen Mist einfach bedienbar machen (also bunte Bildchen einblenden usw. usf. -- und das ist kein unnötiger Luxus, grad wenn Drucker im Spiel sind, deren Ausgabeturm auch noch falzen kann, denn da müssen zum Teil sogar die Leute aus der Druckweiterverarbeitung ohne Visualisierung des Ergebnisses dreimal nachdenken, bevor sie die Auswirkungen der Kombination verschiedener Falzmodi im Kopf haben)