Hallo Besucher, der Thread wurde 38k mal aufgerufen und enthält 113 Antworten

letzter Beitrag von Lars am

GEOS Fonts als TrueType

  • Anbei ein GeoWrite Dokument (LQDemo2.1), in dem ich händisch den o. verlinkten BSW (Berkelium64) Font in das RTF eingestellt habe.

    Autsch, das ist ja übel. Wenn man das damals übliche Quasi-Anti-Aliasing beim Ausdruck nicht mit emuliert (was zu viel Aufwand sein dürfte), hat sich die Verwendung von Original-Fonts wohl erledigt.


    Zu Geos-LQ gab's ja spezielle Fonts, ich meine die waren drei mal so hoch aufgelöst wie die Standard-Fonts. Die müsste man aber erst mal finden, außerdem weiß ich nicht mehr wie viel Auswahl es da gab.


    Ich denke, ich mache es erstmal so, wie oben beschrieben. Dann kann sich jeder seinen Font selbst einstellen.

    Ist ein guter Start, aber sinnvoller wäre es doch, das gleich so auszulegen dass das System mit mehreren Fonts klar kommt? Also beispielsweise anzeigt, welche Fonts im aktuellen Dokument verwendet werden, und für jeden davon eine Alternative haben will.


    Es stellt sich doch die Frage, was man später auf dem PC haben möchte. Wenn man ein identisches Aussehen des Dokuments haben möchte (inkl. pixeliger Fonts), dann muss man die Fonts wohl konvertieren. Aber vielleicht möchte man ja auch eine Darstellung haben, die hochauflösender als das Original ist, also mit sauberen Vektorfonts – dann ist das Font-Ersetzen der richtige Weg.

    Das schließt sich ja nicht aus. Eine Font-Ersetzungstabelle gibt dir immer die Möglichkeit, den von dir gewünschten Font zu verwenden - egal ob das ein konvertierter Original-Font ist oder was zeitgemäßes.

  • Hallo,

    Der Font aus dem Link ist international. Ein TT Font kann ja deutlich mehr Zeichen enthalten, als ein GEOS-Font. Es sind also deutsche Umlaute, wie natürlich auch alle Klammern, | und @ enthalten. Man muss nur wissen, ob ein Text aus dem deutschen oder aus dem US-GEOS kommt, damit man das Mapping anpassen kann.

    Ja, mein Fehler. Sorry. Habe zu sehr mit der Geos64/128-Brille gedacht. :schande:

    Anbei ein GeoWrite Dokument (LQDemo2.1), in dem ich händisch den o. verlinkten BSW (Berkelium64) Font in das RTF eingestellt habe. Ich weiß nicht, ob ich das erstrebenswert finde (zum Vergleich das gleiche Dokument mit Arial).

    Autsch, das ist ja übel.

    Das würde unter Geos noch schlimmer aussehen ;-) .


    BSW und BSW 128 existieren hier nur in Punktgröße 9. Hier wurden ja die originalen Punktgrößen beibehalten. Kann man also nicht vergleichen. Im originalen Dokument (GeosLQ-Demo) werden hier 2 Fonts in unterschiedlichen Größen (10/12/30) benutzt, sie heißen: University LQ und Roma LQ.


    Zu Geos-LQ gab's ja spezielle Fonts, ich meine die waren drei mal so hoch aufgelöst wie die Standard-Fonts. Die müsste man aber erst mal finden, außerdem weiß ich nicht mehr wie viel Auswahl es da gab.

    Man schaue auf die F64-Wolke ;-) .


    Ja, die LQ-Fonts enthielten Schriftgrößen für die Anzeige auf dem Bildschirm und zusätzlich einige Schriftgrößen die wohl 3 x größer waren, die dann für den Druck wieder verkleinert wurden. So kamen mehr Punkte aufs Papier (GeosLQ war für Nadel-Drucker gedacht), was die bessere Qualität ergab. Auf Tintenstrahlern wäre da wohl ein schwarzes Blatt aus dem Drucker gekommen...



    Jetzt bleibt eigentlich nur noch: Es müssen Austausch-Fonts gefunden werden, die an die Geos-Fonts herankommen oder zumindest ähnlich aussehen.




    Lars: Mach es erstmal so, wie geplant. Wichtig ist eigentlich nur dass ich da, wo im originalen Dokument eine neue Font-ID steht, der Font gewechselt werden kann. So werden die Ergebnisse im Endeffekt wohl noch besser (näher am Original).


    Gruß
    Werner

  • Auf Tintenstrahlern wäre da wohl ein schwarzes Blatt aus dem Drucker gekommen...

    Als ich den Stylus Color 980 noch hatte, hab ich es ausprobiert.


    Von gar nichts, kein Ausdruck nur hektisches Geblinkt bis zu Klötzchengrafik war eigentlich alles lieferbar. ^^
    Kein schwarzes Blatt und auch kein brauchbarer Ausdruck.
    Die LQ-Font's waren mit dem Tintendrucker nicht mehr zu gebrauchen.
    Am besten war es mit PrintText und seinen Font's (war ja auch für Tintendrucker gedacht).


    Gruss C=Mac.

  • Hallo,


    also für den RomaLQ (ID: 64) könnte man "Times New Roman" als Ersatz nehmen. Sieht beinahe identisch aus.


    für University LQ (ID: 56) habe ich noch nichts richtiges gefunden. Da ist Arial in den größeren Punktgrößen zu "dick". Arial würde besser zu California LQ (ID: 57) passen.



    Habe die 3 Fonts mal durch den D64Lister gejagt ;-) .


    Gruß
    Werner


    PS: zu mehr werde ich wohl in nächster Zeit nicht kommen. Also Freiwillige vor!

  • Von gar nichts, kein Ausdruck nur hektisches Geblinkt bis zu Klötzchengrafik war eigentlich alles lieferbar.
    Kein schwarzes Blatt und auch kein brauchbarer Ausdruck.

    Das hat weniger mit den LQ-Fonts zu tun als mit


    a) GeosLQ das den Druck gesteuert hat
    b) den Druckertreibern (HQ) die mit Geos LQ geliefert wurden


    Die waren mehr auf 9- und 24-Nadeldrucker ausgelegt. Der "Tintenpisser" hat den Treiber nicht verstanden .....



    Die Fonts selber müßten über Grafikdruck mit passenden Treiber für den Stylus Color 980 eigentlich problemlos gedruckt werden....


    Gruß
    Werner

  • Lars: Mach es erstmal so, wie geplant. Wichtig ist eigentlich nur dass ich da, wo im originalen Dokument eine neue Font-ID steht, der Font gewechselt werden kann

    Deshalb hatte ich ja vorgeschlagen, die ID bei Schriftwechsel im Dokument mit anzugeben. Man kann es ja auch wieder ausblenden, aber hat zumindest die Info.


    Ich habe damals das LQ Paket gekauft und super Ergebnisse auf dem Star LC-10 erzeugt. Aber um es einmal ganz klar zu stellen, ich werde keine eigene Render Engine programmieren, die die LQ Fonts wieder runterskaliert, oder ähnliches. Vielleicht wäre noch eine Lookup Table (als externe Datei oder in der d64lister.ini) praktikabel, in der die Geos Font ID zu Standard Windows Font Namen gemappt werden:


    64 Times New Roman
    57 Arial


    Soetwas kann ich schnell implementieren, wenn gewünscht (und ich von der Familie Zeit bekomme).


    Gruß,
    Lars

  • Hallo,

    Deshalb hatte ich ja vorgeschlagen, die ID bei Schriftwechsel im Dokument mit anzugeben. Man kann es ja auch wieder ausblenden, aber hat zumindest die Info.

    Ok, wenn das dann im Kontext-Menü des Viewers (wie bei den Farb- oder Seitenzahlen-Einstellungen) zu finden ist, kann ich damit Leben. Sollte aber so kurz wie möglich sein und irgendwie auffallen.



    Aber um es einmal ganz klar zu stellen, ich werde keine eigene Render Engine programmieren, die die LQ Fonts wieder runterskaliert, oder ähnliches

    Das verlangt auch keiner ... ;-) . Wäre auch ziemlicher Blödsinn ;-) .


    Zumal die Größen für das Drucksystem in der Regl in einem anderen Format gespeichert sind (siehe Geos LQ-Handbuch, das hier schon seit etlichen Wochen zum Scannen für die F64-Wolke bereit liegt, ich komme einfach nicht dazu ....) :-) .



    Ich werde mal sehen, in den nächsten Tagen eine ID-Liste der Fonts von den Geos64/128-Grundsystem und einigen Fonts aus dem GeosLQ-System (auch hier habe ich "nur" das Grundpaket aus 4 1541-Diskettenseiten) zu erstellen. Die könnte dann schonmal zur Information mit in die Anleitung zum D64-Lister aufgenommen werden. Ersatz-Fonts (TTF; möglichst frei verfügbare) kann ich nicht raussuchen. Keine Zeit..., keine Zeit.... Da müssen auch mal andere mithelfen.


    Gruß
    Werner

  • Hallo Werner,


    Ok, wenn das dann im Kontext-Menü des Viewers (wie bei den Farb- oder Seitenzahlen-Einstellungen) zu finden ist, kann ich damit Leben. Sollte aber so kurz wie möglich sein und irgendwie auffallen.


    Naja, wie ich es oben beschrieben habe: SPACE{0815}SPACE und dann im Kontextmenü abschaltbar. Genauso war es gedacht.


    Und was hältst Du von der Lookup Table (auch im Kontext Menü abschaltbar)? Die wäre ziemlich universal einsetzbar, da man sich die Fonts selbst mappen könnte. Ich würde die Tabelle in der d64lister.ini ablegen, vielleicht mit einem Default Wert (z.B. Arial), der zum Tragen kommt, wenn die jeweilige ID noch nicht gemappt ist. Dann würde ich mir den Font Dialog im GeoWrite Viewer sparen, da man ja global den Font ändern könnte, wenn keine mappings eingestellt sind und Default auf "wasweissich" eingestellt ist. Das nachträgliche Verändern könnte man ja trotzdem mit jedem anderen RTF Betrachter machen.


    Ist nur so eine Idee...


    Gruß,
    Lars

  • Aber um es einmal ganz klar zu stellen, ich werde keine eigene Render Engine programmieren, die die LQ Fonts wieder runterskaliert, oder ähnliches.

    LOL, das meinte ich natürlich nicht - wäre ja schon deswegen Quatsch, weil ein plattformunbhängiges RTF dabei rauskommen sollte. Ich meinte bei der Konvertierung müsste man diesen Effekt emulieren, halte aber auch das für Unsinn.



    Und was hältst Du von der Lookup Table (auch im Kontext Menü abschaltbar)? Die wäre ziemlich universal einsetzbar, da man sich die Fonts selbst mappen könnte. Ich würde die Tabelle in der d64lister.ini ablegen, vielleicht mit einem Default Wert (z.B. Arial), der zum Tragen kommt, wenn die jeweilige ID noch nicht gemappt ist. Dann würde ich mir den Font Dialog im GeoWrite Viewer sparen, da man ja global den Font ändern könnte, wenn keine mappings eingestellt sind und Default auf "wasweissich" eingestellt ist.

    Gefällt mir.

  • Hallo,


    hier nun wie versprochen eine Liste der Font-IDs einiger Geos-Schriften:


    Geos 64/128 V2.x:


    BSW 00
    BSW 128 32 (nur Geos 128)


    California_GE 57
    Cory_GE 66
    Dwinelle_GE 65
    Roma_GE 64
    University_GE 56
    Commodore_GE 129


    LW_Roma_GE 88
    LW_Cal_GE 89
    LW_Greek 29
    LW_Barrows_GE 91


    Geos LQ V2.x (Standardpaket):


    Roma LQ 64
    University LQ 56
    California LQ 57
    Barrows LQ 91
    Schatten 1* LQ 900
    Zierschrift LQ 676
    ZierKapitale LQ 890
    Tusche LQ 706
    Wood LQ 715


    Die doppelten Belegungen zwischen Geos und Geos LQ sind beabsichtigt. Man brauchte die Dokumente vor einem Ausdruck mit GeosLQ nicht ändern (siehe Anleitung zu Geos LQ).



    Für Ersatz-Fonts für D64Lister/PC haben wir bisher:


    BSW ID:00 Berkelium64.ttf
    Roma ID:64 TimesNewRoman.ttf
    California ID:57 Arial.ttf


    Gruß
    Werner

  • Für Ersatz-Fonts für D64Lister/PC haben wir bisher:


    BSW ID:00 Berkelium64.ttf
    Roma ID:64 TimesNewRoman.ttf
    California ID:57 Arial.ttf

    Bei einer TrueType Pixel-Simulations-Schrift muss man allerdings beachten, dass die nur einer der Original-Größen entspricht, bei der Berkelium wird das der 9pt-Font sein. Verwendet man sie in anderen Größen, werden die Pixel skaliert, statt sie aus einer anderen Pixelanzahl aufzubauen. Um eine korrekte Simulation zu erzeugen, müsste man eigentlich alle Größen einzeln als Font umsetzen.


    Natürlich können auch Truetypes und PS-Fonts echte Bitmaps in unterschiedlichen Größen (Pixelanzahlen) enthalten, nur werden die heutzutage meistens nicht mehr zum Rendern im Betriebssystem verwendet, z.B. weil man damit keine (ClearType) Kantenglättung erzielen kann (da nur 1-Bit).


    Zu anderen Ersetzungen:


    Für die Commodore (GE 129) kann man natürlich die PetMe64 aus dem Paket verwenden, das man auf der Seite herunterladen kann, von der auch die Berkelium stammt. Wenn es allerdings nur um das Monospaced-Feature geht, wäre Courier die passende Ersetzung.


    Bei der GEOS University (GE 56) tippe ich darauf, dass es eine Anlehnung an die bekannte Univers von Adrian Frutiger sein könnte. Das Problem bei der Identifizierung ist halt, dass sich die Buchstabenformen je nach Größe (also Pixelanzahl) stark verändern. Meine Vermutung basiert daher eher auf der Namensgebung.


    Für die beiden Zierschriften Dwinelle (GE 65) und Cory (GE 66) habe ich Open Source Fonts herausgesucht, die zwar nicht genau aber doch einigermaßen passen.



    Beide bei dafont herunterzuladen.

  • Mein Dank geht an Retrofan :thnks: .


    Für die Commodore (GE 129) kann man natürlich die PetMe64 aus dem Paket verwenden, das man auf der Seite herunterladen kann, von der auch die Berkelium

    Ich würde mal sagen, das paßt. ;-)



    Cory (GE 66) habe ich Open Source Fonts herausgesucht,

    JLS Space Gothic für Cory wäre eine "Notlösung". Das Design paßt ungefähr, aber die Umlaute nicht (am PC mit LibreOffice probiert). Die scheinen da nicht enthalten zu sein bzw. sehen völlig anders aus.


    Mehr konnte ich nicht vergleichen! Keine Zeit....


    Ich habe ja schon öfter hier geschrieben, um das umzusetzen, brauchen wir Unterstützung. Das war heute das letzte Mal, dass ich mir Fonts genauer angesehen und verglichen habe. Ich habe einfach nicht die Zeit dazu.......


    Gruß
    Werner

  • Ich war mal so frei und habe alle meine Fontnamen mit ID in eine CSV Datei exportiert.

    sind aber einige doppelt und mehrfach drin ;-)


    Und eine ID fehlt (BSW 128) ;-) . OK den gibt es irgendwie nicht als externen Font. Wobei das auch nicht ganz stimmt. Es gab da mal "ChangeBSW", das ich für deutsches Geos angepaßt habe. Da habe ich aber wahrscheinlich den falschen Font für Geos 128 mit Umlauten versehen. Habe damals (so irgendwann Mitte der 1990er übersehen, dass die Anleitung dazu nicht ganz stimmt..... Die ID paßt auch nicht. sind 1000er Nummern.
    Das Ganze ist in der GUC-Geothek Rubrik 1 und 6 zu finden.


    Gruß
    Werner

  • Es sind ja auch nur die Fonts gelistet, die ich (aus meinem Diskettenbestand) habe...

    schon klar. Deshalb aucxh das Smilie. ;-)


    Die ID kann ja nur maximal 1024 sein, da nur 10 Bit zur verfügung stehen, oder (hast Du oben schon mal geschrieben)?

    Korrekt. Zumindest ist das meine Information (aus dem MegaAssembler-Handbuch). Mit über 1000 meinte ich dezimale Werte.


    Habe diese 9 Fonts als csv mit D64Lister gespeichtert. Kommt anbei.



    ChangeBSW diente dazu den/die BSW-Fonts im Kernel durch andere Fonts zu ersetzen. Dabei musste natürlich beachtet werden, dass die Länge des Fonts exakt eingehalten wurde, damit nichts anderes im Kernel überschrieben wurde. Man findet das Ganze auf GUC-Geothek Disk 1.18b (in der F64-Wolke).


    Gruß
    Werner

  • Hallo,


    Ich habe zunächst die Einblendung der FontID implementiert. Sie wird nur eingeblendet, wenn sie sich verändert hat. Leider fand ich wiedermal keinerlei Infos darüber, also wieder einmal selber versucht, es herauszufinden. Ob mein Vorgehen richtig ist, weiß ich nicht.


    Also, ein Style Change wird ja mit 0x17 eingeläutet. Darauf folgen 3 Byte:


    0: beinhaltet in den Bits 0-5 die Schriftgröße (also max. 63), habe ich vorher schon mit 0x3F verundet verwendet. Bits 6 und 7 sind die untersten 2 Bits der ID, mit Rechtsshift von 5 nach ganz vorne geholt.
    1: beinhaltet den Rest der ID, mit Linksshift von 2 Platz für die Beiden Bits von eben geschaffen und zusammenaddiert.
    2: beinhaltet dann den Style.


    Ist die ID Generierung so richtig? Auch bei der Schriftgröße habe ich geraten, habe aber Megafonts, die auch Größe 48 haben.


    Wenn ja, und es sieht bei den beiden angehängten Beispielen auch richtig aus, wundern mich die zwischengestreuten IDs in den Beispielen. Z.B. sollte bei dem LQ Demo nur ID 56 und 64 verwendet werden (zumindest befinden die sich auf der Diskette), es gibt aber einen Absatz mit ID 57 und unten bei der Fußzeile auch. Genauso verhält es sich bei dem anderen Beispiel mit 693. Befindet sich bei mir nicht auf der Diskette. Was macht GeoWrite hier? Sind dies Reste aus der Erstellung der Dokumente? Kann das jemand im Originaldokument nachvollziehen?


    Danke und Gruß,
    Lars

  • Leider fand ich wiedermal keinerlei Infos darüber, also wieder einmal selber versucht, es herauszufinden. Ob mein Vorgehen richtig ist, weiß ich nicht.

    Frag doch ;-)


    Nein, ich habe mal meine Infos darüber aus dem MegaAssembler-Handbuch (PDF) extrahiert. Da steht alles drin, was ich darüber weiß. Sollte stimmen. 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...
    Die Erweiterung stammt von PrintText. Damit konnte PrintText auch farbig (Schriftfarbe) drucken.


    Achtung: das ist geteiltes 7z-Archiv (2 Teile), wegen der Größe. Bitte vor dem Entpacken das .7z nach 001 bzw. 002 löschen.


    Auch bei der Schriftgröße habe ich geraten

    Kann man auch nur ;-) .
    Hier gibt es keine konkreten Angaben, was Geowrite da zuläßt. Ich habe bisher auch nichts konkretes gefunden.....
    Wenn die Punktgröße in kB zu groß wird, stürzt es wohl ab....


    Wichtig ist, das originale GeoWrite, GeoPaint und GeoPublish stürzt bei mehr als 7 Punktgrößen ab. Dafür gab es mehrere Patches, so dass jetzt 8 Punktgrößen in einem Font angewählt werden können.



    wundern mich die zwischengestreuten IDs in den Beispielen.

    Ja, das sieht etwas anders aus als bei meinem originalen Dokument "LQ-Demo". Ich hänge das D64 hier mal an (glq11.7z).
    In Geowrite bleibt es in der Leerzeile zwischen Überschrift und 1. Zeile bei "Font ID : 64", aber der Schriftstiel ändert sich auf "Kontur". Das sollte D64Lister auch anzeigen.
    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?


    Zum Etikett-Demo:


    Die Fonts hast Du laut Deinem hier veröffentlichten CSV aber:


    Font ID : 663 Future III LQ
    Font ID : 665 Krone LQ
    Font ID : 693 Gyrios LQ


    So wie ich das sehe, stammen sie von einer der Zeichensatz-Disketten, die zusätzlich und unabhängig vom eigentlichen GeosLQ von Dritten (hier: Denis Döhler) angeboten wurden. Ich tippe mal auf "LQ-Font-Collection TWO". Da stammt auch das verwendete Etikett her ;-) .


    Gruß
    Werner