Beiträge von Jirka Kunze

    Nein, das ist liegt leider nicht auf GitHub. Um das in den Sourcetree zu stellen, müssten auch alle beteiligten Entwickler zunächst ihr ok geben.

    In das Spiel hatten wir damals auch eine Infobox eingebaut mit einem Bild jedes Entwicklers. Ich bin mir nicht sicher ob ich alle noch erkennen würde....


    Jirka

    Hallo,

    Gonzo läuft hier ebenfalls nicht. Aktuelle Version von Rainers Seite installiert, ohne weitere Libraries. Stürzt sofort beim Aufruf mit KR-09 ab.

    Nach Umstellung auf ISUI ebenfalls.

    die Ursache des o.g. Problems ist identifiziert. Es ist die noch unvollständige Implementierung des GEN_IN_REGION Handlers des TTF-Treibers. Die Korrektur ist in Arbeit (siehe auch Thread zum Stand des TTF-Treibers). Ich bitte noch um etwas Geduld.


    Danke an alle die beim Eingrenzen des Problems geholfen haben.


    Grüße

    jk

    Hallo in die Runde,

    In verschiedenen Threads hier gab es ein paar Fragen zu den TTF-Fonts. Um die anderen Threads nicht zu 'verunreinigen' haben ich hier ein paar Infos zusammengestellt um den interessierten Nutzern einen kurzen Überblick zu geben.

    Wie ist der Stand der Dinge?

    Der TTF-Treiber muss eine definierte Schnittstelle zum Kernel erfüllen. Das tut er aktuell (damit ist der Stand in github gemeint) zu ca. 90%. Für die letzten 10% habe ich eine (noch nicht stabile) Implementierung hier 'rumliegen'. Ein Weg diese zu testen ist gefunden, jetzt muss der Code noch stabilisiert und weiter getestet werden. War das erfolgreich, dann ist die Schnittstelle zu 100% erfüllt.


    Was geht und was geht nicht?

    Im Treiber haben wir mittlerweile eine künstliche Begrenzung der Fonts eingeführt. Aktuell werden nur noch TTF-Fonts mit max. 2000 Zeichen akzeptiert. Warum das? Fonts mit einer sehr großen Anzahl von Zeichen belegen sehr viel Hauptspeicher bereits beim ersten laden. Konkret ist das bei einem GNU Font aufgefallen der ca. 10500 Zeichen enthielt. Das hatte zur Folge das GEOS unbenutzbar wurde. Es gibt aber die Möglichkeit solche großen Fonts zu reduzieren, dann können sie auch unter GEOS genutzt werden. Grundsätzlich ist das Speicherhandling im Treiber noch nicht 'GEOS-freudlich' mehr dazu weiter unten.


    Darstellungsqualität bei kleinen Punktgrößen?

    GEOS rendert Fonts als s/w Bitmaps. Werden Vektorfonts auf kleinere Punktgrößen heruntergerechnet machen sich Rundungen (man kann einen Pixel ja nur setzen oder nicht setzen) besonders stark bemerkbar. Zu sehen ist das an Ausfransungen an den Rändern von Zeichen, Asymetrien oder fehlende Pixel. Eine Technik namens Hintig soll diesen Darstellungsproblemen entgegenwirken. Dieses Hinting ist im TTF-Treiber aber noch deaktiviert da es wieder viel Speicher beansprucht (eigentlich ist es noch komplizierter), denn mit aktiviertem Hintig wird der Treiber sehr instabil. Es ist aber geplant diese Probleme anzugehen und das Hintig zu aktivieren, allerdings muss der Font das Hintig auch unterstützen. Meine Erfahrung sagt das neuere Fonts das nicht immer tun. Auf anderen Systemen ist das auch nicht notwendig da die genannten Darstellungsprobleme mit anderen Techniken vermieden werden (Anti-Aliasing oder Subpixel). Woran kann man erkennen das ein TTF-Font Hinting unterstützt? Da muss in den Font 'hinein' geguckt werden. Enthält der Font Tabellen vom Typ 'prep', 'cvt' und 'fpgm' (und diese sind nicht leer) dann wird das Hintig unterstützt. Es gibt eine Reihe von Tools die die innere Struktur eines Fonts anzeigen können.


    Was sind die nächsten Schritte?

    Zunächst sind die o.g. fehlenden 10% verfollständig und stabilisiert werden. Dann muss das Speicherhandling des Treibers noch überarbeitet werden (aus meiner Sicht die unangenehmste Aufgabe) und das Hinting für GEOS fit gemacht werden.


    Welche Probleme gibt es noch?

    Aktuell gibt es noch drei offene Bugs (in github ist das #272, #273 und #274). Eventuell ist #272 bereits durch Korrekturen am Font-Mapping gefixt. Das wäre noch zu testen. Dann muss die Performance des Treiber noch deutlich verbessert werden. Ein direkter Vergleich der Renderzeiten von Nimbus und TTF-Treiber wäre auch noch interessant um herauszufinden wieviel da noch zu tun ist. Da die Font Funktionen im Kernel quasi für die Struktur der Nimbus-Fonts 'maßgeschneidert' wurden wird der TTF-Teiber die Performance des Nimbus-Treibers nicht erreichen können.
    Das Hauptproblem wird aber die mir zu Verfügung stehende GEOS-Zeit sein. Die ist seit einigen Monaten deutlich gesunken. Ich hoffe ist wird bald wieder besser...

    Ich hoffe ich bin bei meine Ausführungen nicht zu technisch geworden.

    Jirka

    Ja, die Darstellung der TTF-Fonts gerade bei Punktegröße < 24 ist noch problematisch. Das zeigt sich in Asymetrien, Ausfransungen und Ungleichmäßigkeiten. Dieses Problem wird mit dem Bytecodeinterpreter gelöst (zumindest für die Fonts die Bytecode unterstützen). Dieser ist in der aktuellen Version des TTF-Treibers aber noch nicht aktiv.

    JIrka

    Hallo Mitstreiter,

    für das kommende PC/GEOS-Treffen ist ein Vortrag zum aktuellen Stand des TrueType-Treibers gewünscht. Das übernehme ich gerne.

    Folgen Punkte würde ich ansprechen:

    • Was ist fertig und was ist noch zu tun
    • Welche TrueType Fonts können unter FreeGEOS genutzt werden
    • Live-Demo des aktuellsten Treibers

    Falls hier noch jemand zu dieser Thematik etwas einfällt was ich unbedingt behandeln soll, bitte hier eintragen.

    JIrka

    Hallo,

    das FreeGEOS ist noch eine Vorversion die noch unvollständig ist.

    In deinem konkreten Fall betrifft das die Vektorfonts. Wenn diese nicht gefunden werden, wird auf den Defaultfont ausgewichen, was ein Bitmapfont ist.

    Eine mögliche Lösung dieses Problem wäre die Vektorfonts aus Breadbox Ensemble in das FreeGEOS zu kopieren.


    Beste Grüße
    Jirka

    Hallo Nico,

    danke für den Hinweis. Ich habe mir das ps2pdf.geo in den target gesendet und schon werden beim Drucken in die Datei ordentliche PS-Files erzeugt (auch auf dem EC-Target).

    Das ps2pdf.geo übernimmt offensichtlich die von Hans beschriebene Aufgabe und delegiert die Erstellung des PDFs an das DOS GhostScript.

    Ich bin mir nicht sicher ob das für die Zukunft noch der richtige Weg ist, da das GhostScript für DOS nicht mehr gepflegt wird. Das ist aber wieder eine andere Geschichte und kann separat bei Gelegenheit besprochen werden.

    Jirka

    Hallo in die Runde

    nun habe ich eine Reihe von Druckern unter FreeGEOS ausprobiert. Aber es will einfach nicht klappe mit dem erstellen einer PS Datei. Ich bekommen immer einen SL-40 als Fehlermeldung, es scheint das gleiche Problem zu sein dass Achim gerade in einem parallelem Thread geschildert hat.

    Ich bin mir aber sicher dass wir im Kontext Drucker/drucken in FreeGEOS gegenüber BBX Ensemble nichts geändert haben.

    Beste Grüße
    Jirka

    Hallo in die Runde,

    das ist ein großer Schritt.

    Jetzt ist die Community gefragt, denn das ist eine gute Gelegenheit sich an der Entwicklung von FreeGEOS zu beteiligen. Ganz nach dem Motto "Es ist auch dein FreeGEOS".

    Viele Grüße
    Jirka

    Hallo,

    vielen Dank für die hilfreichen Tipps.

    Unter Ensemble habe ich bereits PS-Dateien erzeugen können. Nächster Schritt wird dann sein gleiches unter FreeGEOS (mit dranhängendem Swat) hinzubekommen.

    Viele Grüße
    Jirka

    Hallo Community,

    zu Test und Forschungszwecken benötige ich unter GEOS die Möglichkeit Dokumente in eine PS-Datei auszudrucken.

    In den Preferences habe ich dazu verschiedene Drucker ausgewählt und als Port "To File" selektiert. Im Druckerdialog lässt sich das Testdokument auch erzeugen (etwa 123kb groß) aber diverse Programme sind der Meinung dass sich die PS-Datei nicht auswerten lässt (Gimp, Inkscape, Dokumentbetrachter) andere rendern einfach nur eine leere Seite (diverse Online-Betrachter).

    Habt ihr eine Idee woran das liegen könnte? Oder ein paar Tipps wie ich die Ausgabe in PS-Dateien unter GEOS hinbekomme?

    Danke
    Jirka

    Das Rätsel ist gelöst.

    TrueType unterstützt Kerning sowie als das Verringern des Abstands relevanter Zeichen (negative Kerning Values), als auch das Vergrößern dieses Abstands (positive Kerning Values).

    Der GEOS Kernel beherrscht offensichtlich nur den ersten Fall. Im Falle von positiven Kerning Values wird die Cursorposition falsch berechnet.


    Mir ist es allerdings ein Rätsel wozu man das Vergrößern des Abstands bestimmter Zeichen benötigt, zumal der Begriff Kerning vom englischen to kern (also unterschneiden) stammt.


    Jirka

    Hallo Geos-Gemeinde,

    ich muss mich wiedermal mit einer kniffligen Frage an euch wenden.

    Ich beschäftige mich gerade mit dem Thema Kerning. Dazu wollte ich mir das Verhalten des Nimbus Treibers, mit Fonts die Kerning Informationen enthalten, ansehen.
    Allerdings musste ich feststellen dass die im Ensemble enthaltenen Nimbus-Fonts offensichtlich keine Kerning Informationen enthalten. Im FontBuf werden für alle diese Font eine Anzahl der Kernningpairs von 0 ausgewiesen. Der Offset zu den Kerningpairs und zu den Kerningvalues ist auch jeweils 0.

    Ist das bekannt, oder liege ich hier falsch? Gibt es Nimbus-Fonts die Kerning unterstützen? Es gab ja bereits Versuche Fonts zu konvertieren. Werden bei der Konvertierung die Kerning Informationen mit übernommen?


    Danke
    Jirka

    Hallo,

    ich habe mit dem von Thomas erwähnten Programm die Geschwindigkeit meiner DOSBox-Staging Konfiguration bewertet und komme auf einen Wert der etwas über einem 486DX-2 66MHz liegt. Ein bisschen erschrocken habe ich mich über den Wert schon, denn ich hatte meinen alten 486DX 40MHz (beispielsweise beim Aufbau der Fenster) deutlich schneller in Erinnerung. Mag sein dass das am EC-Target liegt den ich hier zum testen benutze.

    D.h. die Performance des Treibers ist noch lange nicht ausreichend. Ideen wie das in die Reihe zu bekommen ist gibt es bereits.

    Danke für die Infos.

    Jirka