Hallo Werner,
Schickst Du mir auch die D64 Images?
Danke und Gruß,
Lars
Du bist in Begriff, Forum64 zu verlassen, um auf die folgende Adresse weitergeleitet zu werden:
Bitte beachte, dass wir für den Inhalt der Zielseite nicht verantwortlich sind und unsere Datenschutzbestimmungen dort keine Anwendung finden.
letzter Beitrag von Lars am
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:
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:
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:
http://www.pentacom.jp/pentacom/bitfontmaker2/
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:
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: GEOS Fonts als TrueType ). 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.
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 Community Colors 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 überarbeitet 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.
Coco 1.2
[Edit:] Ergänzt um Peptos Palette (50/100/70)
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 Farbmess-System 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 diese 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 hier. 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.