Hi, da mein aktueller Drucker vermutlich Catalina nicht mehr erleben darf (da die letzte offiziell supportete Version macOS 10.8 war), wollte ich einmal fragen, ob jemand weiß, welcher Drucker Hersteller bereits 64bit Treiber anbietet. Vor allem bei den macOS Treiber schreiben die Drucker-Hersteller das ja nie dran, ob es jetzt 32bit oder 64bit ist. Und ich selbst habe bisher keinen Weg gefunden, das herauszufinden. Canon bietet ja für manche aktuellen Modelle gar keine Treiber mehr an und verweist nur auf AirPrint, und Epson hat zwar einen aktuell macOS Treiber, aber natürlich weiß man nicht, ob der jetzt 32bit oder 64bit ist. Ich habe zwar bei beiden Herstellern deswegen schon den Support angeschrieben, aber die meisten wissen vermutlich, wie kompetent so manche Supportabteilung ist *zwinker*. Daher meine Frage hier, ob es Wissen oder vielleicht sogar Erfahrung mit Druckern und 64bit / macOS Catalina gibt.

Der Witz dabei ist, dass es sich ja gar nicht um einen OKI-AirPrint Treiber handelt, sondern um den von macOS bereitgestellten. Und dieser ist halt nun mal ein einfacher Standard-Treiber, der dann ja die besagte AirPrint-PPD anlegt.

Der AirPrint-Treiber wird automatisch gewählt, wenn ich den OKI "automatisch" hinzufüge zu den Druckern.
Um den PS-Treiber zu wählen, muss der Drucker manuell hinzugefügt werden.

Nochmals zurück zu 32/64bit: wenn der Drucker-Treiber nur ein einfaches Text-PPD ist, kann dann dieses 32 oder 64bit sein...??

Schlussendlich arbeiten wir alle mit macOS und nicht UNIX, daher brauchen wir auch "32/64bit Treiber".
Den End-User interessiert CUPS etc nicht, er möchte die vom Hersteller angebotenen Funktionen nutzen können. Und MOMENTAN (in meinem Fall) kann ich dies nur über den offiziellen OKI-PS Treiber.
Ob CUPS etc. dieses IPP-everywhere schon lange unterstützt, nützt mir nichts und interessiert mich nicht.
Iin erster Linie geht es um den momentanen Zustand und natürlich wegen Catalina auch um die zeitnahe Zukunft.
Daher auch der Initial-Post...
Punkt

Im beschnittenen AirPrint-Treiber taucht der Reiter "Optionen" nicht auf. Diese Zusatzoptionen sind bei vielen Druckern vorhanden, z.B. HP, wo Zusatzoptionen wie Anzahl Zusatzfächer, Fachart (Dualfeeder, Grossraumkassette z.B.), RAM etc. definiert wird.

Wenn dann mal diese IPP-everywhere komplett umgesetzt ist, wird dies auch nicht mehr nötig sein...

Nein, natürlich nicht. Das 32bit-Problem existiert nur bezüglich irgendwelcher Plug-Ins, die so unentbehrliche Sachen wie graphische Toner-Füllstandsanzeigen implementieren.

Alles Wichtige kommt vom PPD und ist Bit-unabhängig.

Nimm doch mal (nach einem Backup ) das direkt von OKI geladene PPD, aber lösche alle Plug-Ins etc., die von meinem Terminal-Suchbefehl als 32 Bit gemeldet werden, und schau, was (nach einem Neustart) dann noch geht und was nicht mehr.

War ja gar keine ernsthafte Frage.......

Ja, weil er überflüssig ist.
Das ist schon klar, aber all diese Informationen überträgt der Drucker bei IPP selbst, ohne dass Du das irgendwo mühsam manuell eintragen musst …
Ist es jetzt schon nicht mehr, wenn Dir diese „Option“ (in Wahrheit ein umständlicher Zwang, Daten selbst einzugeben, obwohl die dem Drucker bekannt sind) nicht mehr angezeigt wird.

Ich zitiere mich in leicht geänderter Form:

"Dann freuen wir uns hier und jetzt auf die zukünftigen treiberlosen, unkomplizierten und freudvollen Printerinstallationen...
Hurraaaaa....."


BTW: Ich habe keine Probleme beim Drucken, es geht um die (momentane) Thematik an sich.

Von mir aus können wir den Thread schliessen....

Dann beschwer' Dich bei Apple.
Und auch das hält den Zug, der bzgl. IPP Everywhere ins Rollen geraten ist und schon längst Fahrt aufgenommen hat, nicht auf.

So ist es. Schaue Dir unter /Library/Printers die in den zugehörigen Unterverzeichnissen der installierten Drucker und meist in gezippter Form (.gz) vorliegenden PPDs doch an. Bzw. wenn eingerichtet, dann vom System bzw. von CUPS ggf. von dort nach /etc/cups/ppd kopiert.
Das sind schnöde Text-Dateien. Nix 32bit, nix 64bit. Mehr als diese Dateien sind im Grunde nicht notwendig fürs Drucken unter CUPS (in Zukunft noch nicht mal mehr das, weil, so von Michael Sweet zu lesen, CUPS wohl in Zukunft selbst auf PPDs verzichten will und die System-Drucker-Interaktion und -Kommunikation komplett über IPP laufen wird, ohne, dass irgendwo irgendeine Drucker-Information auf dem System abgelegt sein muss, noch nicht mal mehr abgelegt in einer PPD).

macOS IST ein Unix – im Gegensatz zu iOS sogar ein (gegen eine hohe Gebühr) zertifiziertes Unix – also ein UNIX®.
Scheinst Du zu vergessen bzw. geflissentlich auszublenden. Auch, wenn es Dir egal ist, es ist trotzdem so.

Nö. Brauchen wir nicht. Was da an 32/64-Bit-Gedöns in den "Treiber-Paketen" mit dabei ist, ist viel Zusatz-Gedöns, zusätzlich drumherum um den eigentlichen Treiber. Und der ist bisher unter Unix-Systemen mit CUPS als Drucksystem (also alle unixoiden Betriebssysteme der letzten xx Jahre) im Kern eine PPD, eine kleine schnuckelige reine Text-Datei.

Ich habe hier z.B. einen alten Minolta PagePro8 s/w Laser-Drucker rumstehen. Der braucht nix weiter als seine PPD (eine reine Text-Datei) unter /etc/cups/ppd. Früher habe ich die einfach da per Hand reinkopiert (besorgt von OpenPrinting.org, dort erzeugt mit Foomatic). Inzwischen habe ich GutenPrint installiert und lasse sie mir bei automatisch erzeugen bzw. bei jeder Aktualisierung von GutenPrint wird die übernommen und von CUPS+GutenPrint aktualisiert generiert.
Und so ist das mit vielen Druckern.

Habe dazu ja bereits was gesagt. Beschwer' Dich bei OKI bzw. Apple, was Deinen Drucker angeht, die Gesamt-Entwicklung hin zu treiberlosem Drucken hält das nicht auf, das ist höchsten abzubuchen unter "Kinderkrankheiten" bzw. "Anlaufschwierigkeiten" bzw. etwaige "Anlaufschwierigkeiten eines Herstellers".
Betriebssystem-Hersteller, Drucker-Hersteller und Standardisierungsgremien arbeiten an dem Thema treiberloses Drucken seit Jahren und haben es jetzt endlich auf die Schiene gebracht und befähigen ihre Geräte entsprechend zunehmend.
Das hältst Du nicht mehr auf.

Dann höre bitte auf, hier so unzufrieden und überskeptisch rumzuweinen.
Diesen Zug hältst Du nicht mehr auf, ob es Dir passt oder nicht.
Sei doch froh, dass diese Entwicklung endlich eingesetzt hat, freue Dich doch drüber, statt dagegen anzumeckern und ihr die Qualität abzusprechen.

Gerade Dir als Anwender müsste diese Entwicklung sehr entgegenkommen. Du sollst Dich nicht mehr um Treiber kümmern müssen, das sollte Dir egal sein – einfach nur nutzen das Zeugs, ohne Dir über das Wie und über evtl. Treiber und Features Gedanken machen zu müssen, betriebssystem- und herstellerübergreifend und -unabhängig und auch ortsunabhängig – das ist das Ziel unld Ansinnen auf diesem Weg, der herstellerübergreifend eingeschlagen worden ist und von mindestens einem Standardisierungsgremium (IETF) getragen ist.
Jahre hat es gedauert. Nun macht man es endlich. Freue Dich doch darüber, es ist in Deinem und unser aller Sinne.

Gerne verweise ich dich einfacherweise u.a. auf 14:46

Gelesen heisst noch nicht verstanden...

Es geht nicht darum, einen Zug aufzuhalten... es geht um die schon mehrfach erwähnte momentane Gegebenheit inkl. zeitnaher Zukunft...

Nur: wenn der Zug schon fährt, dann bitte nicht im Schneckentempo. Und bitteschön mit Klima und Bord-Bar

Nachtrag: Dass du meine "Frage" wegen 32/64bit PPDs ernst nimmst, ist schon fast eine Beleidigung...

clear:

Du musst das zukünftig gar nicht so hervorherben und damit suggerieren, als sei das alles noch sehr weit weg – denn diese Zukunft hat schon längst begonnen, und wir befinden uns bereits mittendrin im Geschehen.
Verbesserungsmöglichkeiten auf diesem Weg gibt es immer. Grundsätzlich. Das ist aber bei jeder technischen Entwicklung so. Aber der Weg ist bereits eingeschlagen, die Lokomotive hat bereits Fahrt aufgenommen, und sie fährt mit gutem Tempo, und die Richtung stimmt.

Doch, muss ich.... weil es nicht komplett umgesetzt ist..... weder allgemein noch in meinem Fall
Theorien nützen nichts, wenn du jemandem einen Drucker installierst und dann sagen musst: ähmmm... scheint momentan noch nicht zu funktionieren. Leider muss ich Sie vertrösten. Hmmm, ja das weiss ich jetzt halt auch noch nicht, wann das möglich ist.
Übrigens: die Zukunft beginnt bereits in einem Bruchteil eines Wimpernschlages

Jein. Es gibt halt PPDs die auf PDEs verweisen dort wird dann das ankommende Postscript "verarbeitet". Oftmals, aber nicht immer, bei eigentlich nicht Postscriptdruckern. In dem Fall findet dort dann zB eine Rasterung statt und es werden nur noch reine "Bitmaps" an den Drucker übertragen. Diese PDEs sind wohl am Ende das Problem mit 32/64 Bit. Hier gibt es also wirklich oftmals Handlungsbedarf.

Andererseits kann ich aus eigener Erfahrung bestätigen das oftmals von Dienstleistern für "Kopierer mit Rip" empfohlen wird, gerade nicht den Airprinttreiber zu verwenden sondern den "Richtigen", also IPP.
Ebenfalls habe auch ich schon öfters bemerken dürfen, das beim Airprinttreiber so manches fehlt, was im PS / IPP-Treiber vorhanden ist; zB. die Authentifizierungsmodule. In dem Fall werden vom Druckerhersteller dann nicht alle Daten (was kann ich wirklich) an den anfragenden Rechner übermittelt weil der Hersteller zu faul oder unfähig war, das komplett in den Drucker einzubauen. Das ist leider die Realität die öfters "im Feld" anzutreten ist.
Als Fazit würde ich sagen: noch sind die "Airprinttreiber" nur der kleinste gemeinsame Nenner auf den sich Rechner und Drucker bei der Druckereinrichtung haben einigen können. Warum das dann im konkreten Fall so bescheiden ausgeht, müßte man im Detail am lebenden Objekt / Drucker testen. Leider kommt das einem Reverse Engineering gleich und macht überhaupt keinen Spaß. Am Ende weiß man dann nämlich lediglich, warum es nicht geht. Das es nicht geht, wußte man schon vorher. Abhilfe schaffen kann man damit nur selten weil die Druckerhersteller sich meist taubstumm stellen wenn man sie auf gewisse Problem anspricht. Selbst wenn man im Detail nachweisen kann, warum und man eine Lösung für das Problem mit liefert

Das interne Standard-Format bei der Be- und Verarbeitung eines Print-Jobs von CUPS ist seit Jahren PDF und nicht mehr PostScript:

GitHub issue #2897: Adding CUPS filters for using PDF as standard print job format :

The Linux Foundation Wiki: OpenPrinting: PDF as standard print job format

Der absichtsvolle Einsatz von PostScript als Dokumentenformat fürs Drucken ergibt von daher inzwischen erst recht keinen Sinn mehr, auch nicht unter macOS. Nicht zuletzt deswegen: "A PDF-enabled CUPS setup turns incoming PostScript to PDF as first step in such a case."
Erst recht ist vor dem Hintergrund dann ein PostScript-Drucker einigermaßen sinnfrei geworden. Weil er eh schon lange kein PostScript mehr empfängt, wenn der Druck-Job von CUPS ausgeht.

Öhm, na gut, der Drucker bekommt ein PDF statt PostScript. Dann muss er aber das PDF rastern können. Und was braucht er dazu? PostScript (PDF ist ja nix weiter als ein reduziertes und verpacktes PostScript) …

Also an speziell dieser Stelle sehe ich jetzt nicht so den großen Unterschied. Entweder Drucker sind PDF-fähig (d.h. letztlich, es sind PostScript-Drucker), oder das PDF muss bereits auf dem Mac gerastert werden – und dann sind wir wieder beim „Treiber-Problem“ …

Weia:

Wie drucken Nicht-PostScript-Drucker seit Jahren denn PDFs aus? Gar nicht, die verweigern etwa bei auszudruckenden PDFs seit Jahren den Dienst, weil sie mangels eigenem PS-Prozessor mit PDF nix anfangen können? Dem ist offenbar nicht so, oder?

PostScript-Drucker haben in der Regel einen eigenen PS-Prozessor, wenn ich mich nicht irre, das ist jahrelang ihr großer Vorteil, ihr Alleinstellungsmerkmal, gewesen. Allenfalls druckt der das bei ihm ankommende PDF (was möglicherweise vorher ein PostScript-Dokument war, via CUPS aber automatisch in PDF gewandelt worden ist) dann etwas schneller aus (wenn überhaupt schneller) bzw. hat einen etwas größeren Speicher zur Aufnahme von Druckdaten. Oder? Welchen Vorteil hat er unter diesen Voraussetzungen sonst noch, wenn er seinen Hauptvorteil, nämlich PostScript direkt zu drucken bzw. zu wandeln, gar nicht mehr ausspielen kann, weil bei ihm im Eingabestrom gar kein PostScript mehr ankommt (zumindest via CUPS)?

Hmmm... ich nehme nicht an, dass der Printer direkt ein PDF erhält.

Ich gehe davon aus, dass ein PDF mit den gewählten Druckoptionen der "PrintCore" übergeben wird, diese dann eine gerasterte RAW-Datei erstellt und an den Drucker sendet.
Wobei die "PrintCore" Treibereinstellungen, PPD etc. berücksichtigt.
Auf die Schnelle sind leider keine vernünftigen Infos darüber zu erhalten.

Anhang Aufbau macOS, Quelle Wikipedia:

clear:

Wo ist in diesem Schaubild das Druck-System von macOS, CUPS? Es geht hier ums Druck-System. Und das ist CUPS.

PS-Drucker haben einen eigenen Prozessor und benötigen zusätzlich RAM, da der Druckjob auf dem Drucker berechnet wird. Daher sind diese tendenziell teurer als Nicht-PS Drucker.
PS-Drucker erhalten direkt PS-Files. Unter anderem ist dadurch auch eher gewährleistet, dass man von Treiberproblemen verschont bleibt.

D.h. meine vorherige Aussage bezieht sich auf Nicht-PS Drucker.

Leider ist nur die allgemeine "PrintCore" zu sehen. CUPS scheint in dieser einfachen Übersicht nicht weiter ersichtlich zu sein.

CUPS erhält vermutlich über die darüberliegende macOS-Schicht "PrintCore" die Daten.

clear:

Wo ist in diesem Schaubild das Druck-System von macOS, CUPS? Es geht hier ums Druck-System. Und das ist CUPS.

Was hast Du an Michael Sweets Ausführungen bzw. dem Satz "One of the decisions which was made on the OSDL Printing Summit in Atlanta in 2006 and widely accepted by all participants was to switch the standard print job transfer format from PostScript to PDF" nicht verstanden?

GitHub: Apple: CUPS: issue #2897, 06.08.2008: Adding CUPS filters for using PDF as standard print job format :

sowie den gleichlautenden Ausführungen von LinuxPrinting.org nicht verstanden?
Wenn er das sagt, wenn die das sagen, und das seit Jahren bereits so geplant und umgesetzt ist, dann kann man das ruhig glauben. Und muss es nicht infragestellen bzw. versuchen, es irgendwie anders zu deuten.

Michael Sweet Homepage: About This Site
Wikipedia (en): Michael Sweet
Wikipedia (en): CUPS

Wenn schon, dann dieses Block-Diagramm hier bzgl. CUPS (Quelle: genannter Wikipedia-Eintrag ): https://upload.wikimedia.org/wikipedia/commons/9/9a/CUPS-blo ck-diagram.svg , aber auch das ist nicht mehr aktuell, wenn man Obiges bedenkt: wo dort im Diagramm dick und fett PostScript aufgeführt ist, müsste seit einigen Jahren aufgrund der genannten Änderung PDF stehen.

Ich habs weder gelesen noch verstanden...

Dann kannst du uns ja erklären, wo sich dein Diagramm im macOS-Aufbau einordnen lässt...
Dies beschreibt nur den Linux/UNIX-Druckweg...

Äpfel und Birnen kann man nicht direkt miteinander vergleichen...

Und wenn macOS ein UNIX wäre, wäre CUPS im macOS-Diagramm sicher aufgeführt

"Nur" ist gut. macOS IST ein UNIX.
Und CUPS ist unter Linux/Unix/macOS überall gleich, funktioniert überall gleich, sie alle verwenden das Gleiche CUPS von cups.org wie Apple. Schon bevor Michael Sweet zu Apple ging und das CUPS-Projekt noch von ihm unter seiner Firma Easy Software lief (welche Apple aufkaufte bzw. ihm ein Job-Angebot machte, das er nicht ablehnen konnte und er seitdem CUPS unter dem Dach von Apple weiterentwickelt).

Dann versuche und tue es bitte auch nicht, ich tue es auch nicht.

Spaßvogel. Nicht wäre. Es IST.

Bitte schön, hier, direkt von Apples Server, aus Apples Open-Source-Ordner von CUPS (ob es das Aktuellste ist, weiß ich nicht):

Bzw. nochmal zu finden unter:

CUPS.org: CUPS Design Description

Aktuelles Beispiel für einen PS-Drucker/Plotter:

HP DesignJet T1700 44-Zoll PS-Plotter

Unterstützte Druckersprachen:
Adobe PostScript 3, Adobe PDF 1.7 Ext. 3, HP-GL/2, TIFF,JPEG, URF, CALSG4

Klar funktioniert CUPS gleich wie andernorts, das war nicht die Frage... nur wo es sich versteckt im macOS-Aufbau. Logisch wäre die "PrintCore", die in sich alle Printservices zusammenfasst, somit auch CUPS

Was willst du einem Mac-User antworten, der dich fragt, ob sein Drucker unter Catalina läuft?
Etwa: macOS ist (ein) UNIX, das ist kein Problem... wir haben ja die PPD und diese ist (wie wir heute gelernt haben) nur eine schnöde "Textdatei"
Dies kann man dem User z.B. schon per Mail oder Telefon mitteilen, jedoch armer Druckerinstallatör, der dies dann beim Kunden umsetzen muss

clear:

Was möchtest Du überhaupt? Was soll das Ganze jetzt werden? Diskutieren um des Diskutierens willen? Nerven, um des Nervens willen? Provozieren? Trollen?
Alle Deine Fragen sind bereits beantwortet worden. Du selbst hast heute um 14:46 Uhr in die Runde geworfen: "Von mir aus können wir den Thread schliessen...."

Guter Vorschlag. Wir drehen uns im Kreise. Wir sollten hier nun Schluss machen und uns an Deinen Vorschlag halten, es führt zu nix weiter. Ich habe gehofft und habe das Ansinnen gehabt, zur Erhellung des Themas etwas Sinnstiftendes beitragen zu können, aber nun komme ich an meine Grenze (auch zeitlich, vom Zeitaufwand her).
Ich möchte meinen Sonntagabend gerne anders verbringen, als hier endlos Dinge zu diskutieren, die schon längst klar und ausdiskutiert sind.

Tut mir leid, ich entschuldige mich jetzt, bin nun raus und wünsche Dir trotzdem und in bestem Sinne noch einen schönen Sonntagabend. War nett, mit Dir zu plaudern.
Jemand Anderes kann jetzt hier gerne weitermachen und übernehmen und mit clear endlos weiterdiskutieren, wenn er Lust dazu hat. Weia, wie sieht's diesbzgl. mit Dir aus?

Grob gesagt: Wir diskutieren über die Druckerthematik auf/in macOS im Hinblick auf Catalina.
Und da es da verschiedene Meinungen, viele Fakten und einige Annahmen gibt, ist dies auch kein kurzer Thread.

Aber ich bin deiner Meinung... das machen wir...

Allseits noch einen gefreuten Sonntagabend

Abschliessender, persönlicher Kommentar:
Drucker, die keine weiteren Dateien/Services ausser der korrekten PPD benötigen, sollten in Catalina verwendet werden können.
Dort stellt sich die Frage, ob dies nur für Printer mit eingebauter PS-Funktion gilt oder auch für Nicht-PS-Geräte.
Ich vermute, es werden nur reine PS-Printer laufen.

Die meisten Printer und MFPs werden auf aktualisierte Treiber warten müssen, da die Druckdatei auf dem Rechner generiert wird und dafür (fast sicher) auf Plugins, Frameworks etc. zurückgegriffen wird.

Diese Problematik wird sich zukünftig durch die allseitige Implementierung des IPP-Everywhere erübrigen.

clear?

Hier ist es, u.a. hier kommt CUPS explizit im Ablauf-Diagramm von Apple als Teil des macOS Printing subsystems vor:



Entnommen von:

Apple Developer: Printing Programming Guide for Mac: About Printing on the Mac

Bzw.



Entnommen von:

Apple Developer: Printing Programming Guide for Mac: Printing System Workflow

Bist nun endlich zufrieden, ist das nun endlich zu Deiner Zufriedenheit beantwortet?
Einen schönen Sonntagabend weiterhin. Und einen guten Wochenanfang.

Bin schon lange zufrieden, habe ja (momentan) keine Print-Probleme
Dich lässts anscheinend noch nicht los... grins... danke fürs Nachforschen
Da scheint sich meine Vermutung, dass sich CUPS in/unter der "PrintCore" versteckt, bewahrheitet zu haben.

Abschliessende, persönliche Schlussfolgerung (aktualisiert):
1. Drucker, die keine weiteren Dateien/Services ausser der korrekten PPD benötigen, sollten/müssten problemlos in Catalina verwendet werden können. Dies werden jedoch vermutlich nur PS-Geräte sein, da Non-PS Zusatzplugins nötig macht.

2. PS und Non-PS Drucker, deren Treiber-Bestandteile alle komplett 64bit sind, sollten in Catalina verwendet werden können, falls Catalina nicht anderweitig eine Anpassung erforderlich macht.

3. Non-PS Printer und MFPs werden auf aktualisierte Treiber warten müssen (falls Treiber-Teile noch 32bit sind), da die Druckdatei auf dem Rechner generiert wird und dafür (fast sicher) auf Plugins, Frameworks etc. zurückgegriffen wird.

Diese Problematik wird sich zukünftig durch die allseitige Implementierung des IPP-Everywhere erübrigen.

Nein, warum sollten? Es gibt auch noch andere verbreitete Druckersprachen außer PS. PCL zum Beispiel.

Nein, warum sollten? Nicht jeder Drucker hat Funktionen, die unbedingt nur via Plugin angesprochen werden wollen/können/müssen, es gibt zahlreiche Drucker, die benötigen kein einziges Plugin, um voll umfänglich zu funktionieren, weil der Kern-Treiber bzw. die PPD bereits alles abbildet und ermöglicht, was jener Drucker kann.

Und außerdem gibt es zahlreiche Treiber mit Binär-Plugins, welche entweder bereits nur 64bit sind, oder es sind noch ältere 32bit/64 mach-o fat binaries (Universal Binaries), funktionieren bereits jetzt unter 64bit, weil sie die Binaries für beide Architekturen in sich tragen, und es wird nur die verwendet, die das System benötigt (64bit), der andere Teil (32bit) des Binaries liegt unverwendet brach.

Alles in allem wird hier meines Erachtens um das Thema ein Popanz aufgebaut und ein Schreckenszenario an den Haaren herbeigezerrt (Unsicherheit und Angst aus Unwissenheit?), das der Wirklichkeit doch kaum standhält. Entspannt euch mal. Alles wird gut.

Hast du auf dem Mac schon jemals einen PCL-Treiber gesehen...?? Und ich meine keinen generischen/allgemeinen, sondern Original.
Meine jemals installierten Treiber auf Mac waren allesamt PS-Driver, PCL ist grundsätzlich Windows-Lager.
Und ja, klar kann man einen Generic PCL-Treiber verwenden oder sonstige Hacks und Workarounds machen, aber dann sind wir wieder beim einfachen Standard-Druck, falls es überhaupt funktioniert. Der Computer wurde schliesslich erfunden, um uns Arbeit abzunehmen und nicht, damit wir uns tage-und nächtelang um Druckerthemen kümmern müssen.
Ausschnitt von heise.de
"Drucker ohne PostScript-Modul sprechen in der Regel die alternative Seitenbeschreibungssprache PCL. Falls es sich um einen Schwarzweiß-Drucker handelt, können Sie bei der Druckerinstallation unter „Verwenden“ den Treiber „Allgemeiner PCL-Drucker“ auswählen. Der von OS X vorgeschlagene Treiber ist wie die PPD-Datei des Herstellers ausschließlich für PostScript-Drucker ausgelegt.
Der allgemeine PCL-Treiber kennt jedoch weder Farbdruck noch den maximal bedruckbaren Bereich des Druckers."

Das angeblich an den Haaren herbeigezerrte Schreckensszenario wird spätestens dann aktuell, wenn dich deine Oma abends um 21:16 anruft und nicht mehr drucken kann, weil dieses nervige "Aktualisieren Sie auf macOS Catalina" mit Optionen "Jetzt", Nachher" oder "Morgen" zum Erfolg geführt hat...

Geschweige denn für alle Servicetechniker, die dann ausrücken müssen...

Na, via Treiber. Das ist doch mein Punkt.

Zum eigentlichen Druck benötigt jedes Druckwerk gerasterte Pixeldaten; ein Druckwerk kann kein „PDF“ drucken.

Es gibt genau zwei mögliche Orte, wo ein PDF in gerasterte Pixeldaten konvertiert werden kann: in einem Prozessor in der Druckerhardware, oder in Software auf dem Rechner; letztere Software nennt man „Treiber“.

Jeder Drucker, dem Du direkt ein PDF schicken kannst, ist ein PostScript-Drucker, ob er nun so beworben wird oder nicht. Denn er kann das PDF intern in seiner Hardware in gerasterte Pixeldaten konvertieren, und dazu muss er PostScript können, da PDFs nunmal im Prinzip nichts weiter als komprimierte PostScript-Daten (mit einigen zusätzlichen Vorteilen) sind.

Wenn der Drucker keinen eigenen Prozessor für diese Aufgabe hat, braucht er vom Computer die bereits konvertierten Raster-Pixeldaten; dies besorgt der „Treiber“ auf dem Computer, und das ist eben ein Programm, das für 32 oder 64 Bit geschrieben ist.

Der Datenfluss ist in diesem zweiten Falle wie folgt:

Cocoa-Programm → Cocoa-Printing-Subsytem → CUPS (erzeugt zu druckendes PDF) → CUPS-kompatibler Druckertreiber (wandelt PDF in Rasterdaten) → Rasterdaten, die über Schnittstelle an die Druckerhardware wandern

Bei einem PostScript-fähigen Drucker wäre er:

Cocoa-Programm → Cocoa-Printing-Subsytem → CUPS (erzeugt zu druckendes PDF) → PDF-Daten, die über Schnittstelle an die Druckerhardware wandern

Sein Vorteil ist, das PDF von CUPS direkt verarbeiten zu können. Ein nicht-PostScript-fähiger Drucker kann das ohne eigene Treibersoftware auf dem Computer nicht.

Ohje, da rollen sich einem die Fußnägel hoch!
Reine ASCII PPDs funktionieren ausschließlich mit Postscript-fähigen Drucker . MacOS liefert seit Ewigkeiten einen generischen Postscript-Treiber mit aus, d.h. der eigentliche Treiber ist bereits Teil des Betriebssystems. Dieser Treiber kommuniziert mittlerweile nur noch per lpr-, JetDirect- oder IPP(s)-Protokoll mit dem Drucker (früher war auch noch das AppleTalk Print Protokoll möglich). Die PPD deklariert nur die speziellen Postscript-Eigenschaften des Druckers – mehr nicht, es ist kein Treiber .

Bei Nicht-Postscript-Druckern muss die PPD Verweise auf spezielle Filtern haben, die dann aus dem Poscript-Code druckerspezifische Sprache machen. Das ist bei Nicht-Postscript-Druckern der eigentliche Treiber. Ich sehe nicht, wie man diese Abhängigkeit lso wird, ohne den Support für Nicht-Postscript-Drucker zu eliminieren.

Mein obig genannter betagter Minolta Pagepro rucker versteht bspw. nur PCL5. Ich brauche für den nur die PPD, teilweise von mir per Hand sogar editiert und optimiert, mehr nicht. Funktioniertt einwandfrei und bestens und holt aus dem Drucker das technische maximal Mögliche, das er kann, raus.

Nö. Gewiss nicht! Ganz im Gegenteil. Du verwechselst das mit GDI-Druckern. Ich habe mir den damals gekauft gehabt, um ihn unter Linux via CUPS betreiben zu können, da war CUPS noch von Michael Sweets Firma Easy Software und noch nicht beide von Apple aufgekauft. Den Drucker gab's auch als GDI-Drucker, kam aber deswegen (wegen GDI und Windows-Abhängigkeit) nicht infrage, also die universell und unter Unix prima einsetzbare PCL-Variante gewählt.

Wikipedia (de): Printer Command Language (PCL)
Wikipedia (de): Graphics Device Interface (GDI)

Viele Drucker benötigen aber nix Anderes bzw. die betreffende PPD bildet bereits alles ab, was die können, wozu brauchst Du da mehr? Du unterschätzt PPDs, Du unterschätzt IPP, Du unterschätzt CUPS, und Du überschätzt die teilweise völlig aufgeblasenen Treiber-Pakete (unter Windows ist es teilweiese noch schlimmer als unter macOS, was die Druckerhersteller einem da ales installieren und unterjubeln wollen, das man angeblich alles dringend und unbedingt brauchen soll), die Du vielleicht bisher gewohnt bist und nix Anderes zu kennen scheinst und die Du hier stillschweigend weiterhin als unbedingt notwendig erachtest und voraussetzt. Oft braucht man die gar nicht bzw. braucht nur ein Bruchteil dessen, was sie in sich tragen.

Ein Nicht-Postscript-Drucker kann mit einem PDF rein gar nichts anfangen! Das PDF muss zwingend auf dem Computer in eine druckerverständliche Sprache gewandelt werden. Typischerweise verstehen Nicht-Postscript-Drucker Epson-ESC-Befehle oder HP PCL (das ganze Schreibmaschinen artige Gedöns mal unter den Tisch fallen lassend) und diese Dateien müssen zwingend auf dem Computer erzeugt werden, damit der Drucker sie versteht. Denn der kann mit einem PDF rein gar nichts anfangen. PDFs direkt schlucken nur die Postscript-Drucker mit entsprechend neuem PS-RIP, alle anderen scheitern daran.

Dann hast Du Dir die PPD nie wirklich angeschaut! Diese PPD enthält entweder Verweise auf externe Filter oder enthält diese Filter direkt binärkodiert. Dein Drucker muss zwingend über PCL angesteuert werden, was anderes kann er nicht verstehen.

Aber sischer doch, ich benutze die seit Jahren, kenne die fast auswendig, so oft habe ich die editiert.

Ja. Filter von CUPS. CUPS rastert:

Exakt das ist der eigentliche Druckertreiber!

Nachtrag: Du solltest Dir dringend folgende Seite anschauen .

Jepp.

Jepp.

CUPS fungiert als RIP, CUPS ist ein vollwertiger und umfänglicher Rasterer bzw. Software-RIP. Schon immer gewesen. Deswegen brauchste es auch nicht zwingend im Drucker (außer zur Beschleungung, wenn Du es von einem dafür extra optimierten RIP-Prozessor-Chip rastern lassen willst), nicht mehr bzw. weniger als früher, zumindest unter unixoiden Systemen, die CUPS verwenden – außer eben zur Beschleunigung als Hardware-RIP.

Selbst GDI geht unter Linux/MacOSX. Auch über PPD und Ghostscript. Hier der Ausschnitt aus der PPD für meinen 18 Jahre alten Samsung-Drucker:

Ist aber auch nur für die Standardfunktionen. Aber das reicht mir

Danke für den Hinweis und den Link, aber ich weiß bereits und habe es verstanden, wie das Prinzip und die Verarbeitungskette bzw. das Rastern funktioniert. Ansonsten hätte ich mich zu dem ganzen Thema nicht geäußert und nicht darauf hingewiesen, dass CUPS schon vor einiger Zeit von PostScript auf PDF bei der Verarbeitung der Druckdaten umgestellt hat, das wüsste ich sonst nicht.

stromsparmodus:

Das Foomatic-RIP habe ich früher für diesen Minolta-Drucker auch drin gehabt und von parallel installiert gehabt, nebst von Foomatic generierter PPD (von hier , , ), lange Jahre, bis ich spitz gekriegt hatte, dass ich das gar nicht mehr benötige, weil CUPS das Rastern von Haus aus selber kann mit seinem eigenen RIP – was sich u.a. die Gutenprint-PPDs zunutze machen und es referenzieren, seitdem benutze ich Gutenprint dafür, um mir die PPD ggf. neu zu generieren (i.d.R. lasse ich meine alte einfach übernehmen), einen extra dazu installierten Foomatic-RIP benötige ich seitdem nicht mehr, weil CUPS selber das bereits alles macht und kann.

Hm. Stimmt. Ich glaube unter Linux habe ich auch kein Foomatic. Da musste ich nur die PPD konvertieren. Muss ich direkt mal nachschauen ...

Jetzt musst Du dich aber entscheiden: beide Sätze zugleich können (bezüglich eines spezifischen Druckers) nicht stimmen.

Entweder CUPS gibt Rasterdaten aus oder PostScript bzw. PDF (wie gesagt im Wesentlichen dasselbe). Beides zugleich is’ nich’.

Und an den Vorzügen eines PostScript-fähigen Druckers gegenüber einem nicht PostScript-fähigen hat sich während der gesamten Existenz von CUPS nie etwas geändert; PDF oder PostScript in CUPS ist diesbezüglich völlig schnuppe.

Weia:

Wo widerspricht sich das, wo muss ich mich da entscheiden?
Denn: CUPS verwendet beim Verrbeitungsprozess der Druckdaten standardmäßig kein PostScript mehr sondern verwendet intern PDF, reinkommendes PostScript wird umgewandelt in PDF, beim Drucker kommt kein PostScript mehr an, maximal PDF. Im Fall von meinem Drucker wird, bevor der Datenstrom (CUPS-intern als PDF-Daten vorliegend, weil CUPS selber sie zur eigenen Verarbeitung, zum eigenen Umgang damit in PDF wandelt statt wie früher in PostScrip, CUPS macht diese Wandlung nach PDF statt in PostScript für sich selber) zum Drucker geschickt wird, via CUPS-Filter gerastert und für diesen nach PCL5 übersetzt. Wär's ein PostScript-Drucker, würde er den PDF-Datenstrom unverändert ohne weitere nötige Umwandlung empfangen und drucken können, so muss es zuvor halt gerastert und übersetzt werden.

Er hat ein schnelleres Hardware-RIP in Form eines eigenen Prozessors, ja, und im Zweifel mehr RAM, um Druckdaten zu spoolen. Aber via CUPS kommt dort kein PostScript mehr an, höchstens PDF.
Und wo ist nun der große Unterschied und Vorteil eines PS-Druckers außer, dass sein Prozessor (RIP) PDF nun schneller abarbeiten kann?
Zumal es viele Drucker gibt inzwischen, die durch ihre Firmware PDF-fähig sind, ohne gleich ein voll umfänglicher PostScript-Drucker sein zu müssen, Stichwort: PDF Direct Printing.

Siehe z.B., wahllos rausgegriffen:

OKI: PDF Direct Printing

IBM: Printing PDF Stream Files to an ASCII Laser Printer that Supports Direct PDF Printing

Kyocera: PDF Direct Printing: Kyocera's PDF Direct Print software utility allows users to send PDF (Portable Document Format) files directly to a printer without the need to open the file in Adobe Acrobat or Acrobat Reader and print using a conventional print driver.

[…]

Wo ist da die Rede von PostScript oder dass der betreffende Drucker unbedingt und zwingend ein vollumfänglicher PostScript-Drucker mit PS-RIP ist oder zwingend sein muss, um bei ihm direkt ankommende PDFs direkt auszudrucken? Ein solcher Drucker hat eine Firmware, die kann PDFs direkt verarbeiten und ausdrucken, möglicherweise ist das dann eine Firmware nebst Chip, die so ähnlich wie ein PostScript-Prozessor arbeitet und geartet ist, nur auf viel weniger komplexem Niveau, also ein PDF-Prozessor (Chip), weniger komplex, evtl. preiswerter herzustellen als ein viel komplexerer PS-Chip. Wozu auch mehr? Mehr kommt doch eh nicht an, es kommt doch eh maximal PDF an am Drucker und eh kein PostScript, zumindest, wenn von CUPS aus gesendet.

Der einzige Vorteil eines vollwertigen PostScript-Druckers ist sein eigener Prozessor nebst Firmware, die PostScript hart verdrahtet in sich trägt. Und dadurch schneller ist als eine Software-Lösung. Und wenn andere Drucker das inzwischen auch können und diesbzgl. hart verdrahtet und optimiert sind, nur eben nicht bzgl. PostScript sondern bzgl. des leichter zu handelnden und weiter verbreiteten PDF? Wozu braucht's da noch einen explizit ausgewiesenen PostScript-Drucker?

Aber was CUPS intern tut, ist doch für unsere Belange komplett wumpe. Wichtig ist doch ausschließlich, was – um den großen Helmut Kohl zu zitieren – hinten raus kommt.

Und das sind entweder Rasterdaten oder PDF/PostScript.

Du hast immer wieder die CUPS-Umstellung von PostScript zu PDF betont. Aber die ist überhaupt nur für PostScript-Drucker relevant, denn nur die bekommen von der Umstellung was mit (nämlich, dass sie plötzlich PDF- statt PostScript-Dateien erhalten). Für die anderen Drucker – und nur um die geht es doch im Zusammenhang mit der 32- vs. 64-Bit-Problematik – ändert sich nix; sie kriegen stets dieselben Rasterdaten.

Also: Entweder reden wir über PostScript-fähige Drucker; dann ist die Umstellung von PostScript auf PDF zumindest eine Randnotiz wert (mehr aber auch nicht, weil das Pi mal Daumen sowieso dasselbe ist), aber dann spielt die 32/64-Bit-Problematik, um die es hier ging, keine Rolle. Oder wir reden über nicht-PostScript-fähige Drucker mit Software-RIP mit 32/64-Bit-Problematik; aber dann spielt PDF vs. PostScript in CUPS keine Rolle.

Bei Dir klang das aber so, als wären zu den Zeiten, wo CUPS intern noch PostScript nutzte, PostScript-Drucker im Vorteil gewesen, aber nach der Umstellung von CUPS nicht mehr, weil irgendwie jeder Drucker magisch PDF verstehen würde. Und das ist eben falsch. PostScript-fähige und PDF-fähige Drucker sind ein und dasselbe, und sie haben jetzt genau dieselben Vorzüge gegenüber anderen Druckern, wie sie schon zu Zeiten hatten, als CUPS noch PostScript verwendete, nur hat all das nichts mit den nicht-PostScript-fähigen Druckern zu tun, um die es hier geht.

Alle nicht PostScript-fähigen Drucker verstehen auch kein PDF und sind wie eh und je auf Software-RIPs (vulgo „Treiber“) angewiesen.
Das sind PostScript-Drucker.
Nirgendwo, aber das sind Marketing-Texte und daher irrelevant (jeder kennt heute PDF, wer kennt noch PostScript?). Du kannst ohne einen PostScript-Interpreter kein PDF auslesen.
Wie kommst Du darauf, PDF sei „viel weniger komplex“ als PostScript? Das ist (fast) dasselbe, und wenn überhaupt, ist PDF komplexer (Transparenz, direkter Seitenzugriff, Formularfunktionen, …). Die einzige Stelle, wo PostScript komplexer als PDF ist, ist, dass es eine Turing-vollständige Programmiersprache ist. Aber das spielte für Drucker praktisch keine Rolle.

Jein. Denn, was maximal rauskommt, hat sich geändert, eben weil sich intern was geändert hat.

Richtig. Und das ist eben im Gegensatz zu früher standardmäßig nicht mehr PostScript – es sei denn, man lässt es extra nochmal von PDF nach PS wandeln.

Nein, eben nicht mehr PostScript. PDF oder Rasterdaten. Nix PostScript mehr.
Wer PostScript haben will, muss es sich anschließend wohl wieder per Filter von PDF wandeln lassen, aber standardmäßig ist PostScript in der ganzen Verarbeitungskette und als Endprodukt da nicht mehr drin, ist komplett rausgenommen, aus diversen Gründen. Die Argumente, warum, was für PDF als Standard-Verarbeitungsformat in CUPS spricht und gegen PostScript, u.a. auch Sicherheitsgründe, hat Michael Sweet genannt und sie werden unter LinuxPrinting.org auch nochmal ausgeführt und genannt.


U.a. deswegen hat Apple auch damals für Quarz von NeXTs Display PostScript auf Display PDF gewechselt bzw. sein gesamtes System PDFisiert statt es bei PostScript zu belassen wie bei Unix eigentlich üblich. Es waren nicht nur Lizenzgründe, es war auch die geringere Komplexität von PDF gegenüber PostScript und im Grunde Overkill für das was benötigt wird.
Verstehe mich bitte nicht falsch: ich bin ein großer Freund von PostScript, aber ich nehme auch zur Kenntnis, dass da wohl ein Wandel stattgefunden hat (bei Schriften genauso, PostScript PS1-Schriften werden kaum noch verwendet, geschweigedenn referenziert geschweigedenn weiterentwickelt, TrueType/OpenType bzw. immer mehr auch SVG-Schriften haben schon lange das Ruder übernommen, auch unter Unix-Systemen, den einstigen Hochburgen von PostScript und PS1-Schriften) und eine Verschiebung und noch weiterhin grad' stattfindet, und dass es seine große Zeit wohl hinter sich hat und PDF ihm da Einiges an Rang und Relevanz abgelaufen hat, nicht zuletzt auch dank und durch Apple.

Ja, geschenkt. PDF/PostScript war eine Kurzform für früher PostScript/jetzt PDF. Aber ich verstehe nicht, warum Du darauf wieder und wieder herumreitest, denn PostScript oder PDF ist für den hiesigen Diskussionskontext vollkommen egal, weil beiden gemeinsam ist, dass sie nur mit PostScript-Druckern funktionieren, während das ganze 32/64-Bit-Problem, um das es hier geht, nur die übrigen Drucker betrifft, die ein Software-RIP benötigen. Und für die hat sich, seit es CUPS gibt, nichts geändert, definitiv jedenfalls nichts durch die CUPS-interne Umstellung von PostScript auf PDF.

Ich reite nicht drauf rum, ich unterscheide lediglich zwischen PDF und PostScript. Das eine ist PDF, das Andere ist PostScript, und das Eine bedarf nicht zwingend das Andere. As simple as that.
Rest: geschenkt.

PostScript-Daten an Drucker? Zwingend ein PostScript-Drucker notwendig? Nein. Gerastert und übersetzt geht immer. Nicht übersetzt sondern direkt: geht nur mit PostScript-Drucker.
PDF-Daten an Drucker? Zwingend ein PostScript-Drucker notwendig? Nein. Nicht zwingend. Gerastert geht immer. Und wenn direkt: ein PDF-Direct-Drucker heißt so, weil er direkt PDF verarbeiten kann – könnte er PostScript direkt verarbeiten, hieße er PostScript-Drucker (und wäre zudem sicher um ein paar Euronen teurer).
Abgesehen davon: auch ein PostScript-Drucker rastert die ankommenden PostScript-Daten via PostScript-Interpreter, bevor er diese dann als Raster-Image dann tatsächlich ausdruckt.
Gerastert wird also in jedem Fall.

CUPS IST bereits ein Software RIP bzw. stellt RIP-Funktionalitäten zur Verfügung.
Und was hat 32/64bit damit zu tun? Nix.
Evtl. Plugins, die evtl. für den einen oder anderen Drucker installiert sind und binär unter /Library/Printers liegen, die könnten berührt sein. Wenn so alt, dass nur als 32bit Binaries für das jeweilige Plugin vorliegend und noch nicht mal wenigstens als 32/64bit Universal Binary, sodass das System davon wenigstens den 64bit-Teil verwenden kann. Doch nicht jeder Drucker hat Plugins nötig, nicht jeder braucht welche, es gibt viele, die kommen ohne aus. Und dann gibt es sicher einige, deren Plugins liegen bereits als 64bit Binaries vor.

Ich habe weiter oben doch schon längst deutlich gemacht gehabt in Richtung clear: calm down. Warum überhaupt die ganze Aufregung?

Ich habe PostScript und PDF nur ins Gespräch gebracht, weil ihr zu Anfang das zum Thema machtet und so sehr auf PostScript und seiner angeblichen Wichtigkeit herumgeritten seit und aMacUser so vehement widersprochen habt in dieser Hinsicht. Ich wollte ihm damit nur zur Seite springen und drauf aufmerksam machen, dass PostScript aus der Verarbeitungskette von CUPS inzwischen entfernt worden ist, da gar kein PostScript mehr standardmäßig rauskommt wie lange Jahre zuvor üblich, sondern eben PDF und dass das beim Drucker standardmäßig nicht als PostScript ankommt, selbst wenn es beim Drucken reingeschickt worden ist – es wird von CUPS dann automatisch in PDF gewandelt, bevor es zum Drucker geht – PostScript-Drucker hin oder her, bei ihm kommt standardmäßig gar kein reines PostScript mehr an, so wie es zuvor reingegeben wurde, wenn via CUPS empfangen, weil CUPS zuvor automatisch ein PDF daraus macht.

Diese ganze PostScript-Diskussion ist von euch losgetreten worden, nicht von mir. Ich wollte sie durch meinen Beitrag eigentlich entschärfen, ihr die Relevanz entziehen, die ihr ihr gegeben hattet, um aMacUser zu widersprechen und die Relevanz von PostScript in dem ganzen Prozess relativieren, einen neuen Aspekt reinbringen. Dieser Schuss von mir ist diesbzgl. wohl leider nach hinten losgegangen und mir stattdessen von euch um die Ohren gehauen worden. Tut mir leid.

Ich gehe jetzt schlafen. Gute Nacht.

Ja, aber warum, wenn der Unterschied für das Thema hier keine Rolle spielt?
Logo, aber dann werden keine PostScript-(oder PDF-)Daten mehr an den Drucker gesandt, sondern Raster-Daten.

Werden PostScript-Daten an den Drucker gesendet, ist zwingend ein PostScript-Drucker notwendig.

Soll das vermieden werden, braucht es einen Software-RIP, damit Raster-Daten an den Drucker gesendet werden können. Der kann in 32 Bit oder 64 Bit implementiert sein. Und nur um dieses Problem geht es hier.
Nö, weil das heutigen Käufern nix mehr sagt und PDF das viel bessere Argument ist.
Logo, aber er tut dies in der Drucker-Hardware, und der ist es egal, ob macOS mit 32 Bit oder 64 Bit läuft.
Alles. Denn es hängt von der Drucker-PPD ab, ob der Hersteller dem CUPS-RIP vertraut oder lieber seinen eigenen verwenden will. In letzterem Fall ist entscheidend, ob der RIP des Druckerherstellers unter 32 Bit oder 64 Bit läuft.
Klar, bei 99% der Drucker ist das so. Das Problem, über das wir hier reden, ist eher prinzipieller Natur als praxisrelevant, denn nur uralten und superbilligen Druckern fehlt 64-Bit-Software.
… was PostScript in disguise ist und außerdem egal …
Gute Nacht!