Beiträge von Jirka Kunze

Über die Bitmapfonts kann ich nicht viel sagen. Die Bitmapfonts werden in den Tiefen des Kernels gelesen und gerendert. Auch der Nimbus-Treiber greift dort nicht ein. Ich vermute es gibt keine Dokumentation die die Struktur der Geos-Bitmapfonts beschreibt. Da bleibt dann nur Reverse Engineering...

Hallo Nico,

Zitat von nschu

Outliner benutzt Font URW_Sans wird gemappt mit Nimbus Sans Info von Falk !

stimmt, ich hatte bei mir noch alle TTF-Fonts mit Ausname des PT Mono Fonts entfernt um ein Problem im dem TTF-Treiber besser untersuchen zu können. Wenn ein vom Programm gewünschter Font nicht gefunden wird dann wird der Default-Font genutzt und das ist ein Bitmap-Font...

Jirka

Hallo Nico,

Zitat von nschu

Ich kann die PS Datei korrekt drucken ohne truetype.geo der abgeschnittene Teil enthält Heletica hat das nicht etwas mit Schriften Truetype zu tun ?

In Anderen Anwendungen und Testseite wird korrekt erstellt.

Test mit Write.

Allen Mut Jirka wir schaffen das !

Postscript Drucker kennen einen gewissen Satz an Fonts (also quasi interne Fonts) das sind keine TrueType Fonts sondern wahrscheinlich Type 1 Fonts.

Da der Outliner keine Vectorfonts nutzt sondern alles mit Bitmapfonts realisiert, muss für das Drucken der Bitmapfont auf einen dieser internen Fonts gemappt werden. Im konkreten Fall wird dafür der Font Helvetica ausgewählt. In swat erhält man auch eine Info wenn ein solches Mapping stattfindet:

Wahrscheinlich geht GEOS das Dokument zeilenweise durch und da es 6 Zeilen enthält gibt es 6 solche Infos.

Die PS Datei ist bei mir aber vollständig. Der Inhalt wird nur zuweit oben eingefügt:

Ich vermute dass die Koordinaten einfach nicht korrekt sind (ich vermute die 4 Zahlen die vor dem DSG stehen sind irgendwelche Koordinaten).

Allerdings bin ich kein Kenner des Postscript Universums, von daher sind meine Vermutungen nicht unbeding belastbar.

Jirka

Hallo Nico,

zunächst mal vielen Dank dass du hier so intensiv testest.

Die Probleme in Gonzo und im Outliner haben mit hoher Wahrscheinlichkeit unterschiedliche Ursachen.

#zur Durckvorschau im Outliner

Ja, es sieht danach aus als ob die PS, die mit dem akt. Build erzeugt wurde, mitten in einer Zeile endet. Die genaue Ursache kann ich nicht erkennen. Aus meiner Sicht gibt es aber nur zwei Verdächtige... Hast du mal getestet ob das Verhalten auch bei Wirter Dokumenten auftritt? Auf jeden Fall ist das einen Issue auf Github wert.

#zu Gonzo

Falk hatte ja schon beschrieben dass das Zeichnen des farbigen Gonzo Logos als sehr wahrscheinliche Ursache in Frage kommt. Hier ist wahrscheinlich der Stack für einen Handler im TTF-Treiber zu klein bemessen. Für den relevanten Handler habe wir den Stack bereits um 400byte erhöht. Für einen anderen Handler war bereits eine Erhöhung um 1000byte notwendig. Vielleicht sollten wir für den Gen_In_Region Handler auch auf 1000byte erhöhen. Das Problem ist dass der notwendige Bedarf auf dem Stack nur schwer zu ermitteln ist. Das ist konstrutiv durch die Art und Weise wie in C Parameter und Rücksprungadressen bei Funktionsaufrufen übergeben/gehalten werden. Auch das ist einen Issue auf github würdig.

Die höhere Anzahl an Problemen und Fehlern die in den letzten Wochen/Monaten hier aufgekommen sind mögen den einen oder anderen vielleicht pessimistisch stimmen. Ich kann aus eigener Erfahrung aus anderen (kommerziellen) Projekten aber sagen dass das normal ist. Also kein Grund für Pessimismus zumal die Dynamik der GEOS Entwicklungen momentan so hoch ist wie seit vielen vielen vielen Jahren nicht mehr.

Jirka

Hallo Andreas,

du hast ein Array aus chars definiert und diesem die Bezeichnung ldv gegeben. Wenn du ldv (ohne &) benutzt ist damit die Adresse des ersten Elements aus dem Array gemeint. Mit anderen Worten ldv ist für C das gleiche wie &ldv[0].

D.h. &ldv wird irgendwo in den Speicher zeigen. Ich vermute dass der Zugriff auf diese Speicherstelle nach einer ausreichend großen Anzahl von Versuchen auch mal schief gehen sollte. Auch vermute ich dass der Watcom Compiler wegen der Addition mit l meckert.

Jirka

Can someone confirm that the crashes of Gonzo are related to the file system drivers?

Jirka

Hallo Marcus,

Zitat von mgroeber

Gibt es aktuell irgendeinen Bereich, den ich mir mal genauer ansehen könnte, ohne dir im Weg zu sehen? Ich nehme an, das ist immer noch der alte TTF Branch in deinem Repo?

ciao marcus

seitdem der Treiber in den master gemerged wurde erstelle ich mir für jede Teilaufgabe einen eigenen Featurebranch. Aktuelle ist das https://github.com/jirkakunze/pcg…mory-management .

Im Prinzip verfolge ich zwei Strategien:

• Große Blöcke auf die es nur wenige Zugriffe gibt (das sind vor allem die Arrays) nicht mehr mit Makro ALLOC_ARRAY sondern mit GEO_ALLOC_ARRAY zu allocieren und Zugriffe dann mit GEO_LOCK und GEO_UNLOCK locken/unlocken. Für die Glyphlocation ist das bereits umgesetzt.
• Optionale Tabellen deren Daten vom Treiber nicht benötigt werden nicht mehr verarbeiten. Das ist für die hdmx Tabelle bereits umgesetzt.

Du stehst sicher nicht im Weg. Im Gegenteil ich freue mich über Hinweise und Tipps.

Jirka

Hallo Achim,

Zitat von Achim

Frisches deutsches Geos, Gonzo installiert. Beim Start läuft Gonzo exakt bis zur Dialogbox "RABE-Soft präsentiert:" und dann ist Feierabend. Das allseits bekannte Fenster mit "KR-09, drücken Sie Taste E zum Beenden" erscheint. Mit dem von mir genannten Font SANS.FNT läuft Gonzo.

das Problem ist leider nicht so einfach zu greifen.

Auf meinem ThinClient mit suboptimal konfigurierten FreeDOS (nur konventioneller Speicher ca. 540kb) konnte ich das Problem nachstellen, bin bei verschiedenen Testläufen aber unterschiedlich weit gekommen. Mal war bei der von dir erwähnten Dialogbox Schluss, mal kam ich etwas weiter.

Mit besser konfiguriertem FreeDOS funktioniert Gonzo in 4 von 5 Fällen ohne Probleme. In meiner Debugging Umgebung (Rainer hatte mir die sym Files netterweise bereit gestellt) funktioniert Gonzo auch.

Ich vermute dass die vielen fixen Speicherblöcke die Ursache für die geschilderten Probleme sind. Das Speichermanagement des Treibers ist gerade in Arbeit. Sobald dort Fortschritte erzielt wurden werde ich das Szenario mit Gonzo nochmal testen.

Jirka

Hallo Achim,

Zitat von Achim

Ich versuche mal, es mit ein paar Bildschirmfotos zu verdeutlichen.

Font-Dateinamen haben kleine Buchstaben, der Font Viewer findet/liest diese Fonts gar nicht.

Font-Dateinamen haben grosse Buchstaben, der Font Viewer findet/liest diese Fonts und man kann sie öffnen und anzeigen.

Das betrifft - so wie es hier aussieht - wohl nur FNT-Dateien, TTF-Dateien werden anscheinend vom Font Viewer ignoriert.

jetzt habe ich es verstanden.

Der Font Viewer ist ein Werkzeug mit welchem Fonts betrachtet werden können ohne diese installieren zu müssen. Da dazu die 'innere' Struktur des Fonts dem Viewer bekannt sein muss geht das nur mit den Nimbus Fonts. Ich habe den Font Viewer nicht im github Repository gefunden. Daher kann ich keine Aussage machen wie aufwändig es ist diesen für TTF Fonts fit zu machen.

Die Groß-/Kleinschreibung sollte unter DOS eigentlich keine Rolle spielen. Meine erste Vermutung wäre das hier der Host (wenn ich mich richtig erinnere verwendest du DosEmu) eine gewichtige Rolle spielt.

Jirka

Bisherige Erkenntnisse zum genannten Problem mit dem TTF-Treiber:

Der Gonzo Schriftzug im Registrieren Dialog ist nicht mehr das Problem, denn dieser wird ohne 'Zwischenfälle' gerendert. Da muss ich etwas tiefer forschen... Neuigkeiten dazu gibt es in diesem Thread.

Jirka

Hallo,

Zitat von Geos-Tiger

Hallo,

ich habe mir gerade letzte Geos-Version heruntergeladen und installiert. (6.0 0-621) Gonzo stürzt bei mir aber immer noch ab.

Wenn ich den URW Sans.FNT in userdata/font installiere funktioniert Gonzo.

Jens

Danke für das Testen. Ich gucke mir das gleich an.

Das Problem mit den Großbuchstaben im Font-Viewer habe ich aber nicht verstanden. Könnt ihr das bitte etwas präzisieren?

Jirka

Ich frage mich ob es für so eine Anwendung überhaupt Anwender gibt die diese brauchen. Ich denke der Aufwand diese App anzupassen und zu prüfen ist besser in Übersetzungs- und oder Testarbeit investiert.

Da wir gerade dabei sind. Gibt es eigentlich eine Übersicht was noch für das erste Release zu tun ist (Entwicklung, Übersetzung, Artwork, ...)?

Jirka

Hallo in die Runde,

hat schon mal jemand unter den Geos-Entwicklern mit KI-Assistenen als Unterstützung der Programmierung experimentiert? Wenn ja, mit welchem und was kann dieser so?

Jirka

Anbei ein kleines Statusupdate.

Was gibt es Neues?

Die Implementierung des GEN_IN_REGION Handlers ist erfolgreich abgeschlossen. Das bedeutet die Schnittstelle die der Treiber erfüllen muss ist jetzt zu 100% fertig. Die Änderungen sind bereits in master und im neuesten CI-Build enthalten. Mit der neuen Version des TTF-Treibers funktioniert nun auch Gonzo wieder.

Was ist noch zu tun?

Auf der ToDo-LIste stehen noch folgende Aufgaben:

• Speicherhandling des Treibers an die Bedürfnisse von PC/Geos anpassen
• Bytecodeinterpreter aktivieren
• Speicherbedarf, Binarysize und Performance optimieren
• Offene Bugs (sind aktuell (nur) 2) und alles andere was unterwegs noch so auffällt

An was wird gerade gearbeitet?

Ich habe jetzt begonnen mich mit dem Speicherhandling des Treibers zu beschäftigen. Ein erster Block ist bereits von einen fixed Block zu einem movable und swapble Block geworden. Es müssen aber noch ein paar weitere folgen.

Zusammenfassung und Ausblick

Vor dem Umbau des Speichermanagement hatte ich schon Angst Respekt. Die ersten Schritte in diese Richtung haben aber gezeigt dass es wohl doch nicht so übel wird wie befürchtet. Es wird allerdings eine Mischlösung werden. D.h. die vielen kleinen Speicherschnipsel (je nach Font sind das eine größere Anzahl von denen jeder einzelne oft nur 16 oder 32 byte groß ist) verbleiben in den fixen Blöcken zu jeweils 1kb. Die großen Brocken werden werden zu movable/swapable Blöcken.

Das Aktivieren des Bytecodeinterpreters wird sicher auch noch so einige Problem unter Geos machen. Das kommt aber nach dem Refactoring des Speichermanagements.

Ich hoffe ich habe jetzt nicht zu viel technisches eingestreut....

Jirka

Ja, der Watcom Compiler ist sehr streng was die Typisierung von Funktionsparametern betrifft. Die beiden Codestellen können aber durch einen geeigneten Typecast 'gerettet' werden.

Jirka

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,

Zitat von Mütze

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

Ich war auch überrascht. Sogar der Sound wird an den Browser durchgereicht.

Jirka