letzter Beitrag von Lars am
Bei der Leerzeile nach der Überschrift wird wohl der Zeilenabstand zwischen Überschrift und 1. Zeile justiert. Durch "Kontur" wird der Anstand etwas größer. Bei meinem GeosLQ gibt es den "Font" Absatz nicht mehr, obwohl er in der Anleitung noch beschrieben ist....
Der Font Absatz enthielt keine Zeichen, war wohl nur für die Einstellung eines größeren Zeilenabstandes zu benutzen.
Gruß
Werner
Hallo Lars,
habe jetzt mein LQ-Demo durch D64Lister Version 1.7.2 gejagt. Da läuft soweit alles richtig. im RTF befindet sich dann nur nach der Leerzeile hinter dem kleinen Bild in der Fußzeile eine weitere Leerzeile in "Liberation Serif". Die könnte aber von LibreOffice (hier: V5.3.0.3) kommen. Sieht so aus, dass Dein Demo verändert wurde ....
Gruß
Werner
Hallo Werner,
Nein, ich habe mal meine Infos darüber aus dem MegaAssembler-Handbuch (PDF) extrahiert.
Vielen Dank dafür. In dem Handbuch steht, dass die ID in den Bits 6-15 steht. Man müsste also die beiden Bytes ganz normal zu einem Word zusammenfassen und 5 Bits nach rechts schieben. Es kommt das gleiche dabei raus, wie mit meinem Algorithmus. Danke für die Bestätigung. Bist Du denn mit der Darstellung einverstanden? Ich habe versucht, sie so dezent wie möglich zu machen.
In der Fußzeile kommt bei mir direkt nach dem Text das Bild und dann nach dem Bild eine Leerzeile mit Font ID: 57. Kann es sein, dass Deine Datei verändert ist oder D64Lister einen Fehler macht?
Da fehlte vielleicht die Einstellung "Neue Zeile vor oder nach einem Photoscrap". Dann wäre die Leerzeile mit ID57 unter dem Bild... Was mich wunderte war die ID57, wo doch das Dokument mit ID56 und ID64 erstellt wurde. Also ist in Deiner LQ Demo auch ID57 unter der Überschrift und in der Fußzeile vor oder nach dem Bild vorhanden?
Zum Etikettendemo:
Mich wunderte, dass in der Description (also in den GEOSDetails) des Files stand, dass ID663 und ID665 verwendet wird, und ich ID693 ausgegeben habe... ist auch nicht auf der Diskette drauf (meine ich zumindest). Und ja, ich habe mir damals alle LQ Sachen gekauft, weil ich so begeistert von dem Ergebnis war. Deshalb habe ich ID693 vielleicht auch, ich meine aber nicht in dem Image. Was macht denn GeoWrite, wenn sich der eingestellte Font nicht auf der Disk befindet? Nimmt er BSW?
Zusätzlich habe ich ein zweites PDF dabei, das eine "Erweiterung" des Style Change 0x17 (ESC_RULER) enthält. Wäre schön, wenn wir die auch noch ergänzen könnten...
Meinst Du die Farbe? Ja, das ist möglich. Baue ich mit ein (habe ich vor einiger Zeit eh drüber nachgedacht). Mache ich aber auch als Option im Kontextmenü.
OK, dann scheint zunächst einmal die ID Dekodierung zu klappen. Als nächstes kommt dann die Lookup Table dran (und die Farbe).
Vielen Dank und Gruß,
Lars
Also ist in Deiner LQ Demo auch ID57 unter der Überschrift
Ich habe es nur direkt in GeoWrite angesehen. Nein, da steht bei mir (in den Menüs) weiterhin Roma 12 . Nur der Stil ändert sich in "Kontur".
Kann natürlich sein, das Geowrite den Fontwechsel nicht bemerkt, da ja kein Zeichen in der Zeile steht. Da müsstest Du mal meine LQ-Demo im neuen "D64Lister" anschauen.... 
.
Mich wunderte, dass in der Description (also in den GEOSDetails) des Files stand, dass ID663 und ID665 verwendet wird
Nun, da ist nicht unendlich Platz. Außerdem zeigt der originale Desktop von Geos nicht unbedingt den kompletten Info-Text an.
Was macht denn GeoWrite, wenn sich der eingestellte Font nicht auf der Disk befindet? Nimmt er BSW?
normal ja. (bei Geos128 BSW 128, da Geowrite 128 immer auf 80 Zeichen läuft)
ID57 ... in der Fußzeile vor oder nach dem Bild vorhanden?
in GeoWrite nach dem Bild.
Da fehlte vielleicht die Einstellung "Neue Zeile vor oder nach einem Photoscrap". Dann wäre die Leerzeile mit ID57 unter dem Bild...
Die steht bei mir auf "after", weil ich damit die besten Ergebnisse habe. Wenn z.B. in Geowrite 2 Bilder direkt untereinander zu sehen sind (ein Screenshot bestehend aus 2 Bildern) bringt "none" die beiden Bilder nebeneinander ins RTF. Die anderen Optionen bringen zusätzliche Leerzeilen.
Irgendwie weiß ich nicht, wie das intern in Geowrite gespeichert wird (2 Bilder direkt nacheinander). Ist da nach einem Bild kein Zeilenvorschub im Text?
Bei Deiner LQ-Demo befindet sich aber ID 57 vor dem Bild. Das verwundert mich ein wenig.
Kann es sein, dass die Einstellung "Neue Zeile vor oder nach einem Photoscrap" da die vorhandenen Zeilen rausnimmt und entsprechend der Einstellung neu reinsetzt? Finde ich irgendwie suboptimal....
Gruß
Werner
Kann es sein, dass die Einstellung "Neue Zeile vor oder nach einem Photoscrap" da die vorhandenen Zeilen rausnimmt und entsprechend der Einstellung neu reinsetzt? Finde ich irgendwie suboptimal....
Es wird nichts enrfernt, nur hinzugefügt... Ich habe es nicht anders hinbekommen und mit dieser Einstellung immerhin eine Option vorgesehen, mit der man das Einfügen beeinflussen kann.
Da möchte ich auch nichts mehr dran ändern, ich denke, besser geht es für eine Konvertierung nicht.
Gruß,
Lars
Hallo Werner,
Meinst Du die Farbe? Ja, das ist möglich. Baue ich mit ein (habe ich vor einiger Zeit eh drüber nachgedacht). Mache ich aber auch als Option im Kontextmenü.
Hast Du Beispiel Dateien, mit denen ich dies testen kann, also PrintText Files?
Danke und Gruß,
Lars
Hallo Lars,
Hast Du Beispiel Dateien, mit denen ich dies testen kann, also PrintText Files?
Ich selbst habe nie mit PrintText gearbeitet. Ich habe aber mal 3 Geowrite-Doks, die zu PrintText gehören aus dem Komplett-Paket herausgeholt. Kommt als D64 anbei. Zumindest die Anleitung sollte bunt sein
Gruß
Werner
Hallo,
So, die neue D64Lister Version mit den gewünschten Features ist reif für einen Beta Test.
Ich habe 3 Erweiterungen im GeoWrite Viewer implementiert:
1. Show FontID
2. Use FontTable
3. Show PrintText Colors
Zu 1.:
Die verwendete FontID wird in {} vor Änderungen im Font angezeigt, wenn sich die FontID verändert hat. Sie wird mit den jeweiligen Styles angezeigt.
Zu 2.:
Die FontTable ist in der D64Lister.ini abzulegen nach dieser Vorgabe:
Die D64Lister.ini ist bei Systemen älter als WindowsXP im Windows Ordner, in neueren Systemen im AppData\Roaming\D64Lister Ordner zu finden (z.B. C:\Users\lars\AppData\Roaming\D64Lister). Leider ist der AppData Ordner versteckt, muss also in den Ordner Optionen sichtbar geschaltet werden.
Außerdem kann die *.ini lokal im D64Lister Ordner liegen, diese wird dann bevorzugt.
Das Format ist, wie oben zu sehen FontID=Windows Font Name. Den Windows Font Namen bekommt man, indem man den gewünschten Font mit dem Windows Schriftartenanzeiger öffnet (also Doppelklicken) und den Namen hinter "Schriftname" verwendet. Es ist nicht der Dateiname!
Die Reihenfolge der FontIDs ist egal, da ich die Tabelle im D64Lister aufsteigend sortiere. Allerdings benutze ich im späteren Verlauf einen Binary Search Algorithmus zum Auffinden der ID, d.h., bei doppelten Einträgen ist es eher zufällig, welcher von beiden verwendet wird. Also doppelte Einträge vermeiden (macht ja eh keinen Sinn).
Der erste Eintrag wird als Default Font verwendet, wenn die jeweilige FontID nicht gefunden wird. Hier bietet es sich an, eine kleinere Zahl als die kleinste FontID (0) zu wählen, also z.B. -1. Wenn auf Font Ersetzungen verzichtet werden soll, aber ein anderer Default Font verwendet werden soll, reicht also ein Eintrag in der FontTable:
Wenn die Tabelle nicht vorhanden ist, oder keine Einträge gefunden werden (es muß das obige Format verwendet werden), wird als Default Arial verwendet.
Zu 3.:
Zunächst ein paar Internas:
Ich habe im Jahre 2000 auf Windows98 mit der Entwicklung des D64Listers begonnen und realtiv schnell die Geos Funktionen erstellt. Als bestes (und einziges) Anzeige Element hat sich für den GeoWrite Viewer ein RichEdit Fenster herausgestellt. Die damals aktuelle RichEdit DLL Version 2.0 bot damals nur folgende Optionen, um den Font zu ändern (über die Windows Message EM_SETCHARFORMAT):
- SCF_ALL
- SCF_SELECTION
- SCF_WORD
Es kann also alles, ein selektierter Bereich oder ein Wort geändert werden. Ich entschied mich damals, während des Einlesens des GeoWrite Dokuments den Text zunächst ohne irgendwelche Styles oder Photoscraps ins RichEdit Fenster einzulesen, mir aber die Styles und Photoscraps mit ihrer Position im Text zu merken und nachträglich über die SCF_SELECTION Message die Styles dem Text zuzuweisen. Die Photoscrpas werden genauso an der ursprünglichen Stelle im Text eingefügt (dies ergibt auch das von Werner bemängelte Verhalten mit "Newline before / after Photoscrap"). Diese Methode stellte sich als die schnellste und komfortabelste heraus und wird auch im Mainform für das Blaumachen der Disknamen und im TOK64 Detokenizer für das Syntax Highlighting verwendet.
Da nun die Farbe von PrintText nicht als Style geändert wird, sondern als Ruler Escape, passt dies nicht in dieses Konzept, da Ruler Änderungen direkt behandelt werden (über die Message EM_SETPARAFORMAT). Also habe ich die Ruler Escape Funktion so erweitert, dass auch die Farbe mit der jeweiligen Position im Text gemerkt und nachtäglich geändert wird. Dies findet nach dem Style Changes statt. Nun ergab sich die Besonderheit, dass ich Reverse Teile fest mit schwarzem Hintergrund und weißer Schrift definiert habe. Durch die nachträgliche Farbänderung ergibt sich dann schwarzer Hintergrund mit z.B. grüner Schrift. Also gehe ich als letzten Schritt noch einmal durch die Styles und ändere bei reversem Style den Hintergrund auf die PrintText Farbe und die Schriftfarbe auf weiß.
Als Farben habe ich die zuvor im GeoPaint Viewer und PhotoScrap Viewer verwendeten RGB Werte genutzt, die auf der VICE Palette von 2000 basieren.
Zum Ergebnis (siehe Anhänge):
Die Fontersetzung klappt und bringt mit Berkelium 64 und Pet me 64 100% Retrofeeling hervor (das man sich das früher angetan hat...). Es fehlen natürlich weitere Ersatzfonts, aber ich denke, die Liste wird wachsen. Hier wäre schön, wenn es eine zentrale Anlaufstelle gibt, wo Änderungenen der FontTable mitgeteilt werden können (vielleicht dieser Thread, FXXS?).
Die o.a. PrintText Texte habe ich um einen Reversen Bereich erweitert und das Ergebnis angehängt. Die Farbigen Bereiche sehen zunächt richtig aus, ob es so richtig ist, weiß ich nicht (habe meinen Epson Stylus 400 schon lange verschrottet).
Ich lasse Werner (und Korodny?) eine Beta Version D64Lister zum Ausprobieren zukommen.
Gruß,
Lars
Die Fontersetzung klappt und bringt mit Berkelium 64 und Pet me 64 100% Retrofeeling hervor. Es fehlen natürlich weitere Ersatzfonts, aber ich denke, die Liste wird wachsen.
Was man bei der Schrift-Ersetzung bedenken sollte: Wenn man, wie bei der Berkelium, Pixelfonts mit Vektoren nachbaut, dann simuliert man immer nur eine ganz bestimmte Pixel-Font-Größe. Wenn Fonts im Original in verschiedenen Größen vorliegen (wie bei GEOS der Fall), müsste man zur vollständigen Simulation für jede Pixel-Font-Größe einen eigenen TrueType-Font zeichnen. Erst dann wäre das Ergebnis einigermaßen genau (wenn man das denn möchte).
Das führt aber dazu, dass man bei einer Ersetzung nicht nur die Schriftart berücksichtigen darf, sondern man auch (optional, wenn vorhanden) die Größen beachten müsste. "00=Berkelium 64" recht also nicht unbedingt – man müsste optional auch für unterschiedliche Größen unterschiedlich Zielfonts angeben können, also z.B. "00/8pt=Berkelium 1541" und "00/10pt=Berkelium 64". Nun, wenn man es wirklich korrekt machen möchte.
Bei Ersetzungen mit echten (nicht Pixel-simulierenden) Vektorfonts, wie Arial, ist die Größen-Unterscheidung natürlich nicht nötig.
Hallo Retrofan,
Alles richtig, wenn der BSW Font nicht immer Größe 9 hätte (hat Werner oben auch schon geschrieben). Ich sähe so eine Option auch eher in dem Font. Wie Du schon sagst, bei Vektor basierenden Fonts sowieso egal, bei Bitmap Fonts eine Frage des Erstellens.
Gruß,
Lars
wenn der BSW Font nicht immer Größe 9 hätte
Ist das so? Im Desktop gibt es ihn doch schon in 2 Größen und ich dachte daher, dass es irgendwo noch weitere gäbe. Wenn das nicht der Fall ist, dann muss man das wohl nicht berücksichtigen – außer man verwendet auch für andere GEOS-Fonts (die in unterschiedlichen Größen vorliegen) Ersatz-Btmap-Fonts (statt größenunabhängige Fonts). Dann bräuchte man eine komplexere Ersetzungstabelle, um alle Größen getrennt ersetzen zu können. Aber wenn das nicht vorkommt, dann muss man es auch nicht beachten.
Hier wäre schön, wenn es eine zentrale Anlaufstelle gibt, wo Änderungenen der FontTable mitgeteilt werden können (vielleicht dieser Thread, FXXS?).
Ich hab da keine Einwände, Thread ist jetzt angepinnt... Kann aber Retrofan auch bei Bedarf noch ändern.
sl FXXS
BSW und BSW 128 existieren hier nur in Punktgröße 9
Ich meine, ich kann mich daran erinnern, in GeoWrite auch nur Größe 9 angeboten bekommen zu haben. Weiterhin sind alle 40 Dokumente, die ich mir gestern mit FontID 0 (BSW) angesehen habe, mit Schriftgröße 9.
Ich denke, dass ist kein Problem.
FXXS, Danke für das anpinnen.
Gruß,
Lars
Hallo,
Ist das so? Im Desktop gibt es ihn doch schon in 2 Größen und ich dachte daher, dass es irgendwo noch weitere gäbe.
Es ist so . Nachzulesen u.a. im Geos Handbuch Anhang C (da sind die Fonts abgedruckt mit verfügbarer Punktgröße).
Was Du meinst, sind wohl die Dateinamen, Diskettennamen, Druckertreibernamen, .... die kleiner sind. Das ist aber kein Text sondern Grafik. Frag mich jetzt nicht, wie Desktop das macht, keine Ahnung.
Aber man kann im Menü "Anzeige" auf Textmodus umstellen. Das geht mit Auswahl eines der 4 Menüpunkte, die mit "nach ..." beginnen. Dann wird auch BSW (Fett) zur Anzeige im Laufwerksfenster benutzt.
BSW als Text wird im Grafik-Mode (Pictogramme) in Menüs und in der Titelzeile des Laufwerks-Fensters benutzt. Und das ist BSW 9 Punkte.
Gruß
Werner
Was Du meinst, sind wohl die Dateinamen, Diskettennamen, Druckertreibernamen, .... die kleiner sind
Ja, die meinte ich. Und der Font wurde ja auch als Berkelium 1541 umgesetzt. Wenn das aber kein BSW oder überhaupt ein Font ist, dann will ich nichts gesagt haben. Wie gesagt, ich sah die Problematik nur für den Fall, dass man auf PC-Seite optimierte Bitmap-Fonts für unterschiedliche Größen einsetzen möchte. Dann müsste man halt bei der Ersetzungs-Tabelle die Schriftgröße (und nicht nur die Font-ID) berücksichtigen. Scheint aber wohl nicht der Fall zu sein – außer ein Verrückter pixelt z.B. die University in allen verfügbaren Größen als TrueType nach.
Zum Ergebnis (siehe Anhänge):
Das sieht doch schonmal vielversprechend aus.
Ich frage mich nur, was der Unterschied zwischen den jeweils 2 Versionen in PrintText.zip ist. Unter LibreOffice 5.3.1 in Windows kann ich keinen erkennen ...
Und eins noch:
WordPad aus Win 10 32Bit kann man wohl vergessen. Zumindest sehen die Dateien damit etwas seltsam aus .... .
Danke.
Gruß
Werner
Hallo Werner,
In dem Dokument "PT2.2_News" habe ich zwei Bereiche Reverse gemacht (durch setzen des Reverse Styles mittels eines HexEditors). Siehe Erklärungen oben. Die anderen Files sind unnötig, stimmt.
Bei WordPad muss man die Ränder auf 0 stellen. Ist hier auf der Arbeit bei Windows7 auch so, bei XP war das, meine ich, nicht nötig.
Gruß,
Lars
In dem Dokument "PT2.2_News" habe ich zwei Bereiche Reverse gemacht
Ah, ja. Diese Kleinigkeit habe ich übersehen.....
Da ist "PrintText V2.2" oben im Kasten (blau) und danach die 1. Überschrift (grün) jeweils reverse. Sollte also auch passen.
Gruß
Werner
Hallo,
Ich habe gestern ein wenig (und absolut laienhaft) mit mehreren Raster Font Tools gespielt, um die GEOSFonts direkt aus den vom D64Lister exportierten Bitmaps in PC Fonts zu konvertieren. 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.
Retrofan,
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? Nach dem Karten Eintrag in Deinem Profil wohnen wir im selben Ort
Gruß,
Lars
Hallo Lars,
habe jetzt mal erste Tests durchgeführt. Zunächst ist oben (Post #48) ein Fehler in der Fontliste. Die letzten beiden Zeilen müssen:
65=Olde English
66=JLS Space GothicC NC
lauten.
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 .
Bei den "PrintText Colors" muß ich nochmal schauen. Irgendwie sieht die Farbe in der 1. Zeile in Deinem Beispiel (PT_Anleitung) etwas seltsam aus.....
Ich habe gestern ein wenig (und absolut laienhaft) mit mehreren Raster Font Tools gespielt, um die GEOSFonts direkt aus den vom D64Lister exportierten Bitmaps in PC Fonts zu konvertieren.
Kannst Du hier mal versuchen, den "Commodore_GE" (enthält nur 10 Punkt Größe) umzuwandeln, auf den müßte die "feste Breite" zutreffen. Wie es aussieht, ist "Pet Me" da nicht wirklich ein Ersatz. Ist irgendwie viel zu breit oder schmal.... (habe alle Pet MEs durchprobiert).
Gruß
Werner
