Re: CUPS - auf einmal druckts nicht mehr

On Tue, Dec 04, 2012 at 04:22:17PM +0100, Oliver Fromme wrote:
> Polytropon <freebsd(at)edvax.de> wrote:
> > Die Lösung auf dem silbernen Tablett zu bieten ist ja sicher
> > zu viel verlangt, aber irgendwo "entsteht" bei Fehlern ja eine
> > Fehlermeldung, die man dann mittels fprintf(stderr, ...) oder
> > perror() o. dgl. "weiterreichen" könnte. Meiner Ansicht nach
> > sind gerade aussagekräftige Meldungen, die helfen, den Fehler
> > beim Namen zu nennen, ein Zeichen von _guter_ Software, selbst
> > wenn diese Bugs enthält (was sich nunmal nicht vermeiden
> > läßt).
>
> Wem sagst Du das ... Da rennst Du bei mir offene Türen ein.
>
> > > Ich habe es bisher erfolgreich geschafft, CUPS nicht zu
> > > benutzen. Es ist zwar installiert, aber nur, weil irgend-
> > > welche Ports partout nicht davon abzubringen waren, es als
> > > Dependency zu installieren. Aber benutzen tue ich es nicht;
> > > zum Glück können alle Programme, die ich verwende, PDF oder
> > > PostScript erzeugen. Opera und der Acrobat-Reader z.B.
> > > rufen sogar lpr(1) direkt auf und schaufeln da PostScript
> > > rein.
> >
> > Wirklich? Bei mir was Opera genau der Auslöser, da bei
> > installiertem System-LPD _kein_ Drucker im ^P-Dialog
> > angezeigt wurde.
>
> Ich müsste nochmal mit dem aktuellen Opera nachgucken, ob
> das (immer noch) so ist. Ich drucke eher selten etwas aus
> Opera. Aus dem Acrobat-Reader dagegen sehr viel häufiger,
> das geht definitiv -- Gerade eben habe ich daraus mehrere
> Online-Paketmarken von DHL gedruckt.

Das geht bei dir?
Ich habe immer Probleme bekommen, dass der das Javascript
mangels Signaturprüfung nicht ausgeführt hat und wusste nicht
wo ich die CAs nachtragen kann.
Das wäre für mich auch der einzige Einsatzbereich für den
Acrobat-Reader gewesen, ansonsten bin ich mit dem xpdf
sehr viel glücklicher.

> (Übrigens verwende ich den linux-opera, nicht den native,
> sofern das einen Unterschied bzgl. Drucken macht.)
>
> > Bei Gimp war die Abhängigkeit zum Installieren und die
> > Meldung "cannot connect to server" beim Aufruf des
> > Druck-Dialogs zwar nervig, aber gedruckt hat's trotzdem.
>
> Aus Gimp drucke ich nie; das ist mir zu unflexibel. Ich
> habe ein Shell-Skript, das anhand diverser Kommandozeilen-
> Parameter aus einer PNM-Datei PostScript oder PDF erzeugt.

Wenn ich mal mit GIMP drucke, dann in ein (oder mehrere) PS-Files.
Hintergrund ist, dass dann in der Regel auf einem Thermotransfer
mit Schmuckfarben, sowie Grundierung (OKI DP-5000) drucke und nur so
kann ich mir sicher sein, dass das auch alles glatt geht.

> > Aber mittlerweile gibt's ja beim Drucken dieselbe "tolle"
> > Fragmentierung: lpr, CUPS, Gutenprint, Foomatic, ... und
> > das verfolgt einen selbst dann, wenn man einen Drucker hat,
> > der schön den PS- und PCL-Sprachstandard unterstützt.
>
> Tja, ich ignoriere das ganze Zeug einfach. Ich könnte jetzt
> ausm Kopf nicht einmal mit Sicherheit sagen, welche davon
> bei mir installiert sind -- Wie gesagt, verwenden tue ich
> nur lpr.

Ist bei mir genau so, bzw sehr oft sogar noch ganz ohne Queue.
Mitunter getrennte "Drucker" für Duplex, Papierfach, ...
Das mit den getrennten Druckern mit getrennten Einstellungen hat
sich bei mir auch unter Windows bewährt, um nicht jedes mal die
Einstellungen kontrollieren zu müssen.

> > > Und wenn ein Programm unfähig ist, das zu tun, dann
> > > speichere ich es halt in eine Datei und rufe lpr(1) selbst
> > > auf.
> >
> > Warum sollte ein Program beim Drucken unfähig sein, PS
> > zu generieren? Das ist doch _das_ Standardformat für
> > Druckerausgaben schlechthin.
>
> Das sagst Du. :-)
>
> Aber im Ernst: Meine Bemerkung mit dem "unfähig" bezog sich
> nicht darauf, PostScript zu generieren, sondern darauf, es
> direkt an lpr(1) zu verfüttern, ohne Umweg über irgendeine
> Pseudointelligenz, deren offensichtlicher Zweck einzig und
> allein darin besteht, den ganzen Druckvorgang komplexer,
> undurchsichtiger und fehleranfälliger zu machen (wie dieser
> Thread auch wieder hervorragend demonstriert).

Meinem Nadeldrucker verfütter ich für Endlos-Etiketten immer
noch gerne zwischendurch händische Steuersequenzen plus ASCII.
Das jage ich dann aber auch direkt an die lpt, weil man da
besser kontrollieren kann was gerade passiert.
Kommt schon mal vor, dass ich kleine Aufkleber mit Seriennummern,
bzw. MAC-Adressen drucke und da gehen dann mal schnell einige
tausend Label durch und wenn die ersten nix sind, weil die Postition
nicht stimmt oder sowas, dann wird per CTRL-C abgebrochen, ohne das
da groð was in einer Queue steckt.
lpd besnutze ich hier nur für die wenigen Fälle bei denen ich
vereinzelte Postscript-Label ausdrucke.
Den Thermotransfer steuer ich auch direkt an der Schnittstelle.

-- 
B.Walter <bernd@bwct.de> http://www.bwct.de
Modbus/TCP Ethernet I/O Baugruppen, ARM basierte FreeBSD Rechner uvm.
To Unsubscribe: send mail to majordomo(at)de.FreeBSD.org
with "unsubscribe de-bsd-questions" in the body of the message