Hallo,
müssen alle Druckjobs von Druck-Clients per postscript über das Netzwerk?
Müssen also CUPS-Warteschlangen auf den Clients aus dem zu druckenden Dokument zwingend ein Postscript machen? Oder sollte das jedenfalls so sein, ist also das Normale?
Müssen auf dem Client alle eingerichteten Drucker einen (generischen) Postscript-Treiber haben?
Oder ist es auch üblich "raw" über das Netz zu drucken und erst der CUPS-Server konvertiert dann?
Das brauche ich: eine alte Suse 9.2 mit CUPS 1.1. macht ständig Ärger: "unrecoverable postscript error, Postscript 7.0.1" bei der Konvertierung in ein PCL für einen HP-Laserdrucker. Also will ich die Druckjobs auf mein debian etch hier mit einem moderneren CUPS schicken, dort sollen die ins HP-PCL konvertiert und dann über das Netz an den dritten PC mit einer RAW-Warteschlange mit USB-HP-Drucker geschickt werden. Suse 9.2 und die RAW-Warteschlange gibt es schon seit Jahren, neu ist jetzt das dazwischen gehängte debian mit CUPS-Server.
Noch eine Verständnisfrage meinerseits: Linux-Anwendungen wie xpdf oder gwenview erzeugen doch schon postscript, wenn gedruckt wird, oder? Es gibt ja in jedem Druckdialog unter Linux stets "Drucken und Datei" und das ist immer postscript. Also erhält derzeit unter meiner alten Suse 9.2 das CUPS-Drucksystem stehts ein postscript, richtig? Also brauche ich gar keinen generischen Postscipt-Treiber in meiner Suse 9.2 wenn ich den Druckjob direkt, also "raw", (also ohne ppd-Datei, ganz einfach) aufs Netzwerk Port 631 des CUPS-Servers gebe, richtig? Oder hängt das von der Anwendung ab?
Bin für fachliche Info dankbar. Hat mir jmd vielleicht einen Link zu diesem Thema?
Dann gibts da ja noch dieses Browsing und Polling bei CUPS. Klappt bei mir hier mit Suse 11.1 und einer zweien Suse 11.1 unter vmware gar nicht. Ich würde ja gerne abgucken wie dieser Automatismus die Warteschlange auf dem Client anlegt: mit der ppd-Datei des CUPS-Server? Mit einem generische Postscript-Treiber? Ganz ohne ppd? - Vielleicht kann mir jemand hier seine automatisch per browsing oder polling angelegte Warteschlange posten. Ich bin mal gespannt.
@22.4.: habe unter etch vergessen das foomatic-db-hpijs zu installieren, jetzt fluppt das raw-Drucken auf etch-Warteschlangen hervorragend, diese konvertieren dann korrekt wie es ein HP-Druck will, dann wird auf die tatsächlichen Clients erst gedruckt, die wiederum nur raw-Warteschlangen habe. Ich frage mich jetzt allerdings immer noch, was für ein Dateityp an etch CUPS geschickt wird. hmm... eigentlich müßte ich nur mal das CUPS in etch anhalten, dann in der Warteschlange unter Suse 9.2 nachsehen:
tatsächlich: das png wurde in postscript gewandelt, noch unter Suse 9.2:
%!PS-Adobe-1.0
%%BoundingBox: 0 0 594 842
%%Creator: KuickShow-0.8.6a
%%Title: /home/scan/wo1/1/Briefe/2009-09-22-20.58.21_scan-1.png
%%CreationDate: Do Apr 22 20:07:56 2010
%%Orientation: Portrait
%%Pages: 1
%%DocumentFonts: SUSESans-Roman
%%EndComments
%%BeginProlog
% Prolog copyright 1994-2003 Trolltech. You may copy this prolog in any way
% that is directly related to this document. For other use of this prolog,
% see your licensing agreement for Qt.
/d/def load def/D{bind d}bind d/d2{dup dup}D/B{0 d2}D/W{255 d2}D/ED{exch d}D
[...]
Das pdf ist in Postscript 3 gewandelt worden, für das Postscript scheint wirklich die Anwendung verwantwortlich zu sein:
%!PS-Adobe-3.0
%%Creator: xpdf/pdftops 3.00
%%LanguageLevel: 2
%%DocumentSuppliedResources: (atend)
%%DocumentMedia: plain 612 792 0 () ()
%%BoundingBox: 0 0 612 792
%%Pages: 1
%%EndComments
%%BeginDefaults
%%PageMedia: plain
%%EndDefaults
%%BeginProlog
%%BeginResource: procset xpdf 3.00 0
/xpdf 75 dict def xpdf begin
% PDF special state
/pdfDictSize 15 def
/pdfSetup {
[...]
Also geht postscript über das "Netz". Somit ist klar, dass irgendwo (auf der Welt) ein Druckerserver stehen kann der dieses Poscript in die jeweilige Druckersprache konvertiert und ausdruckt oder die konvertierte (oder falls raw die nicht konvertierte) Datei weitersendet.
Gruss
Eckard