Hallo Werner,
Schickst Du mir auch die D64 Images?
Danke und Gruß,
Lars
Es gibt 116 Antworten in diesem Thema, welches 48.170 mal aufgerufen wurde. Der letzte Beitrag (
Hallo Werner,
Schickst Du mir auch die D64 Images?
Danke und Gruß,
Lars
Hallo Werner,
Dann TestA.RTF : Hier habe ich "ShowPageNumbers" in D64Lister aktiviert. Ich frage mich hier, wo das {0000} vor "----page 1---" herkommt. Im originalen Dokument ist da nirgends "BSW" definiert.
Wenn ich "ShowPageNumbers" deaktiviere, stimmt alles (TestB.RTF).Bei der Definition des Fonts "BSW 128" ist auch ein Fehler (TestC.RTF; letzte Zeile). Da steht {0128} , das müßte eigentlich {0032} sein. (siehe GEOS Fonts als TrueType ). OK, habe ich dort blöd formatiert .
Moment... Die Zahlen in {}, also die FontIDs, lese ich direkt aus dem GeoWrite Dokument. Da ist nichts mit Definition! Die Nummer steht da so drin.
Zur {0000} bei Show Page Numbers:
Ja, das setze ich. Da die aller erste Pagenummer ausgegeben wird, bevor ich etwas eingelesen habe, wird hier FontID 0, Größe 9, kein Style verwendet.
Gruß,
Lars
Edit:
Ich habe meine Fonts mal nach ID 128 durchsucht:
"Textur 1" FON GeoFont 2.0 Font ID : 128 Sizes : 32 Entwurf: Herbert Leuschner 16.04.1990 16:19
Wenn der Font nicht vorhanden ist, wählt GeoWrite vielleicht BSW, ID0 (bei Dir BSW128, ID32) aus?
Und noch einmal zur Verdeutlichung:
Die FontIDs in {} stehen so im GeoWrite Dokument bei jedem Style Change drin (ich zeige sie aber nur an, wenn sich die ID zum vorherigen Wert geändert hat). Die Ersetzung über die FontTable ist von der Anzeige unabhängig. Wenn die Ersetzung aktiviert wurde, nehme ich die ID und schaue in der FontTable nach, ob sie vorhanden ist. Wenn ja, dann wird der Font Name des Tabellen Eintrages als Font verwendet. Wenn nein, wird der Font Name des ersten Tabellen Eintrages benutzt.
Gruß,
Lars
Zur {0000} bei Show Page Numbers:
Ja, das setze ich.
Kann man das da nicht einfach weglassen? Irritiert doch eigentlich nur. Und wiederholt sich auf jeder Seite.... ![]()
Das mit "BSW 128" muss ich mir nochmal ansehen. Im MegaAssembler Hanbuch steht $20 (was 32 wäre). Aber das muss ja nicht unbedingt stimmen ....
Schickst Du mir auch die D64 Images?
Kommt anbei. Habe jetzt aber nur den Stand TestC.RTF hier. Habe parallel unter WinVice MP3-128 laufen und habe mir das Geowrite-Dok "Install.dok" jedesmal auf einem D64 geändert/angeschaut .... Der Font Commodore_GE ist da auch mit drauf.
Gruß
Werner
Nachtrag:
Ich habe meine Fonts mal nach ID 128 durchsucht:
Problem dabei:
"BSW 128" gibt es nicht als einzelnen Font. Die Austausch-Fonts aus "ChangeBSW" haben alle IDs ab 1000....
Arial häufig benutzt heute gab es schon sehr früh
Hallo Werner,
Kann man das da nicht einfach weglassen? Irritiert doch eigentlich nur. Und wiederholt sich auf jeder Seite....
Auf der Nachhausefahrt von der Arbeit habe ich nocheinmal darüber nachgedacht. Ich wollte die Anzeige der Zeitenzahlen einheitlich mit dem Standard Font haben, deshalb setze ich vor _jeder_ Seitenzahl Anzeige den Font auf Standard. Dies wird durch die neue FontID Anzeige nun immer mit angezeigt. Anderen Falls würde die Seitenzahl in dem jeweilig benutzten Font, Style und Größe angezeigt werden. Das sah früher super mistig aus. Nein, möchte ich nicht weglassen. Sorry für den Kompromiss.
Bei der Definition des Fonts "BSW 128" ist auch ein Fehler (TestC.RTF; letzte Zeile). Da steht {0128} , das müßte eigentlich {0032} sein. (siehe GEOS Fonts als TrueType ). OK, habe ich dort blöd formatiert .
OK. Ich habe den fraglichen Sektor (im BAMViewer Rechtsklick auf Track 21, Sektor 4) mal angehängt, hier aber auch zu sehen:
00000 00 EA 45 4F 53 2E 45 64 69 74 6F 72 22 20 76 6F @³eos.eDITOR" VO
00010 72 67 65 6E 6F 6D 6D 65 6E 20 77 65 72 64 65 6E RGENOMMEN WERDEN
00020 2E 0D 0D 0D 4E 65 75 65 72 65 20 56 65 72 73 69 .mmmnEUERE vERSI
00030 6F 6E 65 6E 20 64 65 72 20 50 61 74 63 68 65 73 ONEN DER pATCHES
00040 20 75 6E 64 20 77 65 69 74 65 72 65 20 41 6E 70 UND WEITERE aNP
00050 61 73 73 75 6E 67 65 6E 20 73 69 6E 64 20 61 75 ASSUNGEN SIND AU
00060 66 20 6D 65 69 6E 65 72 20 48 6F 6D 65 70 61 67 F MEINER hOMEPAG
00070 65 20 28 68 74 74 70 3A 2F 2F 77 77 65 69 63 68 E (HTTP://WWEICH
00080 74 2E 68 6F 6D 65 70 61 67 65 2E 74 2D 6F 6E 6C T.HOMEPAGE.T-ONL
00090 69 6E 65 2E 64 65 29 20 7A 75 20 66 69 6E 64 65 INE.DE) ZU FINDE
000A0 6E 2E 0D 0D 28 77 29 20 32 30 31 30 0D 17 09 00 N.mm(W) 2010mwi@
000B0 00 57 65 72 6E 65 72 20 57 65 69 63 68 74 17 4A @wERNER wEICHTwj
000C0 20 00 0D 17 09 20 00 45 2D 4D 61 69 6C 3A 20 77 @mwi @e-mAIL: W
000D0 77 65 69 63 68 74 3E 61 74 3C 74 2D 6F 6E 6C 69 WEICHT>AT<T-ONLI
000E0 6E 65 2E 64 65 17 4A 20 00 0D 00 04 85 F0 1D C8 NE.DEwj @m@dEÚ]H
000F0 D0 F3 AD 04 85 10 14 29 7F C9 30 90 0E C9 3A B0 P´ÀdEpt)\I0PnI:Ú
Alles anzeigen
Mit 17 wird ein Style Escape ausgeführt (im beigefügten rtf farbig markiert) (alle Zahlen sind HEX).
1. Nach "(W) 2010" kommt 17 09 00 00 -> (00*100+00)>>6 = 00 -> FontID {0000}, Größe 09
2. Nach "Weicht" kommt 17 4A 20 00 -> (20*100+4A)>>6 = 81 = 129 Dez -> FontID {0129}, Größe 10 (4A & 3F). Danach kommt ein Return (0D)
3. Danach kommt sofort wieder 17 09 20 00 -> (20*100+09)>>6 = 80 = 128 Dez -> FontID {0128}, Größe 9 (09 & 3F).
4. Nach "ONLINE.DE" kommt 17 4A 20 00 -> (20*100+4A)>>6 = 81 = 129 Dez -> FontID {0129}, Größe 10 (4A & 3F). Danach kommt wieder ein Return (0D).
Und Ende.
Also, es steht so wie angezeigt im Dokument drin. Da kann ich nichts machen ![]()
Der Import von Commodore_DE hat zunächst geklappt. Ich muss mich aber noch weiter reinarbeiten, zu benutzen war der Font jetzt nicht...
Gruß,
Lars
Hauptproblem ist, das die Tools immer von einer festen Breite ausgehen (ist das ein Merkmal von Bitmap Fonts?), die GEOSFonts aber teilweise Proportional Fonts sind und nicht in das Raster passten.
Nein, das ist kein Merkmal von Bitmap Fonts. Das ist ein Merkmal von monospaced Fonts. Allerdings ist es wirklich nicht leicht, (einfache und günstige) Tools für die Erstellung von 1-Bit Bitmap-Fonts zu finden. Ich habe ganz gute Erfahrungen mit folgendem Online-Tool gemacht:
Bitte melde dich an, um diesen Link zu sehen.
Die Char-Breiten ergeben sich hier einfach aus den gesetzten Pixeln. Beim Generieren kann man angeben, wieviele (weiße) Pixel Abstand (zumeist 1) man zugeben möchte.
Nur sehe ich da keine große Chance für eine automatische Übernahme von existierenden Bitmaps. Profi-Tools, wie z.B. FontLab Studio können auch Bitmaps erstellen, allerdings erwarten solche Programme zumeist auch einen Vektor-Font, den man eigentlich zuerst anlegt. Aus dem werden dann Bitmaps vorgeneriert und auch die Bitmap-Breiten berechnet. Beim Export kann auch aufgrund der Komplexität auch einiges schiefgehen.
Mit dem verlinkten Bitmap-Fonttool erzeugt man TrueType- (bz.w. OpenType-) Fonts, die nur die Bitmaps enthalten, also eigentlich unvollständig sind und auch eher ungewöhnlich. Das ist nicht das gleiche, wie bei Berkelium, die aus echten Vektoren besteht, nur eben im Look von Bitmap Fonts.
Vielleicht können wir uns ja mal zusammen setzen und diskutieren, was ich im D64Lister noch einbauen kann, um ein Export der GEOS Fonts und einen anschließenden Import zu einem PC Font zu ermöglichen / zu verbessern?
Wegen mir können wir das gerne tun. Die Frage ist halt, ob es wirklich das Ziel sein sollte, die pixelige Darstellung von GeoWrite auf den PC herüber zu retten oder ob es nicht zielführender wäre, möglichst gut aussehenden Ersatzfonts zu suchen. Der Ausdruck mit den Bitmap-Fobts hätte ja nicht einmal die Qualität der LQ-Font-Ausgabe, von Laserqualität ganz zu schweigen. Ich gehe eigentlich davon aus, dass die Mehrheit lieber Dokument-Ausdrucke hätte, die über die Möglichkeiten von früher hinausgehen und nicht noch schlechter sind.
Wenn man richtig Spaß mit Fonts haben möchte und gleichzeitig die Druckausgabe von damals möglichst optimal nachstellen, dann müsste man eigentlich nicht die Bildschirm-Fonts nachbauen, sondern möglichst gute Ausdrucke (LQ) einscannen und diese Zeichen einzeln vektorisieren (und etwas optimieren) und daraus TrueType-Fonts erstellen. Wenn man dann vom PC aus druckt, hätte man ein Ergebnis, wie man es unter optimalen Bedingungen auch am C64 gehabt hätte.
Was das Zusammensetzen angeht: Entweder wir finden einen Termin oder du kommst mal vorbei, wenn sich die BAUD-Gruppe (eigentlich Amiga-Leute aber offen für alle Vintage-Systeme) alle 3 Wochen in wechselnden Kneipen und Restaurants trifft.
Hallo Retrofan,
Wegen mir können wir das gerne tun. Die Frage ist halt, ob es wirklich das Ziel sein sollte, die pixelige Darstellung von GeoWrite auf den PC herüber zu retten oder ob es nicht zielführender wäre, möglichst gut aussehenden Ersatzfonts zu suchen. Der Ausdruck mit den Bitmap-Fobts hätte ja nicht einmal die Qualität der LQ-Font-Ausgabe, von Laserqualität ganz zu schweigen. Ich gehe eigentlich davon aus, dass die Mehrheit lieber Dokument-Ausdrucke hätte, die über die Möglichkeiten von früher hinausgehen und nicht noch schlechter sind.
Ja, davon gehe ich aus aus und es wäre / war auch mein Anliegen (deshalb wurden die GeoWrite Texte nun schon 17 Jahre in Arial ausgegeben). Ich möchte auch nur die Möglichkeit bieten, es selbst zu entscheiden, was man macht. Ich denke, die Möglichkeit der Font Ersetzung über die FontTable ist der richtige Schritt. Ich möchte dies aber auch nicht in's unendliche Treiben (z.B. Ersetzungen mit allen Fontgrößen, usw.).
Bzgl. Treffen würde ich zunächst mal bei Dir vorbeischauen. Wir können ja mal einen Termin per PM abmachen? Ich bringe einen Laptop mit Windows und GEOS Sachen mit, damit Du dir das mal anschauen kannst.
Gruß,
Lars
Hallo Lars,
Wenn der Font nicht vorhanden ist, wählt GeoWrite vielleicht BSW, ID0 (bei Dir BSW128, ID32) aus?
Ja, aber nur für die Anzeige. Im Schriftarten-Menü von Geowrite ist dann aber kein Font ausgewählt (kein * vor den Font-Namen).
OK. Ich habe den fraglichen Sektor (im BAMViewer Rechtsklick auf Track 21, Sektor 4) mal angehängt, hier aber auch zu sehen:
Ja, das sehe ich hier auch direkt in Geos/MP3 mit einem Diskmonitor .... ![]()
Ich habe es jetzt probiert und einen vorhandenen 9 Punkte-Font die ID: 128 gegeben. Wenn ich damit einen Text in Geos 64/MP3-64 schreibe und diesen dann mit Geowrite 128 in Geos 128/MP3-128 öffne, ist BSW 128 aktiv. Damit ist sicher, "BSW 128" hat die ID: 128 .
Wieder ein Fehler im MegaAssembler-Handbuch ....
Auf Seite 415 (Anhang H) muss es also korrekt heissen:
"für die Zeichensätze BSW und BSW 128 die Kennzahlen 0 und 128 reserviert. Die"
Allerdings kann ich nicht sagen, ob das auch für Geos 2.0 US gilt. Wenn ich einen amerikanischen Text durch D64Lister jage, tauchen da einstellige Font-IDs auf. Dazu habe ich das hier gefunden:
Font files are identified by a unique ID number which is
stored in the file's info sector at offset 130. The info sector
contains a word identifier for each point size in the font. These
identifiers have the form: ID# * 8 + point size. In other words,
bits 15-6 represent the font number while bits 0-5 hold the point
size. These ID words are used by GEOwrite and GEOpaint.
0 BSW 13 Tilden
1 University 14 Evans
2 California 15 Durant
3 Roma 16 Telegraph
4 Dwinelle 17 Superb
5 Cory 18 Bowditch
6 Tolman 19 Ormond
7 Bubble 20 Elmwood
8 Fontknox 21 Hearst
9 Harmon 21 Brennens (BUG)
10 Mykonos 23 Channing
11 Boalt 24 Putnam
12 Stadium 25 LeConte
Alles anzeigen
Ich hänge hier mal ein D64 mit US-Geos-Texten an.
Gruß
Werner
Hallo Werner,
Allerdings kann ich nicht sagen, ob das auch für Geos 2.0 US gilt. Wenn ich einen amerikanischen Text durch D64Lister jage, tauchen da einstellige Font-IDs auf. Dazu habe ich das hier gefunden:
Oh, ja, stimmt. Da wird ein Unterschied zwischen University_Ge (ID 56) und University (1) gemacht. Dann muß man die entsprechenden US FontIDs auch in die FontTable mit eintragen:
z.B. California
2=Times New Roman
57=Times New Roman
Die Umlaute mache ich ja über die Option.
Gruß,
Lars
Hallo C=Mac,
Hallo Lars,
Als ich den Stylus Color 980 noch hatte, hab ich es ausprobiert.
Hast Du da eventuell noch irgendwo farbige Ausdrucke von Deinem Dokumenten, die mit PrintText gedruckt wurden? Wenn ja, kannst Du da irgendwie ein Bild von machen?
Mich stört ein wenig die Farbe der 1. Überschrift in der Anleitung (Anhang "PrintText.zip" hier: Bitte melde dich an, um diesen Link zu sehen. ). Soweit ich das gesehen habe, soll das "Cyan" sein.
Ist "Cyan" nicht eher ein helleres blau?
Zum Vergleich habe ich mal einen Probeausdruck von meinem HP Deskjet 690 (lang lang ist es her ....) eingescannt.....
Gruß
Werner
PT_Anleitung.pdf zeigt die erste Seite wie D64Lister sie erstellt, HP DJ-Farben.pdf zumindest Cyan, wie ich es mir vorstelle .... ![]()
Ist "Cyan" nicht eher ein helleres blau?
Sozusagen. Cyan ist eine der drei Grundfarben der subtraktiven Farbmischung (Körperfarben): Cyan, Magenta, Gelb.
Deren Komplementärfarben, die Grundfarben der additiven Farbmischung (Lichtfarben), liegen auf dem Farbkreis jeweils gegenüber: Rot, Grün, Blau.
Bitte melde dich an, um diesen Anhang zu sehen.
Hast Du da eventuell noch irgendwo farbige Ausdrucke von Deinem Dokumenten, die mit PrintText gedruckt wurden? Wenn ja, kannst Du da irgendwie ein Bild von machen?
Muss mal sehen ob ich noch einen Ausdruck habe. Die Dateien hab ich sicherlich noch, dies hilft Dir aber nichts.
Ich kann es einfach Einscannen.
Gruss C=Mac.
Hallo Werner,
Mich stört ein wenig die Farbe der 1. Überschrift in der Anleitung
Es sind die gleichen Farben wie bei GeoPaint und PhotoScraps / PhotoAlbums. Wie gesagt, basierend auf der Vice Farbpalette von ca. 2000.
Ausdrucke sind doch eher schlecht mit C64 Farben zu vergleichen, da hier auch Farbanpassungen gemacht werden.
Du meinst die Überschrift "Anleitung für"? Ich checke das morgen, was das sein sollte. Nach Cyan sieht das für mich auch nicht aus.
Gruß,
Lars
Wie gesagt, basierend auf der Vice Farbpalette von ca. 2000.
Das könnte damals sogar noch die ungetweakte (also weit von der "Realität" entferne) Palette von Peptos Website gewesen sein. Über die Jahre hinweg hat das VICE-Team mit allerlei Tricks (ich sage das hier mal zusammenfassend und despektierlich) versucht, mit dieser Basis eine bessere Farbdarstellung hinzubekommen – und hat das meines Erachtens in den letzten Releases auch immer besser hinbekommen. ALeX und ich haben vor rund 10 Jahren (da war die VICE-Darstellung noch einiges schlechter als heute) das Ergebnis angezweifelt, weil es einfach nicht zur (von uns so wahrgenommenen) Realität passte und das Bitte melde dich an, um diesen Link zu sehen. Projekt ins Leben gerufen. Kurz gesagt basiert die von uns ermittelte Farbpalette auf einer Mittelung von wahrgenommenen Farben durch freiwillige "Probanden" (Projektteilnehmer) auf unterschiedlichster Hardware. Da es keine mathematisch eindeutige Umrechnung der C64-Farben auf RGB gibt, erschien uns das Verfahren als das Probateste, um auch alle modernen Umrechnungsverfahren der PCs bei ihrer Farbdarstellung (Color-Management, Colorboost, Farbprofilierung etc) und auch den sehr unterschiedlichen Gerätepark (vor allem Bildschirmtechnik) mit einzubeziehen.
Es ging ja darum, die 16 PAL-Farben (NTSC und SECAM haben wir, wie Pepto, ausgeklammert) des C64 auf heutiger Hardware möglichst ähnlich zu treffen – was immer nur ungenau passieren wird, weil einfach der Park der Ausgabegeräte zu unterschiedlich ist. Ziel des Projektes war aber nicht in erster Linie eine gute Farbdarstellung in Emulatoren – da kann sich gerne jeder auf seiner Kiste einstellen, was ihm gefällt– sondern eine allgemein gültige Palette zu finden (daher auch kein Set von Paletten), um damit z.B. C64-Screenshots (aus VICE und Co.) zu versehen, damit sie auf Webseiten von allen Betrachtern als brauchbare C64-Darstellung wahrgenommen wird. PNGs, GIFs und JPGs (und auch Browser) haben nun mal keine TV-Regler zum Anpassen der Farben und nur die wenigsten User werden ihren PC global auf C64-Darstellung hin optimieren wollen.
Ob VICE heute die "neuen Pepto"-Farben verwendet, nachdem Pepto seine Theorie kürzlich Bitte melde dich an, um diesen Link zu sehen. hat, weiß ich nicht, weil das Thema für mich eigentlich abgehakt ist – es kann aber gut sein. Kurz: ich würde als Basis immer eine andere Palette nehmen als die von VICE aus dem jahre 2000. Entweder eine aktuelle VICE-Palette (und zwar nach dem PAL-Tweaken, nicht die von davor) oder aber unsere Coco-Palette der gemittelt wahrgenommenen Farben, wenn es darum geht, die C64-Farben auf dem PC (ohne weitere, individuelle Einstellungen) möglichst ähnlich anzuzeigen.
Bitte melde dich an, um diesen Anhang zu sehen. Coco 1.2
Bitte melde dich an, um diesen Anhang zu sehen. [Edit:] Ergänzt um Peptos Palette (50/100/70)
Bitte melde dich an, um diesen Anhang zu sehen. Eine Palette (50/100/50) aus der neuen Pepto-Berechnung
Das zu Bildschirmfarben. Bei eurer Darstellung innerhalb von GeoWrite-Dokumenten müsst ihr euch aber wahrscheinlich zusätzlich entscheiden, ob ihr die Darstellung auf dem C64-Bildschirm übernehmen/simulieren wollt oder den späteren Ausdruck. Denn die alten Drucker haben sich einen feuchten Kehricht um die Bildschirmdarstellung geschert. Die hatten ihren eigenen Cyan-, Rot- oder auch Blau-Wert. Wenn ihr also den Druck, nicht den Bildschirm, nachempfinden wollt, dann müsstet ihr beispielhafte GEOS-Farbausdrucke mit einem Bitte melde dich an, um diesen Link zu sehen. ausmessen und die ermittelten Farben im Dokument verwenden. Denn heutige Drucker(treiber) kümmern sich sehr wohl um die Farben, wie sie im Dokument vorkommen.
Farbe ist halt nicht so einfach – war es damals nicht und ist es auch heute nicht. Das liegt im Prinzip: zum einen gibt es nicht-deckungsgleiche Farbräume (RGB, CMYK, YUV ...), zum anderen sind alle diese Farbräume (im Gegensatz zu LAB) "geräteabhängig". Also ohne Zusatzinformationen zu den verwendeten Geräten (heute in Profilen versteckt) gibt es keine brauchbare Umrechnung – und sie gilt auch immer nur für eine eingestellte Kombination (üblicherweise der eigenen).
Hallo,
Zunächst Danke, Retrofan, für die Erklärungen. Aber:
Die Farbzuordnungen im D64Lister sind an dieser Stelle falsch. Ich muss noch schauen, woran das liegt. Wenn ich die vordefinierten Farben meines Entwicklungstools nehme (z.B. clRed), wird es auch rot (oder Cyan in der besagten Überschrift bei der entsprechenden Definition clAqua). Bei Verwendung des RGB Wertes 0x30E6C6 wird der Text in eher gelb ausgegeben, obwohl Bitte melde dich an, um diesen Link zu sehen. Seite auch Cyan angibt.
Danke, Werner, für den Hinweis.
Gruß,
Lars
Ah, gefunden.
Die Struktur CHARFORMAT, die Windows für das Ändern über die Message EM_SETCHARFORMAT nutzt, nutzt für die Farbe die Typendefinition der Farbe COLORREF siehe Bitte melde dich an, um diesen Link zu sehen.. Der kann man nicht einfach über RGB Werte zuweisen.
Gruß,
Lars
Die Farbzuordnungen im D64Lister sind an dieser Stelle falsch.
Das kann unabhängig von meinen Ausführungen ja auch sein, ändert aber nichts an der Problematik, dass die VICE-Palette von 2000 keine brauchbare Referenz darstellt und man besser was anders nehmen sollte.
obwohl diese Seite auch Cyan angibt.
Hier auch wieder der Einwand: So eine Umrechnungstabelle, wie auf der Seite, muss zwangsläufig in Teilen falsch sein, weil es eben keine eineindeutige Umrechnung von z.B. RGB (Bildschirm) in CMYK (Druck) gibt (anders als dort suggeriert). Schon alleine, weil der eine Wert aus 3, der andere aus 4 Basisfarben gemischt wird. Wenn z.B. Photoshop so eine Umwandlung (mithilfe des LAB-Farbraums) durchführt, wird dabei immer das eingestellte RGB- (kann z.B. sRGB sein) mit dem eingestellten CMYK- (kann z.B. Coated FOGRA39 sein) Profil verrechnet (da spielen dann aber auch noch UCR und GCR mit rein). Ohne diese Profile kann es (da geräteabhängige Farbräume) nicht wirklich gut funktionieren.
Ich sehe ja, dass ihr noch größere Probleme habt, wenn Cyan auf einmal grün ist – aber wenn diese ganz groben Definitions- und Rechenfehler mal raus sind, dann könnt ihr euch ja noch mit den Feinheiten auseinander setzen. Und da gibt es, wie ich zu zeigen versuche, noch einige Fallstricke mehr.
Ah, gefunden.
Also:
Grün paßt
Violett paßt
Schwarz paßt
Unverändert ( = Schwarz) paßt
Gelb hat die Farbe, die ich als Cyan ansehe
Rot ist jetzt dunkelblau
Magenta ist jetzt ein etwas helleres Blau (müßte laut PrintText ein helleres Violett sein)
Cyan wie diskutiert.
Ich habe mal versucht, einen Farbtest mit PrintText zu erstellen. Damit sollte das erkennbar sein. Kommt als D64 (das erste File auf Disk) mit.
Gruß
Werner
Hallo,
Also, zunächst einmal habe ich RGB Werte zugewiesen, die aus der vielleicht nicht optimalen Palette von 2000 stammt.
Der Variablentyp COLORREF erwartet aber BGR Werte. Nach Tausch des R und B Wertes ist die Überschrift "Cyan" (siehe Anhang, RGB Dateien). Es gibt in meiner Entwicklungsumgebung, wie gesagt, auch vordefinierte Farben. Wenn ich diese benutze, ergibt sich das Bild wie in predef Dateien gezeigt.
Retrofan, die Coco Diskussion habe ich nicht verfolgt, Danke für den Hinweis. Wir können gerne nächste Woche über das Thema diskutieren.
Gruß,
Lars
Hallo Lars,
Entwicklungsumgebung, wie gesagt, auch vordefinierte Farben. Wenn ich diese benutze, ergibt sich das Bild wie in predef Dateien gezeigt
ich würde die predef-Variante bevorzugen
.
Aber wir müssen wohl eine Farbe (Violett) nochmal ändern. Gestern habe ich mir die Farben unter MP3-128 mit dem Programm "PrintText 128" angesehen. Hier werden sie wie beschrieben auf dem Bildschirm dargestellt. Ich habe hier auch einen originalen Ausdruck (deutsche Anleitung zu Wheels, aus dem Jahr 2000), der mit PrintText 128 auf Stylus Color-Drucker ausgedruckt wurde (nicht von mir
, deshalb habe ich die Datei dazu auch nicht). Da gibt es eine "weitere" Farbe: blau .
Inzwischen habe ich mir das Ganze auch mit PrintText 64 angesehen. Dort wird "Violett" in blau auf dem Bildschirm dargestellt (siehe pt_Screen.BMP). Zum Vergleich habe ich mal einen Teil von 2 Seiten des besagten Ausdrucks eingescannt und als PDF gespeichert. Ist auch im Archiv vorhanden (PT_Ausdruck.pdf und PT_Ausdruck2.pdf). Hier ist im 1. die Adresse von M. Randall gemeint und im 2. der 1. Absatz nach der Überschrift.
Wenn wir diesen Farbton noch irgendwie hinkriegen und ihn statt Violett benutzen, sollte die Farb-Geschichte durch sein
.
Eins ist mir noch aufgefallen, das muss ich aber nochmal nachprüfen. Der Screenshot von PrintText (pt_Screen.BMP) zeigt, wie er im Original aussieht (bei 40- und 80-Zeichendarstellung). Der Sceenshot in der Anleitung sieht im D64Lister etwas anders aus. Ich muss mal prüfen, in welcher Form der PhotoScrap in Geowrite eingeklebt wurde. Vielleicht wurde er ja vor dem Einkleben noch bearbeitet....
Hier meine ich den Hintergrund hinter den gelben "Quadraten". Der ist im Original hellbraun (rechts neben gelb in "Retrofans" Palette weiter oben), in D64Lister erscheint er eher schwarz (in der PTAnleitung). Da er aber mit D64Lister (das .BMP) korrekt übernommen wurde, gehe ich davon aus, dass er in der Anleitung vorher verändert wurde.....
Gruß
Werner
Hast Du da eventuell noch irgendwo farbige Ausdrucke von Deinem Dokumenten, die mit PrintText gedruckt wurden? Wenn ja, kannst Du da irgendwie ein Bild von machen?
Hier ein paar Seiten.
Eingescannt mit 300dpi.
Hoffentlich passt so.
Gruss C=Mac.
Bitte melde dich an, um diesen Anhang zu sehen.Bitte melde dich an, um diesen Anhang zu sehen.