Infos zum GEOS TTF-Treiber

    Habe mal ein wenig mit dem neuesten Build Nr. 999 gearbeitet und ich muß sagen, so, wie es jetzt ist, ist es - für mich - richtig gut.

    Und das Beste: Auch die Hilfe wird - im Vergleich zu vorher - richtig gut leserlich dargestellt. :]

    Fehlt nur noch das Ansichtswerkzeug im Hilfefenster. ;)

    Gruß Achim


    PC/GEOS unter Linux in der DOSEMU = UNSCHLAGBAR!

    Ich habe heute ein bißchen mit GEOS 6 und PS-Druck getestet. Für 3 der Schriften fehlt noch das ID-Mapping in der GEOS.INI:

    ---%<--------
    [FontMapping]
    ;FID_PS_BOOKMAN - Bookman-Light
    URWBoolman = 20504
    ;FID_PS_AVANTE_GARDE - AvanteGarde-Book
    URWGothic = 21004
    ;FID_PS_PALATINO - Palatino-Roman
    URWPalladio = 20490
    ---------------

    @Nico die Macher von Cooper*Black haben auch noch weitere tolle Fonts. Vielleicht magst Du die auch konvertieren:

    ;FID_PS_CLARENDON - Clarendon
    Besley* = 20513
    ;FID_PS_BODONI - Bodoni-Book 16 points
    Bodoni* = 20482

    Jost* als Futura-Ersatz ist wohl nicht free. Unter den Cowboy Fonts gibt es mit Copperplate CC auch einen schönen Copperplateverschnitt unter SIL lizensiert.

    Fonts Besley* und Bodoni 16pt in Github hinzugefügt , aber noch nicht in FreeGeos hinzugefügt.

    Mapping habe ich als getrennten PR erstellt.

    Z003 FontID (ZapfChancery Z003) ???

    Gruss von Nico

    Edited once, last by nschu (April 8, 2025 at 7:56 PM).

    Hallo,

    ist es wirklich sinnvoll mehr und mehr Fonts in die Distribution aufzunehmen?

    Ich würde hier eher dem Minimalprinzip folgen und die Anzahl der Fonts begrenzen und weitere Fonts als nachinstallierbare Pakete vorhalten.

    Im originalen GEOS/BBX waren 10 Vektorfonts enthalten (davon 1 Symbolfont) das sollte doch als Grundausstattung genügen oder? So ist mir der Sinn der Fonts MarVoSym oder z003 in der Distribution nicht klar. Diese Fonts gehören aus meiner Sicht in Pakete die der Nutzer bei Bedarf installieren kann.

    Ich hatte damit begonnen das FontData Verzeichnis etwas aufzuräumen und eine Übersicht über die Fonts die in der Distribution enthalten sind zu erstellen und damit auch Dateien die in diesem Verzeichnis liegen zusammenzufassen (info.txt, HINTING.txt usw.) oder zu ersetzen um damit eine Basis für die Dokumentation der Fonts zu schaffen. Das sollte dann etwa so aussehen: https://github.com/jirkakunze/pcg…ont_overview.md Ich denke es ist wichtig eine solche Übersicht zu haben und diese überschaubar und aktuell zu halten.

    Mein Vorschlag wäre sich zunächst auf die Fonts zu konzentrieren die wirklich in die Distribution sollen (Beispiel: der Font NYTFranklin in der Distribution ist noch unvollständig und hat die falsche Gewichtung).


    JIrka

    Es ist auch dein FreeGEOS!

    Sounds very good. Typographically speaking it should be enough with a mono, roman, sans and symbol font set, but I guess that is considered to be too meager, I support the thought to adapt to the traditional Ensemble font set of 10 font with symbol font set.

    Is it possible to create a tool, like "Font Converter", that adapts the TTF fonts to Geos, or is this a manual craft for every font? My thought is if it is possible, then people can choose the fonts themselves and adapt it to Geos, and the manhours can be spent more wisely, than converting each and every font users ask for. I think I asked this previuosly, but I did not understand the answer.

    Great job, Jirka!

    Die ursprünglichen Fonts möglichst identisch und hochwertig zu ersetzen erscheint mir auch richtiger und wichtiger, als weitere Fonts in das Grundpaket aufzunehmen (sofern es keinen triftigen Grund dafür gibt). Qualität vor Quantität...

    Die Fonts Besley und Bodoni sollen nicht ins Build sollten nur nach github , aber mal sehen was Falk meint.

    hanslse "Font Converter", that adapts the TTF fonts to Geos , no chance too complicate.

    I have to copy characters and rename the character IDs manually.

    @Jirka Font NYTFranklin in der Distribution ist noch unvollständig , ich bin leider kein Font designer !

    Alle Zeichen sind im Font nur nicht gezeichnet !

    10 Fonts im Build reichen !

    Die Auswahl hat glaube ich Falk gemacht !

    Copperplate CC Bold geht ohne Bearbeitung !

    Gruss von Nico

    Edited 2 times, last by nschu (April 9, 2025 at 9:25 PM).

    Mein Posting bezog sich auf Issue #858 bzgl. fehlender Font-IDs. Das hätte ich vielleicht schreiben sollen… Der Vorteil diese spezifischen Fonts in der Distribution zu haben, besteht darin, dass sie in vielen alten PostScript Druckern enthalten sind. Verwendet man sie, können diese alten Drucker dank Reolution Enhancement Tricks mit wenig Speicher und wenigen zu übertragenden Daten hervorragende Druckqualität liefern. Das „alte GEOS“ hat das auch so vorgesehen und das nötige Mapping implementiert. Die Fonts wurden seinerzeit allerdings separat verkauft.

    Die meisten, die hier nach einem 1:1 Ersatz für bekannte Fonts rufen, haben vermutlich noch nicht versucht, selbst welche zu finden. Das kann nämlich sehr frustrierend sein. Es gibt zig Webseiten, die Alternativen zu gesuchten Fonts offerieren - die allerwenigsten Suchresultate führen aber zu guten freien Fonts. Was auch kein Wunder ist, weil viel Arbeit in einem guten Font steckt.

    Es ist daher vielleicht die bessere Strategie, erstmal nach hochwerten freien Fonts zu suchen. Wie das im Fall von Claredon und Bodoni* geschehen ist. Diese hat der Autor explizit als moderne Varianten klassischer Fonts erstellt. „Klassisch“ bedeutet, dass GEOS diese Fonts bereits „kennt“. Denn die Macher von GEOS haben intern nälichbereits eine große Liste populärer, klassischer Fonts/IDs hinterlegt, anhand derer GEOS die nächstbeste Entsprechung für einen nicht vorhanden Font ermitteln kann. Im Ergebnis kann eine Ersetzung allemal besser ausfallen, als einen „schlechten“ Font zu verwenden. Bsp:

    URW Gothic = ITC Avante Garde = Sub-ID 12
    …
    URW Franklin Gothic = ITC Franklin = Sub-ID 04
    …
    URW Sans = Adobe Helvetica = Sub-ID 00

    Hat also jemand URW Gothic (Avante Garde) im Dokument verwendet, ihr aber habt diesen Font nicht installiert statt dessen aber ITC Franklin, so wird GEOS Franklin Gothic verwenden. Gibt es auch kein Franklin, wird am Ende URW Sans benutzt.

    Bei meinen aktuellen Test war eine Abwätskompatibilität mit alten GEOS-Version nicht gegeben. Sprich in mit GEOS6+TTF erstellten Dokumenten wurden die Fonts unter GEOS 2/3/4.x überhaupt nicht erkannt. Hat das was mit der Munfacturer-ID von TTFs zu tun, die alte GEOS-Versionen nicht kennen?

    Hallo zusammen,

    das Fuzzy-Matching wie von Thomas beschrieben gibt es in GEOS nur in Richtung der PS-Erstellung für Drucker und Dateiexport. Für die Bildschirmausgabe gab es kein automatisches Font-Mapping in GEOS 2/3/4.x, dies wurde erst für GEOS 6 implementiert. Aus dem Grund kann es für Dokumente die mit GEOS6+TTF erstellt wurden in GEOS 2/3/4.x nicht funktionieren. Das Mapping für den Bildschirm ist auch ein exaktes Mapping, es wird nur auf Fonts gemapped mit der exakt gleichen ID (unabhängig von der Hersteller/Format-Angabe). Zusammen mit der Auswahl von Font mit identischen Metriken, wollte ich vermeiden, dass Fuzzy-Matching zu Umformatierungen der Dokumente führt, wenn das überhaupt so funktionieren würde.

    Viele Grüße,

    Falk \\ blueway.Softworks

    Ich persönlich halte es auch für sehr wichtig Fonts zu finden, die den alten Fonts zum verwechseln ähnlich sind.
    Wie Thomas schon schrieb ist die Suche hier sehr aufwändig, da der zu suchende Font sehr viele Kriterien erfüllen muss.
    Vielleicht ist dann ein anderer Denkansatz möglich.
    Was würde es kosten, einen Fontdesigner zu beauftragen extra für Geos freie Fonts (mit klitzekleinen Abweichungen) zu erstellen, mit den von uns benötigten Kriterien? Wieviel würde so etwas kosten anstelle weitere Monate und Jahre nach entsprechenden Fonts zu suchen?
    Man könnte ja mal eine Anfrage (Kostenvoranschlag) an einen Fontdesigner stellen. Und dann können wir schauen ob wir das Geld durch eine Spende zusammen bekommen könnten.

    Gruß Frank

    Geos + Lenovo Ideapad 5 = Aufbruch in eine neue Galaxie

    Hallo zusammen.
    Ich finde, mit den Fonts, die wir zur Zeit haben, sind wir ganz gut aufgestellt. Für Schriftverkehr, Tabellenkalkulation und andere Anwendungen sind diese Fonts meiner Ansicht nach vollkommen ausreichend. Wir sollten uns besser darauf konzentrieren, Fehler in den Zeichensätzen, wie sie jetzt kürzlich aufgetaucht sind, zu finden und zu beseitigen.
    Ein anderes Thema ist die Darstellung auf dem Bildschirm. Dort ist meines Erachtens noch Luft nach oben. Wenn ich die Darstellung der Fonts in PC/GEOS 6 mit denen in Breadbox Ensemble 4.x vergleiche, gibt es da noch Unterschiede.

    Gruß Achim


    PC/GEOS unter Linux in der DOSEMU = UNSCHLAGBAR!

    Quote from Achim

    Hallo zusammen.
    Ich finde, mit den Fonts, die wir zur Zeit haben, sind wir ganz gut aufgestellt. Für Schriftverkehr, Tabellenkalkulation und andere Anwendungen sind diese Fonts meiner Ansicht nach vollkommen ausreichend. Wir sollten uns besser darauf konzentrieren, Fehler in den Zeichensätzen, wie sie jetzt kürzlich aufgetaucht sind, zu finden und zu beseitigen.
    Ein anderes Thema ist die Darstellung auf dem Bildschirm. Dort ist meines Erachtens noch Luft nach oben. Wenn ich die Darstellung der Fonts in PC/GEOS 6 mit denen in Breadbox Ensemble 4.x vergleiche, gibt es da noch Unterschiede.

    Die Darstellung auf dem Bildschirm ist in den Nimbusfonts in den originalen Fonts mit Bitmap bei kleiner Darstellung verbessert worden die fehlen natürlich in TTF das wäre eine mega Arbeit !

    Sogar habe ich Test mit Umwandlung in FNT (Nimbus) mit MoreTools gemacht , finde in mehreren Punkten TTF besser , Jirka hat tolle Arbeit geleistet !!

    Leider Fehlen in einigen Fonts Einige Zeichen die sind in den originalen Fonts nicht enthalten das ist aber ein Deseigner Job , da kenne ich mich nicht aus , meine Augen sind auch nicht die besten mehr!

    Die Nimbus Fonts sind nun komplett da bin ich froh , nun haben wir die Geostabelle komplett in dem Hintingprogramm.

    Gruss von Nico

    Es liegt mir mehr als fern, Jirkas Arbeit in irgendeiner Weise zu schmälern, ich wollte nur Aufzeigen, wo meines Erachtens noch dran gedreht werden könnte.

    Was heißt das genau, die Darstellung mit Bitmaps zu verbessern? Was wäre da zu tun? Ich kann mich dunkel erinnern, das davon schon einmal die Rede war.

    Gruß Achim


    PC/GEOS unter Linux in der DOSEMU = UNSCHLAGBAR!

    Quote from Achim

    Was heißt das genau, die Darstellung mit Bitmaps zu verbessern? Was wäre da zu tun? Ich kann mich dunkel erinnern, das davon schon einmal die Rede war.

    Vom Hörensagen gefüttert würde ich es so beschreiben (bitte korrigieren, falls fehlerhaft):

    • Die Schrift selbst ist in Form von Vektordaten beschrieben, kann also gut über viele Größen skaliert werden.
    • Für die Darstellung auf dem Bildschirm muß die Vektorbeschreibung eines Buchstaben bzw. Zeichens in Bildschirm-Pixel umgerechnet werden (Rasterisierung).
    • Insbesondere bei kleinen Schriftgrößen, wenn jedes Zeichen nur wenige Pixel umfaßt, ist es schwierig, eine automatische Lösung zu konstruieren, die (schnell) gut lesbare Ergebnisse liefert. Soll nun das Pixel links oder rechts der Linie ausgefüllt werden?
    • Für bessere Ergebnisse hat wohl GeoWorks damals für ihre Systemschriften für kleine Größen Bitmap-Schriften erstellt, bei denen also die Aufteilung der Zeichen auf Pixel schon erfolgt ist. Die Pixel-Darstellung wurde wohl handoptimiert, das hilft ungemein bei komplexeren Zeichen oder Buchstaben mit Akzenten: ä, á, à, å.
    • Ein Nebeneffekt könnte gewesen sein, daß Bitmap-Schriften (potentiell) auch schneller dargestellt werden können, da die Rasterisierung entfällt (was aber evtl. wegen Caching u.ä. kein besonders starker Effekt war).

    Hallo Sebastian,

    deine Ausführungen sind korrekt. Ab da du es sicher ganz genau wissen willst hier noch zwei Ergänzungen:

    Nachdem die Vektordaten auf die gewünschte Größe runterskaliert wurden, werden diese zunächst vom Bytecodeinterpreter bearbeitet. Aufgabe des Interpreters ist es bestimmte Eigenschaften eines Zeichens trotz Verkleinerung zu erhalten. Ein Beispiel: Wenn man das kleine m sehr weit runterskaliert kann es passieren das die stems (das sind die drei senkrechten Striche auf denen die beiden Bögen liegen) verschmelzen. Für das kleine m ist also der Bytecode so geschrieben dass zwischen den drei stems immer noch mindestens ein leerer Pixel liegt. Das kann unter Umständen bedeuten dass das m dann etwas breiter als ursprünglich berechnet wird. Das ist aber nur ein Beispiel. Der Interpreter kennt auch Instruktionen die versuchen einen Bogen trotz Skalierung als Bogen zu erhalten. Das hat aber alles seine Grenzen.

    Während des Rasterizing gibt es noch eine Absicherung die sich dropout control nennt. Wenn ein Zeichen verkleinert wird kann es passieren das bestimmte Teile des Zeichens eine berechnete Breite (oder Höhe) von 0,4 Pixeln hat, damit das nicht zu 0 Pixel gerundet wird greift hier das erwähnte dropout control ein und setzt in diesem Fall dennoch den Pixel. Ich Wirklichkeit ist das noch komplizierter weil es verschiedene dropout modes gibt die natürlich auch vorher noch berechnet werden müssen.

    Wer hätte gedacht dass das rendern eines Zeichen so komplex sein kann....


    Zur Darstellungsqualität der Zeichen:

    Aktuell wurden die Fonts im Repo mit einem Autohinting Tool bearbeitet. Dieses schreibt für jedes Zeichen im Font ein wenig Bytecode der dafür sorgt dass die Qualität auf dem Bildschirm gut ist. Ich denke hier haben wir das Maximum raus geholt was mit solchen Tools möglich ist. Nico hat da viel Zeit investiert und verschiedene Tools für uns getestet und die Fonts entsprechend angepasst.

    Perfekt ist die Darstellung auf dem Bildschirm damit nicht. Das ist uns bewusst. Mir schwirren im Hinterkopf noch zwei Ideen herum wie man da noch bessere Ergebnisse erzielen kann. Das ist aber noch nicht zu Ende durchdacht geschweige denn vernünftig analysiert. Ich muss also noch um etwas Geduld bitten. Bei Bedarf kann ich darüber auch auf den nächsten GEOS-Treffen referieren:-)

    Jirka

    Es ist auch dein FreeGEOS!

    Quote from Jirka Kunze

    Bei Bedarf kann ich darüber auch auf den nächsten GEOS-Treffen referieren:-)

    Unbedingt :love:

    Ich fände es sowieso interessant, neben den allgemeinen Vorträgen auch spezifischere, die (etwas) tiefer in bestimmte technische Themen eintauchen, anzubieten. Die wären dann wsl. nicht mehr für jeden interessant, aber würden auch einen Wissensaustausch ermöglichen und so die Geos-Treffen um einen Aspekt erweitern.

    Allerdings könnte es schwierig werden, mehr Vorträge zeitlich unterzubringen. Und die entsprechende Zeit fehlt dann beim (gemeinsamen) Arbeiten. Muß man vielleicht vor Ort operativ entscheiden.

    Edited once, last by sebi (April 17, 2025 at 12:07 AM).