Am 05.08.2021 schrieb Sabine Baer:
> On 2021-08-04, Andreas Kohlbach wrote:
>> On Wed, 4 Aug 2021 19:05:59 +0200, Sabine Baer wrote:
>
> [...
>
>>> Es ist wieder ein Kyocera, genauer ein Utax, ein P3522DW.
Wenn man mit der richtigen Typbezeichnung P-3522DW sucht, findet sich
zumindest beim Hersteller etwas.
> FreeBSD 12.2, sowohl CUPS als auch lpd. Ich habe auch schon
Ist CUPS denn wirklich installiert und läuft auch? Bei dem vielen
Schreiben hier, ist es mir nicht mehr klar!
> #cat
foo.ps > /dev/ulpt0
> probiert, ich meine mich zu erinnern, dass das mal geklappt hat, aber
> mehrheitlich nicht.
Wenn eine Postscript-Datei über die Geräteschnittstelle (hier /dev/ulpt0)
direkt an den Drucker gesendet wird, dann muss am Ende der Datei ein
End-of-Text-Zeichen (0x04), kurz EOT, stehen, damit der Drucker mit dem
Drucken beginnt. Dieses wird oft auch als End-of-File-Zeichen (EOF)
bezeichnet. Es kann auch nachträglich gesendet werden. Mit dem EOT wird
das Ende einer Quelle signalisiert, in der Regel ist das eine Datei oder
auch ein Datenstrom. Der Postscript-Interpreter im Drucker wartet auf
dieses Zeichen, denn erst nach dem Eintreffen dieses Zeichens kann das
Dokument als vollständig angesehen werden. Erst dann kann er loslegen.
Früher (wirklich lange her) habe ich anfangs meine Briefe direkt in
Postscript formuliert. Dazu wurden dann mehrere Dateien nacheinander an
den Drucker gesendet. Die Letzte enthielt nur das EOT-Zeichen.
Weil es nicht funktionieren will, die Frage: Enthält '
foo.ps' denn ein
EOT als letztes Zeichen? (Auf Linux ermitteln z.B.mit: $ od -t c
foo.ps)
>> Wenn er immer druckt, aber manchmal nur Schrott, dürfte es am falschen
>> Treiber liegen.
>
> Als Treiber habe ich, wie auch bei dem alten FS 1010 'generic postscript
> printer' eingetragen, wenn danach gefragt wurde.
> da $lpr sich nach der /etc/printcap richtet (soweit ich weiss), und da
> der Drucker vor wie nach so beschrieben ist
Dass geht so nicht. Siehe weiter unten.
Wie schon oben erwähnt, wenn man auf
https://www.utax.de/de-de/hardware/download-center
nach P-3522DW sucht, findet sich das ZIP-Archiv
LinuxPPD_P-3521MFP_...P-4020DW_20161117.zip
darin sind zwei PPD-Dateien P3522DW.PPD enthalten. Wenn CUPS in
Verwendung ist, würde ich diejenige im Unterverzeichnis 'EU' verwenden.
Alle bereits versuchsweise installierten Drucker sollten zuvor beseitigt
werden.
> $less /etc/printcap
> lp|local line printer:\
> :sh:\
> :lp=/dev/ulpt0:sd=/var/spool/output/lpd:lf=/var/log/lpd-errs:
>
> und ich nicht mehr weiss, wie ich dem alten FS 1010 beigebracht habe,
> ordentlich zu drucken, habe ich au die Emulayion fuer 'Line Printer'
> eingestellt, ohne Erfolg.
>
> Vielleicht mache ich es auch falsch, die Emulation richtig zu bestimmen.
Wenn CUPS in Verwendung ist, dann ist der obrige Eintrag in der printcap
nicht zulässig. Auch muss keine Emulation bestimmt werden. Es wird alles
über die P3522DW.PPD bekannt gemacht. Um weitere Probleme zu vermeiden
wäre es am besten, den Ducker in seinen Anfangszustand zurückzusetzen.
Zwar verwendet 'lpr' die Einträge in der printcap-Datei, aber diese sind
für CUPS zugerichtet. Hast Du tatsächlich noch den
Pfad /var/spool/output/lpd auf Deinem FreeBSD-System? Habe schon lange
nicht mehr mit FreeBSD gearbeitet.
Ich verwende CUPS und meine Drucker sind über einen Router am LAN
angeschlossen. Die printcap hat nach der letzten Druckerinstallation
folgenden Inhalt angenommen:
# This file was automatically generated by cupsd(8) from the
# /etc/cups/printers.conf file. All changes to this file
# will be lost.
Samsung_ML-3470_Series|Samsung ML-3470 Series:rm=erde.sonne.all:rp=Samsung_ML-3470_Series:
Kyocera_FS-1010|Kyocera FS-1010:rm=erde.sonne.all:rp=Kyocera_FS-1010:
Samsung_ML-3470_Series_beidseitig|Samsung ML-3470 Series Duplex:rm=erde.sonne.all:rp=Samsung_ML-3470_Series_beidseitig:
---
Weil die Drucker über IPP im LAN bekannt gemacht werden, sind in der
printcap 'Fully Qualified Domain Name' (FQDN) enthalten. Der Router
übernimmt auch die Namensauflösung (DHCP) in meinem LAN.
> Ich schreibe die Kommandos in einen File foo und schicke das Komando mit
> #cat foo > /dev/ulpt0
Wenn CUPS in Nutzung ist, dann ist das sicher überflüssig - wahrscheinlich
sogar schädlich.
Ich hoffe die Papierverschwendung kann jetzt beendet werden.