117471
03.01.2021, aktualisiert am 24.08.2022
4430
9
2
RaspberryPi als Printserver für einen HP-Laserjet - Meinungen, Vorschläge usw
Hallo,
in meinem Blog unter altmetaller.de: RaspberryPi als Printserver für einen HP Laser 107w RAW Drucker beschreibe ich, wie ich einen alten RasPi als Printserver nutze und die Treiber dafür über die print$ Freigabe verteile.
Die Infos dazu habe ich mir in diversen Anleitungen zusammengesucht, irgendwie findet man überall nur Brocken / Teilaspekte beschrieben oder die Lösung erschlägt schlichtweg an Komplexität (RasPi als DC, Gruppenrichtlinien usw. usf.).
Was haltet Ihr von der Vorgehensweise? Seht Ihr da irgendwo Optimierungsbedarf?
Gruß,
Jörg
in meinem Blog unter altmetaller.de: RaspberryPi als Printserver für einen HP Laser 107w RAW Drucker beschreibe ich, wie ich einen alten RasPi als Printserver nutze und die Treiber dafür über die print$ Freigabe verteile.
Die Infos dazu habe ich mir in diversen Anleitungen zusammengesucht, irgendwie findet man überall nur Brocken / Teilaspekte beschrieben oder die Lösung erschlägt schlichtweg an Komplexität (RasPi als DC, Gruppenrichtlinien usw. usf.).
Was haltet Ihr von der Vorgehensweise? Seht Ihr da irgendwo Optimierungsbedarf?
Gruß,
Jörg
Auf Facebook teilen
Auf Twitter teilen
Auf Reddit teilen
Auf Linkedin teilenBitte markiere auch die Kommentare, die zur Lösung des Beitrags beigetragen haben
Content-ID: 637211
Url: https://administrator.de/imho/raspberrypi-als-printserver-fuer-einen-hp-laserjet-meinungen-vorschlaege-usw-637211.html
Ausgedruckt am: 22.12.2024 um 12:12 Uhr
9 Kommentare
Neuester Kommentar
Moin,
ich betreibe die Pis als "RIP", d.h. die Drucker werden ganz normal angeschlossne udn eingerichtet und werden dann als Internet-printerm, cifs oder per lpr freigegeben und als Postcript oder PCL-Drucker eingerichtet.
lks
ich betreibe die Pis als "RIP", d.h. die Drucker werden ganz normal angeschlossne udn eingerichtet und werden dann als Internet-printerm, cifs oder per lpr freigegeben und als Postcript oder PCL-Drucker eingerichtet.
lks
Hallo,
Dann hast Du den Abschnitt bezüglich der Motivation noch nicht gelesen
Die Hersteller sparen, wo sie nur können. Im unteren und mittleren Preissegment gibt es immer mehr Drucker, die weder PS, noch PCL (5 oder 6) können. Vermutlich werden da irgendwo Lizenzgebühren fällig. Anzumerken wäre auch, dass das Rendering auf dem RasPi schnell zur Qual wird. Meine letzte Erfahrung lautete gefühlt auf 5 Sekunden pro Seite.
5 Seiten pro Sekunde wäre mir lieber.
Gruß,
Jörg
Zitat von @Lochkartenstanzer:
ich betreibe die Pis als "RIP", d.h. die Drucker werden ganz normal angeschlossne udn eingerichtet und werden dann als Internet-printerm, cifs oder per lpr freigegeben und als Postcript oder PLC-Drucker eingerichtet.
ich betreibe die Pis als "RIP", d.h. die Drucker werden ganz normal angeschlossne udn eingerichtet und werden dann als Internet-printerm, cifs oder per lpr freigegeben und als Postcript oder PLC-Drucker eingerichtet.
Dann hast Du den Abschnitt bezüglich der Motivation noch nicht gelesen
Die Hersteller sparen, wo sie nur können. Im unteren und mittleren Preissegment gibt es immer mehr Drucker, die weder PS, noch PCL (5 oder 6) können. Vermutlich werden da irgendwo Lizenzgebühren fällig. Anzumerken wäre auch, dass das Rendering auf dem RasPi schnell zur Qual wird. Meine letzte Erfahrung lautete gefühlt auf 5 Sekunden pro Seite.
5 Seiten pro Sekunde wäre mir lieber.
Gruß,
Jörg
Zitat von @117471:
Hallo,
Dann hast Du den Abschnitt bezüglich der Motivation noch nicht gelesen
Die Hersteller sparen, wo sie nur können. Im unteren und mittleren Preissegment gibt es immer mehr Drucker, die weder PS, noch PCL (5 oder 6) können.
Hallo,
Zitat von @Lochkartenstanzer:
ich betreibe die Pis als "RIP", d.h. die Drucker werden ganz normal angeschlossne udn eingerichtet und werden dann als Internet-printerm, cifs oder per lpr freigegeben und als Postcript oder PLC-Drucker eingerichtet.
ich betreibe die Pis als "RIP", d.h. die Drucker werden ganz normal angeschlossne udn eingerichtet und werden dann als Internet-printerm, cifs oder per lpr freigegeben und als Postcript oder PLC-Drucker eingerichtet.
Dann hast Du den Abschnitt bezüglich der Motivation noch nicht gelesen
Die Hersteller sparen, wo sie nur können. Im unteren und mittleren Preissegment gibt es immer mehr Drucker, die weder PS, noch PCL (5 oder 6) können.
Genau deswegen, macht das der Pi. Das Problem ist meistens die richtigen RAW-Treiber für den Pi zu finden.
lks
Hallo,
Nein, der Pi macht das nicht und für RAW benötigst Du keine Treiber und genau dieses Szenario (kein Treiber für den Pi vorhanden) beschreibe ich ja in der Anleitung.
Vielleicht solltest Du sie mal lesen - Du kannst da offenbar auch noch was lernen
Gruß,
Jörg
Zitat von @Lochkartenstanzer:
Genau deswegen, macht das der Pi. Das Problem ist meistens die richtigen RAW-Treiber für den Pi zu finden.
Genau deswegen, macht das der Pi. Das Problem ist meistens die richtigen RAW-Treiber für den Pi zu finden.
Nein, der Pi macht das nicht und für RAW benötigst Du keine Treiber und genau dieses Szenario (kein Treiber für den Pi vorhanden) beschreibe ich ja in der Anleitung.
Vielleicht solltest Du sie mal lesen - Du kannst da offenbar auch noch was lernen
Gruß,
Jörg
Cool. Danke, wer weiß, wann man das mal einsetzen kann. Den uralten Plotter, für den es interessant gewesen wäre gibts nicht mehr.
Über nen entsprechenden Raspi erhalten die Geräte damit auch 5Ghz und Airprint-Funktionalität.
Über nen entsprechenden Raspi erhalten die Geräte damit auch 5Ghz und Airprint-Funktionalität.
Hallo,
genau darum geht es ja nicht. Sondern vielmehr um die SMB-Anbindung und die Treiberverteilung über den Server.
Die gegenteilige Lösung (manuelle Treiberinstallation direkt über CUPS) findest Du überall beschrieben. Unter Anderem auch in dem von Dir verlinkten, urheberrechtlich geschützten und hoffnungslos veralteten Artikel
Gruß,
Jörg
genau darum geht es ja nicht. Sondern vielmehr um die SMB-Anbindung und die Treiberverteilung über den Server.
Die gegenteilige Lösung (manuelle Treiberinstallation direkt über CUPS) findest Du überall beschrieben. Unter Anderem auch in dem von Dir verlinkten, urheberrechtlich geschützten und hoffnungslos veralteten Artikel
Gruß,
Jörg
und hoffnungslos veralteten Artikel
Rennt aber dennoch fehlerlos mit dem aktuellsten RasperryOS. Hat sich ja auch nicht wirklich was am CUPS geändert. OK, Treiberverwaltung covert das natürlich nicht, da hast du in der Tat recht.
Hallo,
Nicht unbedingt. Die Hersteller sind - gerade bei neuen Geräten - relativ zurückhaltend mit Treibern für 32 Bit ARM Architekturen. Und, wie ich ebenfalls schon schrieb: Es gibt inzwischen zahlreiche Geräte, die nur noch proprietär angesteuert werden.
In dem Artikel wird ein Treiber auf dem Printserver installiert, was aber extrem dumm ist!
Hier entstehen Effekte, die man so nicht auf dem Zettel hat. Gerade viele der offenen Linux-Treiber basieren z.B. auf Postscript. Die Windows-Treiber liefern jedoch PCL (5 oder 6). Sprich - dein Windows-Treiber rendert nach PCL, der Printserver rendert das noch mal nach Postscript um.
Ich habe schon viele Beispiele gesehen, bei denen so etwas zu "inakkuraten" Druckergebnissen geführt hat. Gerade senkrechte Linien verschwinden gerne einmal. Stell' mal so ein Teil in eine Klinik, die Röntenbilder oder EKGs ausdruckt - die schmeißen Dir das Ding aus 20 Meter Entfernung an den Kopf.
Auch gibt es Situationen, in denen die Treiber der Hardware "entgegenrechnen" - zum Beispiel beim Dithering. Wenn Dir da zwei externe Verfahren dazwischeninterpretieren, kommt häufig Müll raus, den Du auf den ersten Blick gar nicht als Solchen erkennst. Zum Beispiel Moiré Effekte oder exorbitant hoher Tonerverbrauch; gerade bei großflächigen Graustufen.
Kurzum: Genau das, was in der c't steht, ist so ziemlich der gröbste Schnitzer, den man in dem Zusammenhang machen kann: Bei der Aufbereitung kommt im Idealfall ein (einziges!) Rendering zum Einsatz. Und wenn man mit dem Betriebssystem eh' schon eine Closed Source Krücke a 'la Windows fährt, dann kann man auch ruhig den Treiber bzw. das Rendering nutzen, dass vom (Hardware-)Hersteller kommt. Der weiß nämlich letztendlich am Besten, wie die Hardware betankt wird
Wie gesagt - das, was in dem verklinkten Artikel steht, ist nich nur veraltet, sondern hat maximal die Qualität von "Ich muss noch 'ne Seite vollkriegen, klick' mal ein bisschen rum, schreib' irgendwas auf und nach mir die Sintflut". Ich bin immer wieder erschrocken, was gerade bei der c't herauskommt
Gruß,
Jörg
Nicht unbedingt. Die Hersteller sind - gerade bei neuen Geräten - relativ zurückhaltend mit Treibern für 32 Bit ARM Architekturen. Und, wie ich ebenfalls schon schrieb: Es gibt inzwischen zahlreiche Geräte, die nur noch proprietär angesteuert werden.
In dem Artikel wird ein Treiber auf dem Printserver installiert, was aber extrem dumm ist!
Hier entstehen Effekte, die man so nicht auf dem Zettel hat. Gerade viele der offenen Linux-Treiber basieren z.B. auf Postscript. Die Windows-Treiber liefern jedoch PCL (5 oder 6). Sprich - dein Windows-Treiber rendert nach PCL, der Printserver rendert das noch mal nach Postscript um.
Ich habe schon viele Beispiele gesehen, bei denen so etwas zu "inakkuraten" Druckergebnissen geführt hat. Gerade senkrechte Linien verschwinden gerne einmal. Stell' mal so ein Teil in eine Klinik, die Röntenbilder oder EKGs ausdruckt - die schmeißen Dir das Ding aus 20 Meter Entfernung an den Kopf.
Auch gibt es Situationen, in denen die Treiber der Hardware "entgegenrechnen" - zum Beispiel beim Dithering. Wenn Dir da zwei externe Verfahren dazwischeninterpretieren, kommt häufig Müll raus, den Du auf den ersten Blick gar nicht als Solchen erkennst. Zum Beispiel Moiré Effekte oder exorbitant hoher Tonerverbrauch; gerade bei großflächigen Graustufen.
Kurzum: Genau das, was in der c't steht, ist so ziemlich der gröbste Schnitzer, den man in dem Zusammenhang machen kann: Bei der Aufbereitung kommt im Idealfall ein (einziges!) Rendering zum Einsatz. Und wenn man mit dem Betriebssystem eh' schon eine Closed Source Krücke a 'la Windows fährt, dann kann man auch ruhig den Treiber bzw. das Rendering nutzen, dass vom (Hardware-)Hersteller kommt. Der weiß nämlich letztendlich am Besten, wie die Hardware betankt wird
Wie gesagt - das, was in dem verklinkten Artikel steht, ist nich nur veraltet, sondern hat maximal die Qualität von "Ich muss noch 'ne Seite vollkriegen, klick' mal ein bisschen rum, schreib' irgendwas auf und nach mir die Sintflut". Ich bin immer wieder erschrocken, was gerade bei der c't herauskommt
Gruß,
Jörg
