Posts by Jirka Kunze

Wenn du nach

%ROOT_DIR%/Tools/build/product/bbxensem/Scripts

wechselst, funktioniert dann folgender ohne das Kopieren von newgetopt.pl noch?

perl -I. buildbbx.pl

Ursache gefunden und beseitigt. Im aktuellen Release ist dann wieder alles i.o.

Die Problemursache war schlicht und einfach dass ich das TTF-Cache File im PR an die falsche Stelle geschoben habe. Kann ja mal passieren...

Ja, so ist es unter G6. Dokumente und Programme die bspw. URW Sans nutzen, verwenden unter G6 dann Nimbus Sans. Das funtktioniert für alle Nimbus Q Fonts für die in der geos.ini ein Mapping auf TTF Fonts definiert wurde.

Seit gestern gibt es ein neues PC/GEOS 6 Release. Darin ist neben einer neuen (korrigierten und minimal optimierten) Version des TTF-Treibers auch ein neues TTF-Cachefile enthalten.

In dieser Version sollte das geschilderte Problem nicht mehr auftreten. Wer mehr darüber lesen möchte: https://github.com/bluewaysw/pcgeos/issues/1008

Quote from Achim

Mütze : Es ist tatsächlich auch bei mir so, das mit PC/GEOS 6 erstellte Dokumente z. Z. nicht mit BBE kompatibel sind. Ich weiß auch nicht, ob das jemals so sein wird, denn BBE verwendet Nimbus-Fonts und PC/GEOS 6 TTF-Fonts. Vielleicht kann Jirka etwas dazu sagen.

Mit sind die betroffenen Dokumente zwar nicht bekannt, aber wenn diese TTF-Fonts enthalten, dann wird (vermutlich) unter BBX anstelle dieser Fonts der Default-Font greifen. Das bedeutet dass die Dokumente unter BBX anders aussehen werden. Ein Fontmapping von TTF Richtung Nimbus Q ist nicht geplant, da GEOS 6 als Nachfolger von BBX geplant ist. Manchmal ist es auch gut alte Zöpfe abzuschneiden...

Jirka

Ich bin auch für die aufgeräumte Version des Fonts. Mir ist allerdings nicht klar ob ich in diesem Fall mit ja oder nein abstimmen soll

Jirka

Hallo zusammen,

ich möchte den Code eines kleinen Spiels dem FreeGEOS-Projekt zur Verfügung stellen. Bevor ich es offiziell einreiche, fehlen jedoch noch einige grafische Elemente, bei denen ich auf eure Unterstützung hoffe.

Konkret werden folgende Icons benötigt:

1. Ein Anwendungsicon für das Spiel selbst
2. Drei Icons für den Quick Tips Dialog der die 3 möglichen Spielzüge visualisiert

Da ich selbst kein Talent für Icon-Design habe, möchte ich fragen, ob jemand aus der Community Lust und Zeit hätte, diese Icons zu erstellen und mir zur Verfügung zu stellen.

HIer ein Screenshot des Spiels:

Und hier der Quick Tips Dialog mit den gekennzeichneten Stellen für die zu erstellenden Icon:


Ich würde mich sehr freuen, wenn jemand helfen kann – und bedanke mich schon jetzt herzlich für jede Unterstützung!

jk

Ich würde als Look and Feel auch Motif-Redux bevorzugen. Das ist schließlich die Oberfläche die ein Nutzer sieht wenn er das Zip installiert. Im Screenshot würde ich die typischen Produktivitäts Apps platzieren (GeoWrite, GeoDraw...) Ein schöne Headline für das dargestellte Writer Dokument hat mir ChatGPT geliefert:

"Wilkommen bei PC/GEOS Ensemble 6.0"

"Schnell, effizient, klassisch - und doch modern."

Das gefiel mir richtig gut.

jk

Ich habe jetzt auch Auto und Pension gebucht. Ich werden am Donnerstag Abend anreisen und am Sonntag Vormittag abreisen.

Jirka

Quote from Johannes Möller

Hier die Einladung für 2025

Richtig stark der Song.

Ich bin in diesem Jahr auf jeden Fall wieder dabei. Mal gucken ob ich schon ab Donnerstag dabei sein kann. Ich werde wieder im Kohrener Land übernachten.

Themenwünsche für Vorträge an mich könnt ihr gerne hier posten.

Jirka

Ich habe nun auch ein wenig mit dem geposteten Codeschnipsel experimentiert und auch in meinen Fällen wird durch round() das korrekte Ergebnis geliefert.

Eine Idee wäre da noch: Die Funktionen FloatPushNumber(), FloatPopNumber() und FloatRound() delegieren an den Coprozessor, wenn ein solcher erkannt wird, dann wird zu jeder dieser Funktionen die korrespondieren x87 Instruktion aufgerufen. Falls kein Copro gefunden wird, dann werden diese Funktion durch x86 Instruktionen 'emuliert'. Vielleicht wird bei Wilfried der Copro nicht erkannt und die Emulation ist hier das Problem. Das ist aber nur Spekulation.

Jirka

Ich habe bereits mehrere Anläufe unternommen, die Ursache für das Einfrieren bzw. die Kernel-Resets (KRs) von Gonzo unter FreeGEOS einzugrenzen. Rainer war so nett, mir dafür die Sym-Dateien von Gonzo und diversen Libraries bereitzustellen.

Trotzdem ist es mir bisher nicht gelungen, das geschilderte Problem auf dem EC-Target nachzustellen. Im Gegensatz dazu kann ich die Probleme im NC-FreeGEOS zuverlässig reproduzieren.

Ich vermute aktuell einen Zusammenhang mit dem TTF-Treiber, habe aber bislang keinen klaren Weg gefunden, das Problem systematisch weiter einzugrenzen oder zu analysieren.

Hallo in die Runde,

nun ist die letzte Info zum TTF-Treiber schon wieder so lange her....

Was hat sich seit der letzten Info getan?

Falks Caching vorgerendeter Glyphs ist nun (schon einige Wochen) im Master. Das bedeutet dass wir nun mit der Distribution für die wichtigsten Fonts/Styles/Pointsizes bereits vorgerenderte Bitmaps der einzelnen Zeichen eines Fonts mitliefern. Das sorgt für einen zusätzlichen Performance Boost gerade auf etwas schwächeren Rechner die wir nach wie vor unterstützen wollen.

Des weiteren gab es ein paar kleinere Optimierungen am Treiber die den Speicherbedarf des Treibers geringfügig minimieren. Nutzer von PC/GEOS Ensemble sollten aber keinen Unterschied bemerken.

Wie geht es weiter?

Ich habe mir als nächstes die Fonts vorgenommen. Beginnen werde ich damit den Font Nimbus Sans zu optimieren. Genauer gesagt ist dort die Kerning Tabelle noch problematisch da sie viele Kerning Paare enthält die wir nicht benötigen (und bei der Verarbeitung der Kerning Tabelle auch ausblenden). Bei meinen Performance Messungen habe ich festgestellt dass ca. 50% der Zeit, die für den Aufbau des Fontblocks benötigt werden, mit der Konvertierung der TTF Kerning Paare in das GEOS Format benötigt werden. Hier ist also noch Potential für Optimierungen.

Danach werde ich mich an den Bytecode der Fonts machen. Da das für mich Neuland ist kann ich noch nicht sagen ob die Bemühungen erfolgreich sein werden. Drückt mir die Daumen...

Tja, das war es auch schon. Da die berufliche Belastung bei mir etwas abgeklungen ist, und die diesjährige MSR auch erfolgreich hinter mir liegt, hoffe ich zukünftig wieder etwas mehr Zeit für PC/GEOS zu haben.

Jirka

Quote from Rainer

Ich finde es übrigens sehr schade, dass solche Dinge immer nur per Zufall entdeckt werden. Z.B. das hier (aktueller Build)

Ja, das kann ich nachvollziehen. Ich denke solche (und weitere) Probleme können durch automatisierte Tests/Prüfungen abgefangen werden. Grundsätzlich gibt es so etwas auch schon (das kleine grüne Häkchen an Pull Requests und Commits in den master).

Zunächst steht aber das fertige PC/GEOS ganz oben auf der Liste.

Jirka

Guter Fund.

Da stellt sich natürlich die Frage welches Format der Doku wir weiterhin unterstützen wollen. Ich selber nutze nur noch die Online MarkDown Version.

Alle drei Formate zukünftig zu pflegen halte ich nicht für sinnvoll, zumal die txt Version beispielsweise nicht die DDK Doku enthält.

Was meint ihr?

Jirka

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

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

Hallo Sebastian,

da will es aber jemand genau wissen;-)

Quote

• Der 16-Bit-Code, in den der Geos-Char-Code gewandelt wird, wäre dann zufällig UTF-16?

Ja, so ist es. Aber UTF-16 definiert ja auch Zeichen die aus 2 16-bit Werten bestehen können (sog. surrogate pairs). Das kann der Mapper natürlich nicht.

Quote

• Dann erwartet dein TrueType-Subsystem also nicht, daß die TTF-Schriften genauso wie die bisherigen Geos-Schriften aufgebaut sind (also 256 festgelegte Zeichen), sondern es sucht sich die passenden selber aus der (u.U. viel größeren oder auch kleineren?) TTF-Datei?

Richtig, du kannst dem Treiber auch einen TTF-Font mit einer größeren Anzahl von Zeichen zu futtern geben. Es gibt aber eine künstliche Begrenzung von 2000 Zeichen. Hat ein Font mehr Zeichen wird er nicht registriert (d.h. in der Fontauswahl angeboten). Ursache für dieses Begrenzung ist der Speicherbedarf des Treibers der mit der Anzahl der Zeichen wächst. Die in der Distribution enthaltenen Fonts sind aber auf den GEOS Zeichensatz beschränkt (etwas 224 Zeichen) da sich das positiv auf Speicherbedarf und Performance auswirkt. In der Anfangszeit des Treibers habe ich das mal mit dem Font Ubuntu Mono (ca. 1000 Zeichen) und durch die Reduzierung der Zeichen auf den GEOS-Zeichensatz hat sich die Performance um ca. 30% verbessert. Mit dem aktuellen Entwicklungsstand des Treibers wird das vermutlich anders aussehen.

Quote from sebi

• In der CMAP-Tabelle steht also, welchem Unicode-Zeichen jedes Schriftzeichen der Schriftdatei entspricht? Was ist, wenn die CMAP fehlt? Haben denn auch uralte TTF-Schriften schon die Unicode-Zuordnung?

Der TTF Standard definiert verschiedene Typen von CMAP Tabellen (im Font darf es auch mehrere Typen gleichzeitig geben). Vom Treiber wird aber nur die Tabelle vom Typ 4 unterstützt (das ist quasi der Standardtyp). In alten Fonts (vor Unicode) wurde vorrangig der Typ 0 genutzt. Das ist ein Mapping das einfach nur ein Array aus bytes benutzt. Hier wird also ein 8bittiger Char in einen 8bittigen Index gewandelt. Ich habe aber selbst in den Windows 3.1 Fonts immer auch eine CMAP TAbelle vom Typ 4 gefunden.

Jirka

Quote from nschu

Leider hast du recht die Adressen scheinen anders zu sein.

Mit URW Symbols gespeichert und in FreeGeos bringt es Zeichen 00C3 anstatt 00D5 dies liegt ein Platz davor !

Weiss nicht weiter , es gibt 2 Fehler Adresse CAhex (312okt) und F0hex (360okt)

Deshalb verschieben sich die Plätze wahrscheinlich!

Könnte das ein Problem des Treibers sein @Jirka ?

Gruss von Nico

Display More

Hallo Nico,

ich würde ja gerne helfen, aber ich verstehe deine Beschreibung nicht richtig.

Ich versuche einfach mal zu erklären wie das Mappen im Treiber funktioniert und welche Mitspieler es bei diesem Procedere gibt.

Wenn GEOS ein Zeichen eines Vektorfonts auf dem Bildschirm darstellen möchte wird damit ein Treiber beauftragt. Ist der Vektorfont ein TrueType Font dann ist der Treiber der TTF-Treiber an dem wir gerade arbeiten. GEOS intern liegt das darzustellenden Zeichen (aktuell) als 8bit Zeichen vor. Welcher 8bit Wert welchem Zeichen entspricht ist durch die sogenannte Codetabelle vorgeschrieben. Unter GEOS wird dabei eine Codetabelle verwendet die (mit wenigen Ausnahmen) der MAC Roman Codierung entspricht.

Wenn jetzt also ein konkretes Zeichen dargestellt werden soll, dann bekommt der Treiber ein 8bittigen Wert übergeben (ich sage dazu GEOS charcode). Dieser wird vom Treiber in den Unicode gewandelt. Das ist ein 16bittiger Code der einem internationalen Standard entspricht und 10.000e Zeichen definiert. Diese erste Stufe des Mappings findet im charmapper statt und ist spezifisch auf GEOS zugeschnitten und wird für alle TTF-Fonts genutzt. Ist der Unicode bekannt muss dieser noch in den TrueType Index gewandelt werden. Den Index kann man sich als laufende Nummer jedes Zeiches in einem TTF-Font vorstellen. Hat ein Font also 1000 Zeichen hat jedes seinen Index welcher bis zur Nummer 1000 geht (ja, hier gibt es wieder Ausnahmen, das soll aber nicht interessieren). Die Umwandlung des Unicodes in den TrueType Index läuft ebenfalls im Treiber mithilfe einer Mappingtabelle die jeder TTF-Font enthält (konkret ist das die CMAP Tabelle im Font). Wenn der Index bekannt ist kann man mit diesem die Position der Geometriedaten (die sogenannte Outline) zum gesuchten Zeichen ermitteln. Ab dann hat man alles zusammen um ein Zeichen zu rendern.

Ich habe zwar das Problem mit 0xca und 0xf0 nicht verstanden, aber wenn du damit das beschriebene Mapping der ersten Stufe meinst, würde eine Änderung an dieser Stelle Auswirkungen auf alle Fonts haben. Ich denke dein Problem muss im Mapping der 2. Stufe gelöst werden. D.h. die Zuordnung von Unicode zum TTF Zeichenindex.

Ich hoffe ich habe jetzt nicht wieder mit zu vielen technischen Details gelangweilt.

Jirka

Hallo Nico,

du musst keine Zeichen tauschen. EM_DASH und EN_DASH werden im Mapping des Treibers korrigiert. Den PR dafür habe ich bereits eingereicht.

Bei der Kontrolle des Mappings im Treiber ist ein weiterer kleiner Fehler aufgefallen der Aufzählungspunkt war auf das Unicode Zeichen BULLET_OPERATOR gemappt. Richtig ist dieses Zeichen auf BULLET zu mappen. Im o.g. PR ist diese Korrektur ebenfalls enthalten.

In den Fonts müssen nur noch folgende Unicodes hinzugefügt werden:

• BULLET (0x2022)
• µ (0x00b5)
• das kleine pi (0x03c0)

Jirka