Ich glaube, der Großibär hat seine Kontaktdaten...
Leider nicht.
Seit seiner Hochzeit, seit der er Thomas Bernburg heißt, ist unser Kontakt abgerissen. Traurig, aber wahr, zumal wir seit der Schulzeit unzertrennlich waren. jaja, die Frauen machen alles kaputt.
Soweit ich mich erinnere, hat er einen Account bei StayFriends, da ich da aber nicht Gold-Mitglied bin, kann ich seine Kontaktdaten da auch nicht einsehen.
Original von DerGastWenn sich Ghostscript unter Win/Linux trotz S/W-PS-Input zum farbigen "PDF-Druck" überreden liesse, müsste das Ergebnis doch wie gewollt ausfallen, oder?
Ehrlich gesagt bin ich nicht mehr so firm in PS. Ist einige Jahre her, seit ich das letzte Mal damit gearbeitet habe.
Ich glaube, im PS-File wird irhendwo gesagt, dass die Darstellugn in S/W erfolgen soll, aber es werden die Vektorelemente trotzdem in Farbe uebermittelt. Wenn der Rasterizer die Farbraumangabe ignoriert, dann kommt in Farbe raus, was in Farbe uebermittelt wurde. Aber 100% sicher bin ich mir da nicht.
Original von Rainer
ich denke, Grossis Ausführungen zum Thema Umrechung RGB-CMY sind so nicht ganz korrekt.
Natürlich gibt es saubere Umrechungsformeln, die den RGB-Farbraum komplett in den CMY oder auch HSV umrechnen. Das habe ich im meinem Farben-Programm verwendet. Welches Modell ich verwende ist letzlich egal. Man kann jedes Bild verlust- und verfälschungsfrei zwischen diesen Farbmodelen hin- und herkonvertieren.
Natuerlich hast Du Recht, meine Ausfuehrungen waren etwas vereinfacht.
Grundsaetzlich ist es so, dass ein Monitor nicht RGB, sondern "RGBBl" darstellt. Nicht leuchtende Pixel sind schwarz. Daher enthält die Bildschirmdarstellung einen 'Aufheller'. Ein 'reines' RGB-gelb auf dem Bildschirm erscheint deshalb braun, weil ein Farbpixel schwarz bleibt.
Beim Drucker ist es aber umgekehrt, er stellt "CMYW" dar. Wo keine Farbe draufgesprueht wird, bleibt das Papier weiss. Es muss also nachgedunkelt werden statt aufgehellt.
Eine Umrechnung ist daher mehr als nur eine simple Formel. Und vor >20 Jahren, als GEOS entstand, wäre das ein mehr als nur ernsthaftes Problem gewesen.
Auf nem GHz-System führen die notwendigen Rechnungen natürlich nicht mehr zu Altersschwäche beim Benutzer.
Grundsätzlich gilt jedoch: der RGB Farbraum udn der CMY-Farbraum lassen sich zwar theoretisch ineinander ohen Verlust umrechnen, aber für die real darstellbaren Teile auf Monitoren und Druckern (und hier gibt es sogar Unterschiede zwischen Röhre und LCD) gibt es nur einen Überlappungsbereich. Da aber der Normaluser alle 16,7m Farbwerte von 24bit RGB verwendet, gibt es ein Problem. Es lassen sich definitiv nicht 16,7m verschiedene RGB-Werte vom Monitor in 16,7m identische CMY-Werte auf dem Drucker umrechnen. Windows trickst hier, und GEOS auch.
Wobei es natürlich hilft, wenn der Drucker 2400DPI oder mehr hat und man für das Auge fast unsichtbar rastern kann.
In der Druckindustrie wird das Problem dadurch gelöst, dass nur bestimmte, vorgegebene Farben überhaupt Verwendung finden (z.B. Pantone-Farbpalette), anstatt alle in RGB 'waehlbaren' Farben, die Monitore Spezialgeraete sind und aufwendig kalibriert werden, und die Drucker auch keine Straßenware sind.
Und der Knabe, die die Kundenvorlagen für den Druck aufbereitet, eine Spezialausbildung dafür hat.
Original von Rainer
Na und? Ist eben etwas helleres Gelb. rgb(255;255;85) (bei mit hat Gelb b=85) lässt sich als cmy(0;0;171) darstellen. D.h. es ist, wenn es denn unbedingt sein muss, eine farbgetreue Umrechung ins CMY-Modell möglich. Damit sehe ich keinen Grund, warum ein fehlerfreier Postscript-Translator die Farben vermatschen sollte.
Eebn das ist das Problem.
Ein reines RGB-Gelb waere 255,255,0, was auf einem Monitor (wegen des dann schwarz bleibenden dritten Pixels) braun aussieht. Also wird das dritte Pixel etwas 'angeleuchtet' (85).
Auf dem Drucker hingegen ist ein reines Geld 0,0,255. Was in RGB umgerechnet braun aussieht, während die Umsetzung des 'aufgehellten' gelbs auf dem Drucker kein vollflächiges gelb, sondern gelb mit weissen Stellen ('heller als gelb') ergibt.
Damit sattes gelb auch sattes gelb bleibt, müssen die beiden darstellbaren Farbräume 'beschnitten' werden. Was GEOS macht. Aber eben nicht nur beim Druck auf dem Tintenstrahler, sondern auch beim Export an den PS-Rasterizer, der das seinerseits nochmal macht.
Dann werde ich mich hie rmal kurz ein-(und wieder aus-)klinken.
1) Die GhostScript 'Treiber' enthalten ein paar Anpassungen speziell fuer den GhostSript interpreter. Hauptsaechlich bewirken sie, dass die Standardfionts (Roman etc.) vom interpreter geladen werden. Bei vielen 'echten' Druckern ist das standardmaessig der Fall. Bei GhostScript nicht.
Unter Windows gibt es das als Option ('PostScript Header') in allen PS Druckertreibern.
Ansonsten stellen die Druckertreiber nur die allgemeinen Parameter wie Seitenraender, Farbe (vorhandene hardware-zusatzfonts im Drucker, falls mit GEOS-FOnts vergleichbar) etc. ein und haben keinen Einfluss auf den ansonsten generierten PS-Code.
Der wird von der EPS library (eps.geo) generiert. Fuer alle PS-Drucker. Allerdings gibt es hier einige Unterschiede je nach PS-Level des Druckers.
Der Kernpunkt is also die EPS library.
Das Original hatte viele Bugs. so wurden z.B: nur B/W Bitmaps generiert und nur mit maximal 16 Graustufen (und Verzerrungen bei ungerader Pixelanzahl in der Breite).
Vektorelemente wie Linien und Text konnten hingegen schon immer in Farbe gedruckt werden.
Dabei benutzt die alte EPS-Lib eine Farb-Ersetzungstabelle feur alles. Die Neue nur noch bei farbigem Text.
Das Problem ist, dass Bildschirm-Farbraum und Druckerfarbraum sich nur teilweise ueberlappen.
Angenommen zwei Dreiecke. eines auf der Spitze.
In der Mitte ist weiss/schwarz, die Spitzen des einen sind rot, gruen, blau (die Spitzen selber sind 255/0/0 etc.)
die des anderen Cyan, Magenta und Gelb.
Ein reines Bildschirm-rot laesst sich nicht direkt in ein reines Drucker-rot umrechnen, da die rote Spitze weit ueber die Rote Verbindungslinie zwischen magenta und gelb hinausragt.
Ebenso ist ein reines gelb auf dem Drucker eigentlich '0,0,255', was auf dem Bildschitm in RGB umgerechnet (255,255,0) eher braun aussieht. Das Bildschirmgelb hingegen hat einen Weissanteil (255,255,128), der auf dem Drucker nur duch Rasterung darstellbar waere. Daher ist eine gewisse Umrechnung noetig.
Bei dem Erstentwurf des Canon-Druckertreiber fuer GEOS haben die dazu noetigen Tabellen ca. 6MB eingenommen. Die lahme Variante, die das berechnet, hat noch immer mehrere 100 KB gehabt.
Die EPS-Lib geht daher jetzt einen Mittelweg. Einfache, schnelle Umrechnung von RGB nach CMY unter Inkaufnahme von Farbaenderungen bei Vektorgrafik. Bitmaps (z.:B importierte JPGs) sollten richtig dargestellt werden.
Fuer GEOS-Generierte Bitmaps waere eine angepasste Farbtabelle sinnvoll. Bzw das Verwenden von direkt eingegebenen RGB-Werten passend zu CMY, auch wenn sie auf dem Bildschirm zu dunkel erscheinen (besonders bei gelb).
Vektorgrafiken werden uebrigens grundsaetzlich in Farbe an den Drucker weitergeleitet. Um die graurasterung kuemmert sich besser der PS-Rasterizer in maximaler Druckeraufloesung anstatt der GEOS-Rasterizer in Quellaufloesung. Farbdrucker, die man nicht forher auf S/W umgestellt hat, drucken dann natuerlich farbig.
Bei den Fonts hat sich etwas wesentliches geaendert. Die originale EPS lib hat immer nur den Standard-Font an den Drucker gesendet und fuer bold/italic diese rechnerisch im Postscript-Rasterizer erzeugt (Doppeldruck, Scherung), auch wenn im Original-Font separate Schnitte vorhanden waren.
Selbst wenn der Drucker die separaten Schnitte intern zur Verfuegung hat, wie bei Times Roman / URW-Roman.
Die neue EPS sendte tatsaechlich die verschiedenen Schnitte (italic is also wirklich italic und nicht oblique, und bold it bold und nicht nur doppelt breite Striche).
Allerdings habe ich damals keinen Weg gefunden, festzustellen, ob der Font wirklich separate Schnitte enthaelt. GEOS sagt da leider immer 'ja' und berechnet dann schnell was selber, wenn die EPSlib die Fontdaten haben will. Leider mit Bildschirmaufloesung. Man sollte also Fonts, die keine eigenen Schnitte fuer bold/italic haben, auch nicht mit bold/italic verwenden, wenn man PS drucken will.
Woran sieht man das? nun, von aussen eigentlich nur an der Groesse der fnt-Datei. Sie ist dann viermal so gross. 
(die vier Standard-Fonts haben sogar noch vorberechnete Pixelsaetze fuer die Standard-Bildschirmgroessen 10/12/14pt dabei, aber die werden nur vom Bildschirmtreiber verwendet)
Ich wollte das damals noch irgendwann beseitigen, aber mit dem Tod von NewDeal und der langen Durststrecke danach ist es nie dazu gekommen. Der Lebensunterhalt war da wichtiger, und so viel Exemplare habe ich ja nicht verkauft, dass ich dieZeit dafuer haete abzweigen koennen.
Allerdings gab es mal ein Update, in dem ich noch ein paar Kleinigkeiten gegenueber dem ersten Release verbessert hatte. Das ist aber auch schon ~9 Jahre her. Und betraf, glaube ich, nur die "Druckertreiber", nicht die EPS-Lib.
Ich hoffe, alle Klarheiten sind jetzt beseitigt.
