Hallo Jörg, Joerg Thuemmler schrieb:

Thomas Michalka schrieb:

...

Hallo,

mein CUPS-Server (und wohl auch der CUPS-eigene Web-Server) läuft, aber weder von einem grafischen noch einem Text-Browser kann ich auf die Startseite zugreifen.

/usr/share/doc/packages/cups/de/index.html ist aber vorhanden. Ich habe vorasichtshalber auch die Integrität aller installierten CUPS-Pakete mit rpm -V <package> geprüft, besonders auf 'missing' files, da ich durch einen Dateisystemdefekt auf einem anderen Rechner genau dieselbe Fehlermeldung bekam: 404 Not Found.

Hi,

aber Drucken geht? Seltsam...

Jein, d.h. auf diesem Rechner habe ich noch keine Queue konfiguriert, denn ich wollte das ja über das Web-Frontend machen. Auf einem anderen Rechner, dessen Web-Frontend ich (aber auch nur von einem oS-11.0-System, s.u.!) erreiche, geht drucken. Nichts besonderes, denkt man vielleicht, aber hier ist das Seltsame, dass man nur einmal den Anmeldedialog des Browsers präsentiert bekommt (wo ich mich als root anmelde), wenn man als normaler Benutzer einen Drucker z.B. modifizieren will (z.B. Beschreibung ändern). Wenn ich später nochmal die Startseite aufrufe und unter http://rechner:631/printers bei einem Drucker auf "Modify" klicke, dann bekomme ich keinen Anmeldedialog mehr, sondern die Meldung Unauthorized Der Server konnte nicht Ihre Berechtigung überprüfen, diese Ressource zu benutzen. Für root war es nie Problem einen Anmeldedialog zu erhalten. Die Frage ist, woher 'weiß' das Web-Frontend des CUPS--Servers, als welcher Benutzer man die Startseite aufruft? Eigentlich kann und muss es das doch nicht wissen, denn für die Authentisierung ist doch ein Anmeldedialog da, dachte ich. Das ist doch der Clou von Web-Frontends, dass man sich theoretisch von überall in der Welt, möglichst SSL-geschützt anmelden kann. Bei meinem Netzwerk-Drucker geht das übrigens anstandslos. Von selben CUPS-Server bekomme ich auf einem anderen Rechner nur 403 Forbidden You don't have permission to access the resource on this server. zu lesen. Das ist eine oS-11.2, von der aus ich auch nicht drucken kann. Deshalb habe ich mir dort sozusagen provisorisch einen CUPS-Server mit einer Queue für meinen Netzwerkdrucker eingerichtet, damit ich von dort aus drucken kann. Auf dem Parallel-Port-Drucker des eigentlich als zentralen Print-Server gedachten Rechners kann ich damit natürlich nicht drucken. Auf einem anderen Rechner mit oS-11.0 dagegen brauche ich nicht einmal einen CUPS-Server, damit Drucken auf dem entfernten Print-Server geht. Dort ist es sogar so komfortabel, dass man nach dem Einrichten einer neuen Queue unmittelbar danach in jedem Druck-Dialog (OOo, Firefox, KDE) die neue Warteschlange sieht. So sollte das auch sein, dachte ich. Kann man irgendwo in YaST oder sonstwo die Zugriffsrechte für LAN-Rechner, denen ich voll vertrauen kann, zunächst mal möglichst lasch einstellen, damit man durch Verschärfung nach und nach herausfinden kann, welche Einstellung das Drucken und konfigurieren verhinderte? Ich möchte hier für später gerne was dazulernen. Gruß, Tom -- Um die Liste abzubestellen, schicken Sie eine Mail an: opensuse-de+unsubscribe@opensuse.org Um eine Liste aller verfuegbaren Kommandos zu bekommen, schicken Sie eine Mail an: opensuse-de+help@opensuse.org

Hi Jörg, Joerg Thuemmler schrieb:

Thomas Michalka schrieb:

...

Hallo Jörg,

Joerg Thuemmler schrieb:

...

Thomas Michalka schrieb:

...

Hallo,

mein CUPS-Server (und wohl auch der CUPS-eigene Web-Server) läuft, aber weder von einem grafischen noch einem Text-Browser kann ich auf die Startseite zugreifen.

aber Drucken geht? Seltsam... Jein, d.h. auf diesem Rechner habe ich noch keine Queue konfiguriert, denn ich wollte das ja über das Web-Frontend machen.

Kann man irgendwo in YaST oder sonstwo die Zugriffsrechte für LAN-Rechner, denen ich voll vertrauen kann, zunächst mal möglichst lasch einstellen, damit man durch Verschärfung nach und nach herausfinden kann, welche Einstellung das Drucken und konfigurieren verhinderte? Ich möchte hier für später gerne was dazulernen.

also, dass Du von keinem anderen PC rankommst, ist vielleicht der segensreiche Einfluss der Suse-Firewall

Auf dem Rechner (helix, s.u.) läuft keine Firewall -- ist ja auch nur ein Rechner im LAN, der sozusagen allen anderen vertrauen kann, da sie alle unter meiner Fuchtel stehen. Ich gebe zu, dass mein Text oben (hier fast alles gelöscht) etwas schwer nachzuvollziehen ist ... Also nochmal einfacher, in Form einer Zugriffstabelle mit folgenden Festlegungen: In der Hauptdiagonalen (Rechner bei "von" und "auf" identisch) steht jeweils die Kurzdiagnose für lokalen Zugriff (sowohl mit grafischem Browser als auch mit lynx und w3m). Alle Einträge haben die Form <Web-ADM>/<PRINT>, d.h. OK/OK bedeutet, dass sowohl über das Web-Frontend von CUPS administriert als auch gedruckt werden kann, X/X bedeutet das Gegenteil für beide Aspekte. Einträge in Klammern haben eine besondere Bedeutung und bedürfen der Erklärung (immer eine Nummer in Fußnote "[x]", siehe unten). Steht ein '-' in der Tabellenzelle, dann habe ich es nicht ausprobiert, z.B. Drucken, weil der Kontakt zum Web-Frontend schon gescheitert ist. Entschuldige bitte, dass ein Teil meines obigen Texts wieder in den Fußnoten steht (vor allem in [1]), das ist aber wegen des Verständisses und der jetzt eindeutigen Zuordnung erforderlich. Der eigentlich als einziger Druck-Server gedachte Rechner ist helix (sowohl für den lokalen Parallelport-Drucker als auch den Netzwerkdrucker). Auf terrix läuft jetzt auch ein CUPS-Server, aber nur, weil dieser Rechner überhaupt keinen Zugriff auf den Druck-Server helix schafft, ganz im Ggs. zu neptix, wie die Tabelle zeigt Auf neptix läuft auch ein CUPS-Server, aber nur, weil ich das Verhalten von allen drei Rechnern mal systematisch durchprobieren wollte. Zugriff ... ... auf helix neptix terrix von (ADM / PRINT) (ADM / PRINT) (ADM / PRINT) ------------------------------------------------------------------------ helix (SuSE 7.3) OK / OK (X)[2] / - (X)[4] / - (cups 1.1.10) neptix (oS-11.0) (OK)[1] / OK (X)[2] / - (X)[4] / - (cups 1.3.7) terrix (oS-11.2) (X)[3] / X (X)[2] / - OK / OK (cups 1.3.11) [1] Man bekommt den Anmeldedialog des Browsers nur einmal präsentiert (wo ich mich als root anmelde), wenn man als normaler Benutzer einen Drucker z.B. modifizieren will (z.B. Beschreibung ändern). Wenn ich später nochmal die Startseite aufrufe und unter http://rechner:631/printers bei einem Drucker auf "Modify" klicke, dann bekomme ich keinen Anmeldedialog mehr, sondern die Meldung "Unauthorized Der Server konnte nicht Ihre Berechtigung überprüfen, diese Ressource zu benutzen." Für root war es nie ein Problem einen Anmeldedialog zu erhalten. Die Frage ist, woher 'weiß' das Web-Frontend des CUPS--Servers, als welcher Benutzer man die Startseite aufruft? Eigentlich kann und muss es das doch nicht wissen, denn nur für die Authentisierung ist doch ein Anmeldedialog da, dachte ich bisher. Das ist doch der Clou von Web-Frontends, dass man sich theoretisch von überall in der Welt, möglichst SSL-geschützt anmelden kann. Bei meinem Netzwerk-Drucker geht das übrigens anstandslos. [2] Aufrufen von http://localhost:631 ergibt "404 Not Found" Aufrufen von http://neptix:631 (w3m bzw. lynx) ergibt "Alert!: Unable to connect to remote host." "w3m: Can't load http://neptix:631" und jeweils automatisches Programmende. [3] Aufrufen von http://helix:631 ergibt "403 Forbidden You don't have permission to access the resource on this server." [4] Aufrufen von http://terrix:631 ergibt mit lynx: "Alert!: Unable to connect to remote host." w3m: "w3m: Can't load http://terrix:631" und jeweils automatisches Programmende.

... aber lokal (w3m http://localhost:631) tut auch nicht?

Auf helix und terrix immer schon, nur auf neptix nicht. Ist aber auf dem nicht so wichtig, da ich den gar nicht als Print-Server haben wollte. Hier kann ich cups entweder runterschmeißen oder interessehalber aktualisieren, um zu sehen, ob auch lokal immer noch keine Indexseite gefunden wird. Ich wollte aber demnächst eine oS-11.2 u.a. als Print-Server installieren, aber das Verhalten von terrix, der alle Remote-Zugriffe (siehe letzte Spalte der Tabelle) blockiert, lässt mich an der Sinnhaftigkeit zweifeln. Deswegen muss ich auch den Uralt Print-Server auf helix behalten.

Probehalber kannst Du sie ja mal abschalten, nur für den Fall dass da was falsch konfiguriert ist, normalerweise sollte die Port 631 im LAN nicht blocken.

War nie eingeschaltet, auf keinem Rechner im LAN ("rcSuSEfirewall2 status" ergibt immer "unused").

Was sagen die Yast-Einstellungen, leg doch mal probehalber dort einen Drucker an, vielleicht schmeißt Suse den cups erst an, wenn es auch was zum drauf drucken gibt.

Nein, er läuft in den RLs 2, 3 und 5. So habe ich das im Runleveleditor auf jedem Rechner eingestellt ("rccups status" ergibt auch in allen Fällen "running").

/etc/rc.d/cups restart wirst Du ja schon probiert haben... wenn nicht, mach es mal, vielleicht spuckts eine Fehlermeldung aus...

Alles paletti.

In /var/log/messages irgendwas drin?

neptix: Mar 29 23:56:26 neptix xinetd[3522]: Reading included configuration file: /etc/xinetd.d/cups-lpd [file=/etc/xinetd.d/cups-lpd] [line=15] helix: kein Eintrag terrix: Mar 31 12:10:31 terrix xinetd[2210]: Reading included configuration file: /etc/xinetd.d/cups-lpd [file=/etc/xinetd.d/cups-lpd] [line=15]

Mit Sicherheit "weiß" cups nicht, wer sich anmeldet, bis der Anmeldedialog durch ist, auch danach kann man als user zumindest gucken und eigene Jobs bearbeiten. Das Verhalten ist normalerweise unabhängig davon, wer den Webbrowser aufgerufen hat.

ACK. Zusammenfassend bleiben also folgende Fragen: 1) Wie erlaubt man uneingeschränkten Zugriff auf den Druck-Server einer SuSE 7.3 / cups 1.1.10 im LAN (hier auf helix)? 2) Wie erlaube ich uneingeschränkten Zugriff auf den neuen Druck-Server einer oS-11.2 / cups 1.3.11 im LAN (hier auf helix)? Wüsste ich 2), dann bräuchte ich 1) nicht mehr zu lösen. Ich glaube, mich an eine grafische Darstellung des modularen Aufbaus des CUPS-Drucksystems zu erinnern, in dem neben allen beteiligten Config-Dateien evtl. auch Sicherheitsaspekte/Zugriffsrechte behandelt sind. Kennt irgendjemand so etwas? Übrigens habe ich gestern bei CUPS 1.3.11 auf terrix "Drucken über das Internet" erlaubt, was doch im LAN eigentlich alle Pforten öffnen sollte -- leider ohne Erfolg. Gruß, Tom -- Um die Liste abzubestellen, schicken Sie eine Mail an: opensuse-de+unsubscribe@opensuse.org Um eine Liste aller verfuegbaren Kommandos zu bekommen, schicken Sie eine Mail an: opensuse-de+help@opensuse.org

Thomas Michalka schrieb: ...

Zusammenfassend bleiben also folgende Fragen:

1) Wie erlaubt man uneingeschränkten Zugriff auf den Druck-Server einer SuSE 7.3 / cups 1.1.10 im LAN (hier auf helix)?

2) Wie erlaube ich uneingeschränkten Zugriff auf den neuen Druck-Server einer oS-11.2 / cups 1.3.11 im LAN (hier auf helix)?

Wüsste ich 2), dann bräuchte ich 1) nicht mehr zu lösen.

Hi, das sollte eigentlich bei beiden gleich sein: wenn, wie Du sagst, auf helix http://localhost:631 geht, mußt Du dort unter "Verwaltung" auf jeden Fall freigeben (Häkchen setzen): - "Verteile publizierte Drucker welche mit diesem System verbunden sind" wenn Du auch auf Jobs etc. zugreifen willst: - "Erlaube entfernte Verwaltung" Natürlich muss bei den Druckern dann auch "Drucker publizieren" eingestellt sein, sonst kannst Du den von außen nicht sehen außerdem solltest Du mal die /etc/cups/cupsd.conf mal durchsehen. Die Optionen dort sind relativ selbsterklärend. Was auch Ärger machen kann, sind generelle Einstellungen zum Anmeldeverfahren (passwortlos über keys), hier musst Du evt. auch die cupsd.conf anpassen, aber wenn Du mit ssh helix auf helix draufkommst, sollte das eigentlich passen... cu jth -- Um die Liste abzubestellen, schicken Sie eine Mail an: opensuse-de+unsubscribe@opensuse.org Um eine Liste aller verfuegbaren Kommandos zu bekommen, schicken Sie eine Mail an: opensuse-de+help@opensuse.org

Hi Jörg und Johannes, vielen Dank nochmal für Eure Anregungen, die zu Lösung meines Problems viel beigetragen haben! Joerg Thuemmler schrieb:

Thomas Michalka schrieb: ...

...

Zusammenfassend bleiben also folgende Fragen:

1) Wie erlaubt man uneingeschränkten Zugriff auf den Druck-Server einer SuSE 7.3 / cups 1.1.10 im LAN (hier auf helix)?

2) Wie erlaube ich uneingeschränkten Zugriff auf den neuen Druck-Server einer oS-11.2 / cups 1.3.11 im LAN (hier auf helix)? ^^^^^ Den Host-Namen hatte ich hier falsch: muss terrix heißen.

Wüsste ich 2), dann bräuchte ich 1) nicht mehr zu lösen.

Hi,

das sollte eigentlich bei beiden gleich sein:

Bei beiden Fällen möchte ich "uneingeschränkt" relativieren, d.h. beschränkt wissen auf Root und das LAN. Zum obigen Fall 1) (CUPS-Server * 1.1.10 * auf helix): ------------------------------------------------------ Der Grund, warum ich diesen nur von einem einzigen Rechner erreichen und administrieren konnte, war, dass ich in /etc/cups/cupsd.conf folgende Einträge hatte: <Location /> Order Deny,Allow Deny From All Allow From 127.0.0.1 Allow From 192.168.x.y Allow From .domain.local </Location> <Location /admin> AuthType Basic AuthClass System Order Deny,Allow Deny From All Allow From 127.0.0.1 Allow From 192.168.x.y Allow From .domain.local </Location> Eigentlich hätte ich durch die jeweils letzten Zeile vor </Location> Zugriff von allen Rechnern meiner lokalen Domain haben sollen, aber es war ein dafür entscheidender Eintrag falsch gesetzt bzw. 'falsch' voreingestellt, nämlich HostNameLookups Off (default) Der hätte auf 'On' gesetzt sein müssen, was ich aber vor fast zwei Jahren schon übersehen und nur nicht bemerkt habe, weil ich immer nur von der Adresse 192.168.x.y aus administriert habe, und das auch nur extrem selten. Apropos "übersehen": Ich hätte eher erwartet, dass ein Eintrag, wie "Allow From .domain.local" entsprechende Hostname Lookups impliziert. Ich habe den Kommentar in cupsd.conf offenbar nicht gelesen -- Asche auf mein Haupt ... ;-) Diese implizite Setzung könnte in den Versionen Realität geworden sein, siehe meine Erfahrungen mit diesen Versionen unten.

wenn, wie Du sagst, auf helix http://localhost:631 geht, mußt Du dort unter "Verwaltung" auf jeden Fall freigeben (Häkchen setzen): - "Verteile publizierte Drucker welche mit diesem System verbunden sind" wenn Du auch auf Jobs etc. zugreifen willst: - "Erlaube entfernte Verwaltung"

Zum obigen Fall 2) (CUPS-Server * 1.3.11 * auf terrix): ------------------------------------------------------- Obwohl ich, wie ich schon schrieb, die von Dir genannten Settings eingestellt habe, konnte ich nicht remote auf diesen Server zugreifen (403 Forbidden schon bei der Startseite). Nachdem ich die Einträge in den Locations so geändert habe, wie sie in der cupsd.conf des CUPS-Servers 1.1.10 auf helix stehen, klappt's auch beim terrix mit dem Remote-Zugriff. Das gilt in gleicher Weise für CUPS 1.3.7 auf neptix. Noch etwas bemerkenswertes, was ich nicht verstehe: Beide CUPS-Server auf terrix (1.3.11) und neptix (1.3.7) konnten zunächst nur die Startseite http://<rechner>.domain.local:631 an den Browser in korrekter Darstellung (die Links funktionierten dennoch) liefern, wenn 'HostNameLookups Off' eingestellt war. Seiten, wie http://<rechner>.domain.local:631/admin wurden falsch dargestellt, so, als wenn CSS-Dateien nicht gefunden wurden. Mit ausschließlicher Verwendung von IP-Nummern anstatt FQHNs hat es dann aber funktioniert. CUPS 1.3.7 und 1.3.11 leiten bei Eingabe obiger Admin-Adresse auf die entsprechende SSL-verschlüsselte Seite um (wohl wegen Encryption IfRequested), wobei bei 1.3.11 das Umleitungsziel anders lautet, nämlich https://192.168.x.y:631/admin. Bei CUPS 1.3.7 wird der FQHN nicht durch die zugehörige IP-Nummer ersetzt, weshalb die Darstellung auch solcher Seiten falsch war. Erst, wenn 'HostNameLookups On' eingestellt war, war die Darstellung der Seiten korrekt. Seltsamerweise war dies dann nicht mehr der Fall für Web-Adressen _mit_ IP-Nummer -- und dies reproduzierbar! CUPS 1.3.11 konnte jetzt also seine Web-Seiten nicht mehr korrekt liefern, während es bei CUPS 1.3.7 funktionierte, weil hier ja das Umleitungsziel https://<rechner>.domain.local lautet. Mit der Adresse http://localhost:631/admin war die Darstellung immer korrekt, aber halt nur lokal. Dann wurde es aber seltsam: Mittlerweile werden alle Web-Seiten beider CUPs-Server remote korrekt dargestellt, und zwar unabhängig von der Web-Adresse und unabhängig von http oder https. Ich kann 'HostNameLookups' nach Belieben ein und ausschalten, egal ob ich die CUPS-Server-Web-Seiten numerisch oder namentlich, ob SSL-verschlüsselt abfrage oder nicht -- das habe ich eigentlich von Haus aus so erwartet, nur: Warum nicht gleich so?

Natürlich muss bei den Druckern dann auch "Drucker publizieren" eingestellt sein, sonst kannst Du den von außen nicht sehen

Das gibt es in Version 1.1.10 noch nicht als expliziten Schalter bei den einzelnen Druckern (Menü 'Drucker'), wie das in 1.3.x der Fall ist.

außerdem solltest Du mal die /etc/cups/cupsd.conf mal durchsehen. Die Optionen dort sind relativ selbsterklärend.

Nachdem ich das nun, wenn auch nicht erschöpfend, getan habe, verstehe die Wirkung etlicher Direktiven noch nicht, und das trotz Doku -- die finde ich eher zu knapp :-( Aber ich habe mich auch noch nicht durch alles durchgearbeitet. Übrigens war bei der 1.1.10 die mitgelieferte Config wesentlich gesprächiger als bei den Versionen 1.3.x und ich habe daraus fast mehr gelernt, als aus der mitgelieferten Doku, zumindest bei den von mir benutzten Konfigurationsdirektiven. Dennoch kann ich jetzt 1. von allen Rechnern über den alten CUPS-Server (1.1.10) drucken, 2. von allen Rechnern aus den alten CUPS-Server (1.1.10) verwalten, 3. einen neuen CUPS-Server (1.3.11) mit der Funktionalität von 1. und 2. einrichten, was das Ziel war :-D Ich bedanke mich nochmals herzlich für Eure Anregungen. Viele Grüße, Tom P.S.: Jetzt muss ich /nur/ noch die PPD meines neuen Netzwerkdruckers verstehen lernen, denn da gibt es einige sehr kryptisch formulierte Treiberoptionen. Außerdem habe ich Probleme mit einer zweiten Queue mit Tonerspareinstellungen für meinen Netzwerkdrucker; Aufträge darüber werden stillschweigend und noch vor dem Druck abgebrochen, obwohl das Drucken über die erste Queue geht, auch wenn ich im KDE-Druckdialog die Treibereinstellungen auf die Werte ändere, die ich in der zweiten Queue voreinstelle. Also scheint es nicht an den PPD-Einstellungen zu liegen -- aber das ist ein anderes Thema, wo vielleicht auch der Support des Herstellers mitwirken muss. -- Um die Liste abzubestellen, schicken Sie eine Mail an: opensuse-de+unsubscribe@opensuse.org Um eine Liste aller verfuegbaren Kommandos zu bekommen, schicken Sie eine Mail an: opensuse-de+help@opensuse.org

Hallo Johannes, danke für die hilfreichen, weiterführenden Hinweise! Johannes Meixner schrieb:

Hallo,

On Apr 12 09:12 Thomas Michalka wrote (shortened):

...

Ich hätte eher erwartet, dass ein Eintrag, wie "Allow From .domain.local" entsprechende Hostname Lookups impliziert.

Kein Automatismis, denn siehe http://www.cups.org/documentation.php/doc-1.3/ref-cupsd-conf.html -------------------------------------------------------------------- HostNameLookups ... The default is Off to avoid the potential server performance problems with hostname lookups. Set this option to On or Double only if absolutely required. --------------------------------------------------------------------

Habe ich auch gelesen, aber ich kann mir nicht vorstellen, dass das Auflösen der Hostnamen in meinem LAN mit den paar Hosts ein nenneswertes Performanzproblem verursacht. Zumindest habe ich bei mir nicht mal im Ansatz dergleichen beobachtet. Aber warum keine implizite Einschaltung von HostNameLookups durch Namenseinträge? Wenn man Domain- oder Hostname-Einträge vornimmt, dann braucht man diese Option eben, sonst wären die namentlichen Einträge ja nutzlos. Gut, es könnte natürlich auch ohne Namenseinträge einen Grund geben für HostnameLookups, aber dazu habe ich nichts gefunden. Wenn man aus Gründen der Server-Performance keine HostnameLookups will, dann soll man eben auch keine Namenseinträge vornehmen. Aber zum Verständnis noch eine Frage: was macht CUPS bei HostnameLookups denn eigentlich technisch, dass diese zu einem Server-Performanzproblem werden könnten? Browser machen das ständig.

...

P.S.: Jetzt muss ich /nur/ noch die PPD meines neuen Netzwerkdruckers verstehen lernen,

Als ersten Einstieg, siehe http://en.opensuse.org/SDB:CUPS_in_a_Nutshell "What is a PPD file and how does it work?"

Die autoritative Doku zu PPD Dateien ist die "Adobe PostScript Printer Description File Format Specification" (ein PDF von Adobe, mit Google leicht zu finden) plus http://www.cups.org/documentation.php/doc-1.3/spec-ppd.html

Mit /usr/bin/cupstestppd kann man PPDs testen, vergl. http://en.opensuse.org/SDB:Information_for_Printer_Manufacturers_Regarding_L...

"PostScript Printers" -> "Technical Details"

Werde ich mir sicher zu Gemüte führen. Viele Grüße Tom P.S.: Aber mir geht's beim Verständnis der Optionen in einer PPD als Anwender eher um die Klärung von technischen, druckerspezifischen Begriffen, wie "Grafiken RGB Intent", "Farbtrennung" und "Kantenfestigkeit". Dagegen scheinen andere Begriffe, wie "Spardruck" und "RGB Graustufenbehandlung" als solche klar zu sein, aber die Auswirkung der Werteeinstellung, wie "Zusammensetzen Schwarz" ist oft nur im Ansatz verständlich oder sogar unverständlich. Hier kann vielleicht der Hersteller-Support Licht ins Dunkel bringen. Selbst die mitgelieferte Doku erklärt so gut wie keinen der Begriffe der "Printer Driver Settings" erschöpfend, bzw. ist in Teilen völlig unverständlich. Seitenweise Aufzählungen mit Driver-Settings-Beschreibungen der Art Match Paper Color Specifies the Match Paper Color. - The default setting is Off. sind nicht wirklich aufschlussreich, sondern lösen als typische Ingenieurserklärung höchstens ein etwas frustriertes "Aha" aus. Vielleicht habe ich in den über 300 bzw. 500 Seiten starken Handbüchern noch eine ausführlichere Beschreibung übersehen. -- Um die Liste abzubestellen, schicken Sie eine Mail an: opensuse-de+unsubscribe@opensuse.org Um eine Liste aller verfuegbaren Kommandos zu bekommen, schicken Sie eine Mail an: opensuse-de+help@opensuse.org

Hallo Johannes, Johannes Meixner schrieb:

Hallo,

On Apr 13 18:04 Thomas Michalka wrote (shortened):

...

Johannes Meixner schrieb:

...

http://www.cups.org/documentation.php/doc-1.3/ref-cupsd-conf.html -------------------------------------------------------------------- HostNameLookups ... The default is Off to avoid the potential server performance problems with hostname lookups. Set this option to On or Double only if absolutely required. --------------------------------------------------------------------

Habe ich auch gelesen, aber ich kann mir nicht vorstellen, dass das Auflösen der Hostnamen in meinem LAN mit den paar Hosts ein nenneswertes Performanzproblem verursacht.

Das Wort "potential" ist hier entscheidend, denn das Performanzproblem entsteht, wenn das Auflösen der Hostnamen einmal aus irgendwelchen Gründen nicht funktioniert und dann bekommt man minutenlange DNS Timeout-Verzögerungen, vergl. https://bugzilla.novell.com/show_bug.cgi?id=577936#c8

Verstehe. Da ich den Effekt, Hostnamen mal nicht auflösen zu können in meinem kleinen LAN höchstens dann hatte, wenn ich mal wieder an etwas gedreht habe, was ich dann aber meistens genau weiß, ist mir dieser Gedanke noch gar nicht gekommen. Allerdings, wenn ich da an frühere Einrichtungen einer Verbindung ins Internet denke ... es kam schon vor, dass man vergessen hat, die DNS-Server-IPs in die resolv.conf einzutragen, aber die Browser haben anscheinend nur sehr kurz Timeouts, weil sehr schnell die Meldung "unknown host" kommt. Kurze Timeout-Verzögerungen mit klarer Fehlermeldung wären mir auch bei CUPS lieber.

...

P.S.: Aber mir geht's beim Verständnis der Optionen in einer PPD als Anwender eher um die Klärung von technischen, druckerspezifischen Begriffen, wie "Grafiken RGB Intent", "Farbtrennung" und "Kantenfestigkeit". Dagegen scheinen andere Begriffe, wie "Spardruck" und "RGB Graustufenbehandlung" als solche klar zu sein, aber die Auswirkung der Werteeinstellung, wie "Zusammensetzen Schwarz" ist oft nur im Ansatz verständlich oder sogar unverständlich.

Das sind Begriffe aus der Drucktechnik, siehe z.B.:

http://de.wikipedia.org/wiki/Farbseparation http://de.wikipedia.org/wiki/Buntaufbau http://de.wikipedia.org/wiki/Unbuntaufbau http://de.wikipedia.org/wiki/Unterfarbenreduktion

Wäre ich nicht draufgekommen, da ich annahm, die Begriffe selber sind spezifisch für meinen Drucker. Ich verstehe bloß nicht, wie ein Druckerhersteller annehmen kann, die Endanwender seien auch Fachleute für Drucktechnik. Wenn in einem Handbuch Treiber- bzw. PPD-Einstellungen tabellarisch aufgelistet werden, dann sollte auch in einer für Nichfachleute verständlichen Sprache Näheres zur Bedeutung der verschiedenen Einstellungen dabei stehen. An anderer Stelle wird ja auch jeder Kleinkram erklärt, so dass man sich manchmal fragt, ob der Hersteller einem für minderbemittelt hält. Man hat mintunter das Gefühl, dass einerseits Ingenieure ohne Gefühl für die Anwendersicht und andererseits Bürokraten, die sich mit jedem Wort rückversichern wollen, die Handbücher schreiben.

Wenn es ein PostScript Drucker ist, dann muß der in der Lage sein, PostScript-Druckdaten im RGB Farbraum in seinen gerätespezifischen CMYK Farbraum umzuwandeln.

PS3, und er kann die Farbraum-Umwandlung. Interessant ist nur, dass er drei verschiedene RGB-Farbräume kennt und auch hierzu findet man so gut wie nichts in den hunderte Seiten starken Handbüchern. Ich muss mal sehen, ob ich irgend ein Forum o.ä. finde, wo sich Benutzer von Konica-Minolta-Druckern austauschen.

Ursprünglich hat PostScript nur den RGB Farbraum unterstützt und es war die alleininge Aufgabe eines PostScript-Ausgabegerätes, ggf. RGB Farben in einen ausgabegerätespezifischen Farbraum umzuwandeln. Das Ausgabegerät muß eben seinen Farbraum kennen und passende Umwandlungsfunktionen implementiert haben.

Im Prinzip ist das auch immer noch so, nur dass heutzutage Druckereien oft ihre Zuständigkeit dafür gerne an ihre Kunden weiterschieben und verlangen, dass der Kunde die Druckdaten im CMYK Farbraum anliefert wodurch die Druckerei von der heiklen Aufgabe der RGB->CMYK Umwandlung befreit ist, so dass falls die Farben im Ausdruck unschön aussehen, der "Fehler" natürlich alleine beim Kunden liegt weshalb er trotzdem zahlen muß.

Glücklicherweise habe ich eine günstige Druckerei gefunden, die bei Anlieferung von PDF-Dateien auch die Farbtöne nahezu perfekt hinbekommt.

Die RGB->CMYK Umwandlung ist heikel, weil es keine feste Formel gibt, wie man den Schwarzanteil generiert, denn der hängt u.a. von den tatsächlich verwendeten Farbpigmenten ab.

Die RGB<->CMY Umwandlung ist in beide Richtungen fest definiert und gäbe es perfekte Cyan-, Magenta- und Gelb-Farbpigmente, bräuchte man kein zusätzliches Schwarz (außer für 100% Schwarz, um Kosten für 300% Farbpigmente zu sparen).

Es ist der zusätzliche Schwarzanteil, der wegen der nicht perfekten Farbpigmente notwendig ist, dessen Bestimmung heikel ist und wenn sich das der Kunde aufdrücken lässt, hat die Druckerei einen möglichen Reklamationsgrund weniger am Hals und kann obendrein billiger anbieten was natürlich dem unwissenden Kunden gefällt (zumindest solange ihm auch das Druckergebnis gefällt ;-)

Also wäre es ratsam, Originaltoner bzw. -tinten (gibt es überhaupt Tintendrucker die PS verstehen?) zu kaufen, denn sonst könnte der Drucker im Extremfall falsche Farbtöne drucken (z.B. bei den heiklen Hautfarben).

Ich meine hier mit "Kunde" übrigens nur "normale Endkunden". Wenn Profis was gedruckt haben wollen, können und wollen die natürlich ggf. die RGB->CMYK Umwandlung lieber selbst machen, oft in enger Zusammenarbeit mit der Druckerei unter Beachtung des genauen Weißtons des Papiers u.v.m...

Ja, das war mir klar. In der PPD für den KM magicolor 4595MF gibt es eine Einstellung "Simulation", wo man anscheinend Einstellungen für verschiedene Papiertöne vornehmen kann. Den Begriff "Simulation" habe ich aber in dem Zusammenhang noch nicht verstanden, aber man arbeitet sich vorwärts, und: mühsam ernährt sich das Eichhörnchen. Viele Grüße, Tom -- Um die Liste abzubestellen, schicken Sie eine Mail an: opensuse-de+unsubscribe@opensuse.org Um eine Liste aller verfuegbaren Kommandos zu bekommen, schicken Sie eine Mail an: opensuse-de+help@opensuse.org