Post by Gerald EÃscher[Unterschied von foomatic zu Gutenprint]
Danke, nun ist mir einiges klarer.
Wobei man noch hinzufügen sollte, daß unter Unices != MacOS X und Linux
GhostScript natürlich eine zentrale Rolle auch bei Gutenprint spielt,
nachdem die meisten Programme nativ PostScript ausspucken. GhostScript
wird seitens CUPS, konkret des pstoraster-Filters, und des "cups"-Device
genutzt, um die einkommenden Druckdaten in "CUPS Raster Format" zu
wandeln (eine simple bunte Bytemap, d.h. ein gerendertes Abbild der
Druckseite), das dann Gutenprint nimmt, rastert (inkl. Spezialitäten wie
Weaving [1], um auf Tintenspritzern eine maximale Ausgabequalität zu
erzielen) und in die individuelle Druckersprache des Zielgeräts umsetzt
(bspw. PCL für HP-Drucker, ESC/P2 für Epsons, etc.)
D.h. unter Linux bspw. sieht's dann so aus, um auf einen Epson-
Tintenstrahler auszugeben:
Programm --> PS --> GhostScript --> CUPS Raster Format --> Gutenprint --> ESC/P2
Auf dem Mac hingegen sieht der Weg Richtung Gutenprint so aus (wenn man
nix kaputtkonfiguriert hat bzw. unpassende PPDs nimmt):
Programm --> PDF --> cgpdftoraster-Filter --> Gutenprint --> ESC/P2
Programm --> PS --> pstocupsraster-Filter --> Gutenprint --> ESC/P2
D.h. es braucht -- ab 10.3 -- kein GhostScript, weil MacOS X PDF "kann"
als Teil von CoreGraphics (das "cg" im cgpdftoraster-Filter steht dafür)
und für den seltenen Fall, daß Programme direkt PS erzeugen in Form von
Apples PSNormalizer Framework einen von Adobe lizensierten PostScript-
Interpreter an Bord hat (der pstocupstaster-Filter macht nix weiter
als in einem Schritt PostScript nach PDF zu wandeln und dann dieses
wiederum per CoreGraphics rendern zu lassen, natürlich in CUPS' Raster
Format)
D.h. unter MacOS X braucht's halt schlichtweg seit 10.3 kein GhostScript
mehr, weil auch ohne gs bereits alles an Bord ist, um auch PostScript
korrekt in CUPS Raster Format zu bringen und damit spezialisierte echte
Treiberpakete wie bspw. Gutenprint oder HPIJS mit Rasterung und
Umwandlung in die eigentliche Druckersprache beauftragen zu können.
Aber selbst wenn GhostScript im Rahmen von Gutenprint ins Spiel kommen
würde, gibt es noch einen zentralen Unterschied zum foomatic-Ansatz.
Zuerst zu den Gemeinsamkeiten: Sowohl Gutenprint als auch foomatic
erstellen anhand von Drucker-Datenbanken PPDs (PostScript Printer
Description) für Drucker, die gar kein PostScript können (müssen). Ziel
ist, einkommendes PostScript $irgendwie zu rendern, rastern und dann in
die druckerspezifische Sprache umzusetzen und dabei dem Anwender die
Möglichkeit zu geben, so viele Features des Druckers wie möglich auch zu
nutzen (bspw. verschiedene Qualitätsmodi, Druckerschächte, etc.)
Der Clou ist, daß diese speziellen Druckerfähigkeiten als PPD-Features
kodiert werden und dann
- bei foomatic dafür sorgen, daß der entsprechende gs-Aufruf bzw. das
die eigentliche Render- *und* Raster-Arbeit durchführende GS-Device
entsprechend passend ausfällt (kann bisweilen ein rechter Parameter-
Bandwurm werden, der da entsteht bzw. mit dem gs dann aufgerufen wird)
- bei Gutenprint dafür sorgen, daß das CUPS Raster Format, das per
GhostScript (bzw. am Mac PSNormalerizer Framework oder CoreGraphics)
mit immer identischen Parametern erzeugt wurde, vom entsprechenden für
den Druckertyp passenden Gutenprint-Treiber passend geraster wird (da
gibt es je Tintenspritzer ideale Algorithmen) und dann passend in die
Druckersprache umgesetzt wird (und dabei kommen auch Control-Codes ins
Spiel, die bspw. den Qualitätsmodus bestimmen oder die Schachtwahl und
so Zeugs)
D.h. bei foomatic wird in den PPDs nur kodiert, wie GS bzw. das
spezifische für den Drucker zuständige Device parametrisiert werden
muß/soll, während bei Gutenprint GS immer den gleichen Job macht (CUPS
Raster Format mit spezifischer Auflösung rendern) und Rasterung und
Umwandlung Sache des nachgelagerten eigentlichen Druckertreibers sind
(und die Kunst in dem Fall darin besteht, PPD-Parameter durchs
Drucksystem bis hinten raus zu dem spezifischen Treiber durchzuschleusen
anstatt wie bei foomatic einen GS-Parameter-Bandwurm zu erzeugen)
Post by Gerald EÃscherPost by Thomas KaiserZudem ist es ja noch so, daß Drucker ggf. mehrere Druckersprachen
unterstützen, bspw. neben PCL auch noch PostScript nativ. D.h. es
hier meist völlig unnütz ist, den Drucker per PCL anzusteuern, wenn
er doch direkt PS spricht.
Jein. Bei einem Lexmark Optra E312 habe ich die Erfahrung gemacht,
dass er mit PCL schneller druckt, jedenfalls unter Windoof. Ich
vermute, PCL ist für den Drucker weniger rechenaufwändig als
PostScript und moderne PCs rendern halt schneller als alte Drucker.
Das zum einen. Unter Windows ist es aber auch noch so, daß PCL hier
anders genutzt werden könnte. Während PCL aus CUPS heraus immer nur ein
gerendertes und bereits gerastertes Seitenabbild enthält, d.h. in PCL
verpackt immer nur eine große die ganze Seite beinhaltende Bitmap zum
Drucker geschickt wird, _könnte_ es Dir unter Windows passieren, daß in
PCL auch grafische Primitive wie Text, Vektorgrafiken und Bilder als
Elemente existieren. Das grafische Modell von PCL ist zwar deutlich
primitiver als das von PS/PDF aber für Vieles auch ausreichend. Und grad
im hochvolumigen Druckbereich macht sich das sehr bemerkbar, ob ein
Drucker für das Verarbeiten einer Seite 0,05 Sekunden oder 0,5 Sekunden
braucht. Aber für diese Aufgabenstellung gibt es auch schon wieder
spezialisiertere Druckersprachen wie bspw. AFP [2]
Ein weiterer Grund, einen an und für sich PostScript-tauglichen Drucker
nicht per PS anzusteuern sondern bspw. per PCL wäre, daß man "hübschere"
Ergebnisse bekommt, einfach mal der Rasterizer im PS-Interpreter des
Druckers nicht so toll ist (macht sich in Detailauflösung und Halbton-
abstufungen bemerkbar). Ich hab bspw. jahrelang eigentlich PS-fähige
HP-Laserjets per PCL angesteuert, weil mit GhostScripts lj4dith-Device
eine frequenzmodulierte Rasterung auf den Dingern möglich war (d.h. viel
feinere Details und Grauverläufe druckbar)
Aber es gibt auch Nachteile am Mac (seit MacOS X). So kann bspw. nach
wie vor bei nicht-PS-Druckern (bzw. der Ansteuerung als "raster printer",
d.h. CUPS rendert/rastert den Druckjob und schickt ihn dann als PCL oder
ESC/P2 bzw. $irgendwas-aber-kein-PostScript an den Drucker) im
Druckdialog gesagt werden, daß man die erste Seite aus Schacht 1 und die
Folgeseiten aus Schacht 2 haben will. Wird der Drucker per PostScript
angesteuert, dann geht das hingegen.
D.h. bei Druckern, die sowohl PS als auch andere Sprachen wie bspw. PCL
können, kommt's halt drauf an, was einem wichtiger ist. Qualität und
Ausgabetempo sind oft höher, wenn man _nicht_ per PS ausgibt. Die
Flexibilität (und Unabhängigkeit von Treibern) ist dagegen bei PS höher.
Hat aber alles nix mit GhostScript zu tun, weil es das -- ich wiederhole
mich -- seit 10.3 am Mac zum Drucken nicht mehr braucht. Ausnahme:
Exotische oder uralte Drucker, für die es sinnvolle Ansteuerung nur
mittels eines echten GhostScript-"built in"-Treibers gibt (wie im Falle
Deines Canon und GS' bjc600-Device)
Gruss,
Thomas
[1] Siehe bspw. <http://gutenprint.sourceforge.net/developer-html/c1717.html>
[2] <http://en.wikipedia.org/wiki/Advanced_Function_Presentation>