druckerner ist für Zuhause sogar brauchbar und die Möglichkeit ‘mal
> schnell was (farbig, gezoomt, etc…) kopieren zu können, ohne erst
> den Rechner anschmeissen zu müssen, ist oft recht nützlich …
Habe nen Scanner und ne ISDN-Karte im Server, die auch Faxen kann.
Das wäre also rausgeschmissenes Geld. Schwarz/Weiss-Kopien in
*bester* Qualität mach ich mit dieser Kombi auch jetzt schon. So oft
brauch ich das nicht und wenn, dann rentiert sich auch das “mal eben
kurz” Hochfahren des Scan-Rechners im Wohnzimmer. 
> > > Was für Dateien?
> > Postscript? > Welches? PS1, PS2, PS3 mit Jpeg-EPS? 
> Auch Ghostscript hat mit einigen PS-Dialekten Probleme …
mag zwar prinzipiell sein, zumindest unter UNIX erstellte PS-Datein
(Level2) haben aber bei mir noch nie Ärger gemacht; ganz im
Gegenteil! Und die Windows-Clients drucken über Adobe-PS auf ein
Samba-Share. Glaubs einfach, *das* ist wirklich das geringste Problem
(sofern es überhaupt eines ist).
> > Ist zwar prinzipiell richtig, doch mit CUPS
> > Ghostscript/Ghostprint/TurboPrint hat man unter Linux ein Drucksystem
> > zur Verfügung, dass Du unter Windows *so* nicht finden wirst;
> > zumindest nicht für Umme! O.g. Kombination macht aus *jedem*
> > unterstützten Drucker einen IPP-fähigen, Netzwerk-Postscript-Drucker.
>
> Wie ich schon sagte: nicht schlagen scho recht! 
> Ich arbeite nicht unter Linux, sondern mit Unix (HPUX und AIX 4.3)
> auf Produktionsmaschinen. Es gibt für AIX zwar inzwischen auch KDE
> und Gnome, ist bei uns aber nicht im Einsatz. Unter Unix ist leider
> nicht unbeding gewährleistet, dass jedes Programm auch Postscript
> oder ein anderes direkt druckbares Dateiformat (ausser Text)ausgeben
> kann.
Das hat nix mit “Unix” zu tun, sondern ist dann eine
Anwendungs-Besonderheit. HPUX und AIX sind nebenbei auch schon etwas
älter. Unter Linux wirst Du es aber schwer haben, ein Programm zu
finden, welches nicht Text und/oder PS beherrscht.
> Ghostscript kenne ich von verschidenen Plattformen: Solaris, Mac,
> Windows, Unix. Als Dienstleister war das teilweise meine letzte
> Rettung, wenn alle anderen PS-RIPS sich weigerten …
hehe > > doch, *das* ist dann klar. So richtig kennst Du Dich mit
> > UNIX-Druck nicht aus, gell? UNIX-Anwendungen brauchen kein
> > “passendes Backend”.
>
> Ahem, sagt Dir rembak unter AIX was?
Hatte mit AIX nur wenig zu tun. Eher noch Solaris.
> > Die “drucken” erstmal nur Postscript
> Wenn sie es denn können!
ok, lass uns über “normale” Anwendungen reden, die *heutzutage* auf
jeder Linux-Büchse laufem. Wie gesagt, in grauer Vorzeit war vieles
anders und viele dieser Urgetüme leben länger, als einen lieb sein
kann. Dass diese Anwendungen dann gewissen Dinge nicht (richtig)
können, ist zwar übel, aber eben kein grundsätzliches Problem. PS ist
unter Linux deswegen kein Problem, weil es so nette libs dafür gibt,
die einen die meiste Arbeit abnehmen. Da kommt dann auch recht
brauchbarer Code bei raus…
> > und können diesen Output an beliebige Programme durchpipen.
>
> Nun, ich dachte immer, die gehen über enq oder lp an den qdeamon, der
> das ganze in die Queue stellt und über einen Backend an den Drucker
> schickt Das ganze kann noch vieeeeellll komplizierter sein. Aber i.d.R.
interessiert es die Anwendung nicht! Weil: lpr ist die Schnittstelle,
die die meisten Anwendungen nutzen, um ihren Druckjob (meistens PS)
loszuwerden. Was ‘lpr’ dann damit anstellt, kann der Anwendung
wurscht sein. Die Anwendung piped ihren Druckoutput durch ‘lpr’ und
der kümmert sich um den Rest. Das kann dann alles sein, vom
Vorfiltern, umwandeln, RIP über Printerpooling, Jobmanagement,
spooling, etc. Aber wie gesagt, *das* kann der Anwendung wurscht
sein!
> So macht’s zumindest SAP …
SAP ist ne ganz andere Welt ;-)))
> Man kann natürlich statt dem Qdeamon auch Unispool verwenden, das hat
> den Vorteil, das man ei GUI hat um sämtliche Qeues zu überwachen und
> nicht mehr jeden Drucker auf jeder Unix-Kiste als System-Queue
> einrichten muss. Man braucht ihn nur noch einmal zu definieren und er
> steht auf jedem Unix-System auf dem Unispool läuft zur Verfügung …
Schau Dir mal CUPS an. *das* ist mal richtig geil! ;-))
> > I.d.r. wird dies ‘lpr’ sein.
> Ich dachte immer, lpr->lpd wäre ein Protokoll :->
ja und nein. Die Anwendung selbst heisst auch ‘lpr’. Wobei die bei
CUPS eigentlich nicht mehr notwendig ist und nur emuliert wird, damit
alte Programme, die nur LPD/LPng/BSD, etc. kennen keine Probleme
haben ihren Druckjob loszuwerden.
> > CUPS emuliert lpr. Also kein Problem!
> lpr oder lpd?
das ‘lpr’ Kommando. Der lpd ist eingebaut und kann doch “ein klein
wenig” mehr, als nur das reine spooling.
afaik.