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
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
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;-)
- 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.
- 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.
- 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
Display MoreLeider 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
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:
Jirka
Ein Übertragen der Zeichen ist nicht notwendig. Die Fonts die der Distribution beiliegen sind für PC/GEOS angepasste Fonts. Diese Anpassungen umfassen je nach Font 2 bis 3 Schritte:
Die originalen Nimbus TrueType Fonts haben die notwendigen Zeichen alle. Diese haben nur den 2. Schritt nicht 'überstanden'. Nico hat sich für uns die Arbeit gemacht für jedes Fontfile die o.g. Schritte durchzuführen. An dieser Stelle vielen Dank dafür.
Der 2. Schritt muss nur noch Korrigiert werden dann ist alles i.o.
Jirka
Die Überprüfung der genannten Probleme hat folgendes ergeben:
Zeichenmapping im TTF-Treiber:
Zeichensatz im Font (Nimbus Sans Regular):
Die anderen Fonts müssen noch geprüft werden.
Alles in allem sind das lösbare Probleme. Danke an den Finder.
Jirka
Hallo,
ich habe mal eine frühere Alpha Version von Ensemble 6 gegen die PC/GEOS Live Demo verglichen.
Frühe Alpha Version mit Nimbus Sans:
Live Demo:
Der Punkt (nicht der Satzpunkt) und das µ ist in der älteren Version vorhanden. Der Unterschied beim Punkt zum Satzpunkt ist nur schwer zu erkennen, er liegt etwas näher dem Zentrum des Kästchen.
Die beiden Striche sind in beiden Fällen vertauscht, ich vermute das liegt am Mapping des GEOS Zeichens auf den Unicode. Das prüfe ich gleich. Auch sieht es so aus als ob das kleine Pi in den Zeichensatz gehört und nicht das große Pi. Das prüfe ich auch.
Hintergrund:
Für PC/GEOS haben wir die Font ein wenig abgespeckt, was einen deutlichen Performancegewinn und einen geringeren Speicherbedarf brachte. Das bedeutet dass diese nur die Zeichen des GEOS-Zeichensatzes enthalten sollen. Offensichtlich wurden in neuere Versionen einige Zeichen entfernt die eigentlich im Font hätte verbleiben müssen. @Nico kannst du hierzu etwas sagen?
Vielleicht ist es ja eine gute Idee die GEOS Zeichen und das Mapping auf die Unicodes zu dokumentieren. Hier habe ich schon mal angefangen die Fonts zu dokumentieren und für weitere Infos ist noch genug Platz: https://github.com/jirkakunze/pcg…ont_overview.md
Einen Issue auf github gibt es ja bereits.
Jirka
Ja, der PDF-Viewer benötigt viel Zuwendung und da das PDF Format quasi ein Standardformat ist, brauchen wir auch unter PC/GEOS einen guten Viewer.
Mir juckt es auch schon in den Fingern. Von PDF internas habe ich aber keine Ahnung.
Jirka
Die Gsol Library liegt im Repository unter Library/Breadbox/Gsol. Auch FontMagick lässt sich ohne Probleme übersetzen und ist unter GEOS 6 lauffähig.
Jirka
Moin zusammen.
Falk möchte ja Marcus' Programm FontMagick in FreeGEOS aufnehmen - ich habe die deutsche Hilfedatei dafür fertig. Testen konnte ich sie nur in BBE 4.13, da FontMagick noch nicht zum Bestand in FreeGEOS gehört. Kopiere ich FontMagick nach FreeGEOS funktioniert es nicht, da angeblich eine Systemdatei fehlt; ich kann aber nicht herausfinden, welche. Vielleicht hat da jemand mehr Möglichkeiten?
Ich habe das Programm in der Version 1.0 vor ewigen Zeiten auf Diskette gekauft. Die Diskette gibt es noch, aber kein Laufwerk...
Es wird wahrscheinlich die Gsol Library sein die FontMagick vermisst, denn alle anderen benötigten Libraries sind bereits Bestandteil der Distribution.
Moin zusammen.
Vor ein paar Wochen hatte ich ja mal geschrieben, das es an der Zeit wäre, eine Dauertestinstallation mit FreeGEOS einzurichten (es sind sogar zwei geworden). Nun, das ist geschehen; ich habe diese Installationen ganz normal verwendet, wie Breadbox Ensemble auch. Mir ist dabei etwas ganz gravierend aufgefallen:
Wenn ich Dokumente bearbeite, die mit diesem oder einem anderen FreeGEOS erstellt wurden, dann funktioniert das ohne Probleme, kein Einfrieren, keine Abstürze, nichts. Wenn ich jedoch ältere Dokumente bearbeiten möchte (Text hinzufügen oder löschen, Formatierung ändern, etc.), die mit Breadbox Ensemble oder sogar noch mit GeoWorks erstellt wurden, dann kann ich diese Dokumente zwar öffnen und ansehen, aber es ist nicht möglich irgendeine Bearbeitung durchzuführen, FreeGEOS bricht dann immer zusammen bzw. es erscheint die Meldung mit "Drücken Sie Taste E" u.s.w.. Kann das irgendjemand nachvollziehen?
Die Installationen haben die Release-Nummern 6.0 0-930 und 6.0 0-974, Auflösung 1600x900 64k Farben, ich verwende DOSEmu2 in Linux Mint 20.3.
Hier gibt es viele potentielle Ursachen. Eine erste Idee wäre wenn das problematische Dokument Fonts nutzt die nicht auf eine entsprechenden TTF Font gemappt sind. Eigentlich sollte dann der Default-Font genutzt werden, dass ist aber ein Bitmap-Font. Mit einem solchen Font gehen bestimmte Manipulationen, die mit Vektorfonts möglich sind, nicht.
Das alles ist aber nur eine Vermutung. Dieses Problem muss zunächst untersucht werden.
Jirka
