CUPS Einstellungen

Deutsch (German) Hardware
61

Hallo GrandDixence2,

CUPS hat kein Filter für *.odt. Somit akzeptiert CUPS keine .odt-Dateien. Jedoch akzeptiert CUPS PDF-Dateien (.pdf). Bitte noch einmal die Beiträge zum Themas “CUPS-Filter” durchlesen.

Da
Danke für Deinen Hinweis. Ich habe das einfach übersehen, da ich noch keine Erfahrung mit dem Drucken über Konsole habe.

Ein Druck von Konsole hat jetzt geklappt.

**Tuxedo2020:/home/suse_user1 #** lp -d OKI_B401d /home/suse_user1/Dokumente/tesseract/Tobler_test_1.pdf 
Anfrage-ID ist OKI_B401d-124 (1 Datei(en))


**Tuxedo2020:/home/suse_user1 #** lp -d OKI_B401d -o media=A4 -o sides=two-sided-long-edge /home/suse_user1/Dokumente/tesseract/Tobler_test_1.pdf 
Anfrage-ID ist OKI_B401d-121 (1 Datei(en))

Formatierung des Text-Dokuments:
A4
Kopfzeile mit Seitenzahl
Seitenlayout: gespiegelt (siehe Bild)
Seitenränder: Außen 1 cm, Innen 3cm (siehe Bild)

Bild:
https://paste.opensuse.org/96454269SUSE Paste
SUSE Paste

Ein einseitiger Druck über 2 Seiten liefert auf Seite 1, genau gedruckte Seitenränder links/rechts, wie im PDF-Dokument. Auf Seite 2, um ca. 4mm verschobene Seitenränder links/rechts in eine Richtung.
Ein Duplex-Druck über 2 Seiten liefert auf Seite 1, genau gedruckte Seitenränder links/rechts, wie im PDF-Dokument. Auf Seite 2, um ca. 6mm verschobene Seitenränder links/rechts in eine Richtung, wobei die Verschiebung auf allen ungeraden Seiten und auch greaden Seiten nach rechts geht. Das wirkt sich bei Duplex entgegengesetzt aus, da Rechts für Vorder- und Rückseite entgegengesetzt ist.
Bei einem Duplex-Druck über 4 Seiten bleibt der Fehler für jeweils ungerade und gerade Seitenzahlen regelmäßig.

Mein erster verdacht war, dass die Duplex-Funktion nicht sauber im *.ppd speziell für meinen Drucker (OKI B410d) beschrieben ist.
OKI B410 PPD sollte laut “OpenPrinting” perfekt funktionieren - das tut er aber nicht. Andere ähnliche Treiber, die ich ausprobiert habe haben das gleiche Problem.
Deshalb glaube ich immer mehr, dass CUPS hier das Problem macht.

Auch wenn ich das Text-Dokument ohne Seitenlayout=gespiegelt sondern Standard= Rechts/Links und die Seitenränder Innen/Außen gleich wähle (2cm), sind die Seitenränder im Duplex-Druck auf der Vorder- und Rückseite verschoben.

Hier stimmt was nicht mit Berechnung bei der PCL-Emulation !? Ist da CUPS daran beteiligt?

62

Hallo,

ich habe überraschender Weise festgestellt, dass ich den empfohlenen Treiber von OpenPrinting noch nicht ausprobiert hatte. Das war meinerseits ein Irrtum. Ich habe mich von der Benennung “OKI B410” irreführen lassen. Mir war dabei nicht klar, dass dieser Treiber der weiter unten an erster Stelle aufgeführte Treiber mir Namen “pxlmono” und “Recommended driver” der oben unter “OKI B410” angebotene Treiber ist. Leider sind auch noch weitere Treiber unter der Beschreibung “OKI B410” zu finden, so dass ich dachte es sei alles das selbe.

Also habe ich nun diesen “plxmono” herunter geladen und in das Verzeichnis /usr/share/cups/model/gutenprint/5.2/C [FONT=arial]abgelegt. Kann sein, dass dieses Verzeichnis nur für Gutenprint gedacht ist. Der “pxlmono” Treiber ist ein Foomatic Treiber. Jedenfalls lässt sich der Treiber über YAST installieren.
Worüber ich freudig überrascht war ist, dass der Treiber unter gewissen Bedingungen ein gutes Ergebnis über CUPS liefert. Der Duplex-Druck aus LibreOffice Writer klappt gut. Minimale Abweichungen des Druckbereichs zwischen Vorder- und Rückseite. Der Duplex-Druck von einem PDF macht jedoch wieder Schwierigkeiten. Hier sind wieder Verschiebungen zwischen linken/rechten Seitenrand.
Mit dem gleichen Treiber aus der Konsole gelingt das Text-Dokument aus [FONT=monospace][FONT=arial]LibreOffice Writer und als PDF gleichemaßen gut.

Als weiteren Versuch habe ich den von vom Hersteller OKI angebotenen Treiber für Linux herunter geladen und installiert. Damit waren, egal wie ich einen Duplex-Druck erstellt habe, alle Ergebnisse so schlecht wie auch mit den anderen Treibern die ich schon zuvor probiert hatte.

Ich sehe dabei noch nicht ganz klar was sich hier abspielt, aber vermute, dass der Druckbereich und der Seiteninhalt für die geraden Seiten anders, etwas unterschiedlich berechnet werden. Das komplette Text-Bild einer Seite ist wahrscheinlich nur eine Berechnung der originalen Text-Datei. Je nach dem, wie genau diese Berechnung durchgeführt wird, desto exakter die Gleichheit zum digitalen Original.
Meine Frage dazu wäre, wo könnte man hier selbst Justierungen vornehmen ?? In der PPD-Datei habe ich dazu nichts finden können.[/FONT]
[/FONT][/FONT]

63

Ich nehme an, du druckst immer noch Hardware-Rand. Dann ist es für den ‘Spiegel-Druck’ unabdingbar, diesen Rand links und rechts gleich groß einzustellen. Beispiel mein MFC255CW:

[FONT=monospace]**erlangen:~ #** grep A4 /opt/brother/Printers/mfc255cw/cupswrapper/brother_mfc255cw_printer_en.ppd 
*PageSize **A4**/**A4**:                                        "          " 
*PageSize Br**A4**_B/**A4** (Borderless):                       "          " 
*PageRegion **A4**/**A4**:                                      "          " 
*PageRegion Br**A4**_B/**A4** (Borderless):                     "          " 
***ImageableArea **A4**/**A4**:                                                   "14     14      581     825" 
***ImageableArea Br**A4**_B/**A4** (Borderless):                  "1      1       595     838" 
*PaperDimension **A4**/**A4**:                          "595 842" 
*PaperDimension Br**A4**_B/**A4** (Borderless):                 "595 842" 
*UIConstraints: *BRColorMediaType Transparencies        *PageSize Br**A4**_B 
**erlangen:~ #**[/FONT]

Mit den obigen Einstellungen druckt er das zweiseitige Dokument etwas verkleinert, aber deckungsgleich.

64

Gemäss:
https://www.openprinting.org/printer/Oki/Oki-B410
gibt es 5 mehr oder weniger brauchbare PLC5e-Filter. 4 sind in Ghostscript integriert (pxlmono, lj4dith, ljet4 und ljet4d). Einer wird via IJS von Ghostscript aus externen Quellen (HPIJS) geholt (hpijs-pcl5). Wenn man im Webbrowser auf die in grösserer Schriftgrösse geschriebene Bezeichnung des Filters mit der Maus klickt, erscheint im Webbrowser eine Webseite mit Detailinformationen des jeweiligen Filters. → Immer brav nach unten scrollen…

Es wäre wohl angebracht, die Drucker entsprechend den PCL5e-Filtern zu bezeichnen. Und dann einen Blick ins Verzeichnis /etc/cups/ppd zu werfen, was sich auf dieser Linux-Installation bereits für Druckvorgänge verwendete PPD-Dateien tummeln.

Weiter sollten die CUPS-Standard-Druckeinstellungen kontrolliert werden. Ich mach das bequem über die GNOME-Einstellungen. Geht aber auch sicher unter KDE oder über den Webbrowser mit der Adresse: https://localhost:631 oder http://localhost:631
Zum Beispiel steht beim Filter lj4dith geschrieben:

Replacement for the ljet4 Ghostscript driver intended to enhance the image output quality with Floyd-Steinberg dithering. Unfortunately, this driver has problems with the margins. The document is not placed exactly at the same position as with the “ljet4” driver. The page seems to be shifted to the upper right, probably due to the upper and right unprintable borders not taken into account. Therefore the driver is not used any more together with “ljet4” in the same PPD files, with an option to switch between the two. To get higher output quality you can set Well-Tempered screening when you use the “ljet4” driver with Ghostscript 8.x or later, which is the recommended replacement for “lj4dith”. Or use HPIJS or Gimp-Print.

65

Heute können praktisch alle Drucker Postscript und PCL. “Drucker” meint in diesem Kontext auch “Postscript Printer Definition”.

Weiter sollten die CUPS-Standard-Druckeinstellungen kontrolliert werden. Ich mach das bequem über die GNOME-Einstellungen.

Ich komme von CDE/HP-UX. Da ist Gnome PITA. :wink: Darum verwende ich KDE > Kontrollleiste > Systemabschnitt > Drucker > Modell auswählen > Drucker einrichten.

66

Hallo,

@karlmistelberger

ch nehme an, du druckst immer noch Hardware-Rand. Dann ist es für den ‘Spiegel-Druck’ unabdingbar, diesen Rand links und rechts gleich groß einzustellen. Beispiel mein MFC255CW:
Code:
[FONT=monospace]erlangen:~ # grep A4 /opt/brother/Printers/mfc255cw/cupswrapper/brother_mfc255cw_printer_en.ppd
*PageSize A4/A4: " "
*PageSize BrA4_B/A4 (Borderless): " "
PageRegion A4/A4: " "
PageRegion BrA4_B/A4 (Borderless): " "
ImageableArea A4/A4: “14 14 581 825”
ImageableArea BrA4_B/A4 (Borderless): “1 1 595 838”
*PaperDimension A4/A4: “595 842”
*PaperDimension BrA4_B/A4 (Borderless): “595 842”
*UIConstraints: *BRColorMediaType Transparencies *PageSize BrA4_B
**erlangen:~ #
**[/FONT]
Mit den obigen Einstellungen druckt er das zweiseitige Dokument etwas verkleinert, aber deckungsgleich.

Also ich habe ich habe wieder lang getestet.
Ich bin zu dem Ergebnis gekommen, dass beim Installieren des Drucker-Treibers das A4 Format überall in der PPD-Datei als default gesetzt wird, wenn man bei der YAST Installation die Option “Standardpapierformat A4” setzt.
Die “Imageable Area” habe ich in X-Richtung um 5 Einheiten verändert. Der Duplex-Druck war jedoch unverändert. Auch die Testseite aus CUPS behielt seine Werte für “Imageable Area”.
Die “Imageable Area” ist doch nur die Fläche die auf dem A4 Papier maximal bedruckt werden kann. Dabei wird damit aber nicht bestimmt wo der Textrand (Software-Rand) innerhalb dieser Fläche konkret liegt. Die “Imageable Area” kann über die 2 Punkte x/y unten links und oben rechts eingestellt werden. Was mich dabei wundert ist, dass eigentlich nur der Rand links und unten von dem A4 wegfallen. Der Rand rechts und oben geht immer bis zur Blattkante. Um das festzustellen braucht man nur die X/Y-Werte der Punkte unten links und oben rechts zu addieren. Das Ergebnis ist immer X/Y = 210/297 mm.
Meine Vorstellung war, dass ein Rand vor allem wegen der Mindestränder des Druckers, um das Blatt transportieren zu können, freigehalten werden muss. Anscheinend ist das gar nicht so wichtig.

Obwohl in CUPS “Page Size” A4 eingestellt ist, steht auf der Test-Seite 197,2x271,6 mm. Auch das stimmt irgendwie nicht überein.

CUPS:
https://paste.opensuse.org/11209820

*DefaultImageableArea: A4
*ImageableArea Letter/US Letter: "18 36 594 756"
*ImageableArea A4/A4: "18 36 577 806"
*ImageableArea 11x17/11x17: "18 36 774 1188"
*ImageableArea A3/A3: "18 36 824 1155"
*ImageableArea A5/A5: "18 36 403 559"
*ImageableArea B5/B5 (JIS): "18 36 498 693"
*ImageableArea Env10/Envelope #10: "18 36 279 648"
*ImageableArea EnvC5/Envelope C5: "18 36 441 613"
*ImageableArea EnvDL/Envelope DL: "18 36 294 588"
*ImageableArea EnvISOB5/Envelope B5: "18 36 481 673"
*ImageableArea EnvMonarch/Envelope Monarch: "18 36 261 504"
*ImageableArea Executive/Executive: "18 36 504 720"
*ImageableArea Legal/US Legal: "18 36 594 972"

Vielleicht stellt die “Page Region” eher den Ausschnitt dar, wo die Lage des Text-Blockes (software-Ränder) auf dem A4, wie sie im Text-Dokument eingestellt ist, bestimmt.
Hier lässt sich allerdings nichts einstellen.

OpenUI *PageRegion: PickOne
*OrderDependency: 100 AnySetup *PageRegion
*DefaultPageRegion: A4
*PageRegion Letter/US Letter: "%% FoomaticRIPOptionSetting: PageSize=Letter"
*PageRegion A4/A4: "%% FoomaticRIPOptionSetting: PageSize=A4"
*PageRegion 11x17/11x17: "%% FoomaticRIPOptionSetting: PageSize=11x17"
*PageRegion A3/A3: "%% FoomaticRIPOptionSetting: PageSize=A3"
*PageRegion A5/A5: "%% FoomaticRIPOptionSetting: PageSize=A5"
*PageRegion B5/B5 (JIS): "%% FoomaticRIPOptionSetting: PageSize=B5"
*PageRegion Env10/Envelope #10: "%% FoomaticRIPOptionSetting: PageSize=Env10"
*PageRegion EnvC5/Envelope C5: "%% FoomaticRIPOptionSetting: PageSize=EnvC5"
*PageRegion EnvDL/Envelope DL: "%% FoomaticRIPOptionSetting: PageSize=EnvDL"
*PageRegion EnvISOB5/Envelope B5: "%% FoomaticRIPOptionSetting: PageSize=EnvISOB5"
*PageRegion EnvMonarch/Envelope Monarch: "%% FoomaticRIPOptionSetting: PageSize=EnvMonarch"
*PageRegion Executive/Executive: "%% FoomaticRIPOptionSetting: PageSize=Executive"
*PageRegion Legal/US Legal: "%% FoomaticRIPOptionSetting: PageSize=Legal"
*CloseUI: *PageRegion

Ich werde einfach nicht schlau aus der ganzen Sache. Es gibt da noch etwas was ich bisher noch nicht berücksichtigt habe. Im Verzeichnis /etc/cups/ppd/ liegt neben der *.ppd noch ein *ppd.O (Objektcode). Da ist jedoch so ziehmlich das gleiche drin.

Vielleicht sind das auch die Filter die CUPS einsetzt, und damit von einer EDV-Sprache in eine andere übersetzt, die zu diesen Ungenauigkeiten führen.

67

Dass Du nicht schlau wirst ist mir hinreichend klar. Dir zu helfen ist eine Herausforderung, weil du grundsätzlich Fragen ausweichst, nur unvollständige Informationen präsentierst und eigene Überlegungen, deren Sinn sich mir nicht erschließt. Du kannst versuchen, das installierte ppd File mit susepaste hochzuladen so, wie ich es für meinen Drucker getan habe: http://www.mistelberger.net/brother-HLL2350DW-cups-en.ppd Hinweis: Das hochgeladene File ist identisch mit dem File /etc/cups/ppd/HLL2350DW.ppd

68

Hallo allerseits,

nochmal einen kurzen Bericht darüber, was ich noch zu meinem Thema abschließend erreicht habe.
Nach einer notwendigen Pause habe ich gestern die Einstellungen in der ppd Datei unter /etc/cups/ppd/… unter etwas nüchterner Umstände als beim letzten Mal probiert.

Beim letzten poste hatte ich schon mehere Stunden alles mögliche probiert, um überhaupt einen Überblick zu erhalten wie die Auswirkungen bei dieser und jener Änderung oder Vorgehensweise sind. Leider führten die Tests zu keinem endgültigen Ergebnis.

Tut mir leid, das Bild beim letzten poste war nicht, was ich eigentlich zeigen wollte, nachträglich konnte ich es nicht mehr ändern.
Das Bild hier wäre das passende gewesen.
https://paste.opensuse.org/82943095

Jetzt stimmt der druckbare Bereich im Test-Druck aus YAST->Drucker Treiber-Installation. Der Druckertreiber, der von OpenPrinting als “perfect” angeboten wird, hätte eigentlich von anfang an gute Druck-Ergebnisse geliefert. Nur die “imaginable area”, wie vorher erwähnt, war noch nicht in der Höhe passend. Ich habe da noch eine Feinjustierung vorgenommen, die jedes Mal nach dem abspeichern der *.ppd sofort auch im Testdruck angekommen ist. Somit war das dann recht einfach. Irgendwie hatte das zuvor nie so richtig geklappt.
Das Ergebnis mit diesem Druck-Treiber ist jetzt ähnlich gut wie die Ergebnisse mit dem proprietären Treiber von OKI aus Windows 10. Ich bin froh, jetzt wieder beim Drucken auf Windows verzichten zu können.

Was mir jetzt noch als Eindruck von diesem ganzen Test-Aufwand bleibt, ist meine Vermutung, dass die wenigen verbleibenden Ungenauigkeiten zwischen Vorder- und Rückseite, in der genauen Größe des Textbereichs beim Duplex-Druck, Ungenauigkeiten bei der Übersetztung vom Textdokument in die Druckersprache geschieht. Das Druck-Ergebnis ist nicht ganz exakt gleich wie das Textdokument selbst. Hier geht es insgesamt um 1-2mm Verschiebung zwischen Vorder- und Rückseite.

Ich frage mich noch immer, ob man vielleicht gar nicht erwarten kann, dass digitales Dokument und Hardcopy-Dokument exakt gleich - ohne jegliche Abweichungen - sein können, und ob die Home-Office Technologieen da vielleicht auch einfach an ihre Grenzen stoßen.
Wie dem auch sei, vielleicht würde ein neuer Drucker auch nicht ganz exakt, und mit den gleichen Abweichungen drucken - das wäre dann enttäuschend.

69

Vielen Dank für die Rückmeldung. Mit dem passenden Bild verstehe ich jetzt deine Probleme mit dem Rand.

Jetzt stimmt der druckbare Bereich im Test-Druck aus YAST->Drucker Treiber-Installation. Der Druckertreiber, der von OpenPrinting als “perfect” angeboten wird, hätte eigentlich von anfang an gute Druck-Ergebnisse geliefert. Nur die “imaginable area”, wie vorher erwähnt, war noch nicht in der Höhe passend. Ich habe da noch eine Feinjustierung vorgenommen, die jedes Mal nach dem abspeichern der *.ppd sofort auch im Testdruck angekommen ist. Somit war das dann recht einfach. Irgendwie hatte das zuvor nie so richtig geklappt. Das Ergebnis mit diesem Druck-Treiber ist jetzt ähnlich gut wie die Ergebnisse mit dem proprietären Treiber von OKI aus Windows 10. Ich bin froh, jetzt wieder beim Drucken auf Windows verzichten zu können.

Da hat sich die lange Diskussion doch noch gelohnt.

Was mir jetzt noch als Eindruck von diesem ganzen Test-Aufwand bleibt, ist meine Vermutung, dass die wenigen verbleibenden Ungenauigkeiten zwischen Vorder- und Rückseite, in der genauen Größe des Textbereichs beim Duplex-Druck, Ungenauigkeiten bei der Übersetzung vom Textdokument in die Druckersprache geschieht. Das Druck-Ergebnis ist nicht ganz exakt gleich wie das Textdokument selbst. Hier geht es insgesamt um 1-2mm Verschiebung zwischen Vorder- und Rückseite.

Ich frage mich noch immer, ob man vielleicht gar nicht erwarten kann, dass digitales Dokument und Hardcopy-Dokument exakt gleich - ohne jegliche Abweichungen - sein können, und ob die Home-Office Technologien da vielleicht auch einfach an ihre Grenzen stoßen.
Wie dem auch sei, vielleicht würde ein neuer Drucker auch nicht ganz exakt, und mit den gleichen Abweichungen drucken - das wäre dann enttäuschend.

Meine Brother-Drucker, der HLL2350DW und der uralte MFC255CW drucken perfekt abgesehen vom mechanischen Spiel (ersichtlich bei bidirektionalem Druck) und Rundungsfehlern in CUPS beim Umrechnen von Points in Millimeter: Die kleine PPD Fibel — handsOn Dokumentation (ersichtlich auf der Yast2-Testseite).

Die Ausführungen bezüglich des Randes in Kommentar #29 kann ich nicht nachvollziehen. CUPS funktioniert perfekt. Von meinen Druckern wird ein Dokument mit eingestelltem Rand, wie z.B. von LibreOffice Writer erstellt, mit genau diesem Rand ausgedruckt. Dokumente, die selbst keinen Rand haben werden auf die Imageable Area gedruckt, so dass sie problemlos gelesen werden können. Das Rand-Problem ist hier in Wirklichkeit ein Benutzer-Problem.

70

Hallo karlmistelberger,

/home/suse_user1/Dokumente/TEMP/CUPS_dxlmono_1.png

Ich verstehe nicht immer sofort alles, aber manchmal dann etwas später.
Es war ein guter Tip und Hinweis für mich, mal den angebotenen Drucker-Treiber von OpenPrint auszuprobieren.

Da mir das schon öfters passiert ist, dass ich mit manchen Lösungsansätzen nicht mehr weiter gekommen bin, hatte ich manche schon vormals wahrgenommene und angebotene Möglickeiten außer Augen verloren.

Auch wenn ich jetzt nicht sofort mit dem *.ppd richtig umgehen konnte, habe ich etwas später durch probieren verstanden was da passiert.
Nichts was hier gepostet wird ist ganz umsonst. Manchmal hilft es gleich, manchmal etwas später weiter. Auch die Beiträge von GrandDixence2 waren hilfreich.

weil aber immer wieder die Rede von CUPS-Filter die Rede war:
in meiner *.ppd sind Filter angelegt.
Bild:
https://paste.opensuse.org/72094390

71

Ja, deswegen habe ich auch weiter diskutiert.

weil aber immer wieder die Rede von CUPS-Filter die Rede war: in meiner *.ppd sind Filter angelegt: SUSE Paste

Das Bild ist nicht so hilfreich. Nach sechs Tagen wird es gelöscht und dann kann keiner mehr sehen worum es ging. Praktischer ist es, Text zu posten, am besten den wonach der Helfer fragt. Den Oki-B410-pxlmono.ppd habe ich zwar nicht installiert, aber heruntergeladen:

karl@erlangen:~> grep Filter Downloads/Oki-B410-pxlmono.ppd  
*cups**Filter**:    "application/vnd.cups-postscript 100 **foomatic-rip**" 
*cups**Filter**:    "application/vnd.cups-pdf 0 **foomatic-rip**" 
karl@erlangen:~>

Bei meinem Laserdrucker sieht es genau so aus:

**erlangen:~ #** grep Filter /etc/cups/ppd/HLL2350DW.ppd 
*cups**Filter**:    "application/vnd.cups-postscript 0 **brother_lpdwrapper_HLL2350DW**" 
*cups**Filter**:    "application/vnd.cups-pdf 0 **brother_lpdwrapper_HLL2350DW**" 
**erlangen:~ #**

Zum Filter:

[FONT=monospace]**erlangen:~ #** locate brother_lpdwrapper_HLL2350DW                         
/usr/lib/cups/filter/brother_lpdwrapper_HLL2350DW 
**erlangen:~ #** ll /usr/lib/cups/filter/brother_lpdwrapper_HLL2350DW            
lrwxrwxrwx 1 root root 54 Jul 17 14:34 /usr/lib/cups/filter/brother_lpdwrapper_HLL2350DW -> /opt/brother/Printers/HLL2350DW/cupswrapper/lpdwrapper
**erlangen:~ #** head /opt/brother/Printers/HLL2350DW/cupswrapper/lpdwrapper              
#! /usr/bin/perl 
# 
# CUPS filter                                      Ver2.01 
#   Copyright 2014-2017 Copyright Brother Industries,Ltd 2006-2017 
#   All Rights Reserved.  


# This program is free software; you can redistribute it and/or modify it 
# under the terms of the GNU General Public License as published by the Free 
# Software Foundation; either version 2 of the License, or (at your option) 
**erlangen:~ #**[/FONT]

Der Filter ist Teil eines von Brother zur Verfügung gestellten rpm-Pakets:

**erlangen:~ #** rpm -qf /opt/brother/Printers/HLL2350DW/cupswrapper/lpdwrapper 
hll2350dwpdrv-4.0.0-1.i386 
**erlangen:~ #** zypper if hll2350dwpdrv                                        
Loading repository data... 
Reading installed packages... 


Information for package hll2350dwpdrv: 
-------------------------------------- 
Repository     : @System 
Name           : hll2350dwpdrv 
Version        : 4.0.0-1 
Arch           : i386 
Vendor         : Brother Industries,Ltd 
Installed Size : 3.1 MiB 
Installed      : Yes 
Status         : up-to-date 
Source package : hll2350dwpdrv-4.0.0-1.src 
Summary        : Brother HL-L2350DW printer driver (lpd/cups) 
Description    :  
    Brother HL-L2350DW printer driver 
    Copyright Brother Industries,Ltd 2006-2017 

**erlangen:~ #**

Brother tut was für die Linux Benutzer und stellt aktuelle Pakete auf den eigenen Downloadseiten zur Verfügung.