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
Seit kurzem steht ein neuer CI-Buid zum Download bereit. Am TTF-Treiber des Pakets hat sich seit meiner letzten Statusmeldung folgendes getan:
- Einige kleine Optimierungen die dazu dienen diverse Code-Ressoucen zu verkleinern.
- Einige kleine (und auch größere) Fehlerbereinigungen.
- Das Beste zu Schluß: Falk hat die Coderesource die vom Bytecodeinterpreter belegt wird in kleinere und für unser GEOS besser 'verdauliche' Resourcen aufgesplittet.
Ich kann das weder in der DosBox Staging noch unter FreeDOS bestätigen.
Hallo,
es ist wieder Zeit für ein paar Neuigkeiten. Seit gestern gibt ist in den CI-Builds eine neue Version des TTF-Treibers enthalten. Was hat sich getan?
So, ich hoffe ich habe jetzt niemanden mit zu vielen technischen Begriffen verwirrt.
JIrka
Im letzten CI-Build hat sich folgendes am TTF-Treiber getan:
Und zum Schluss fällt mir ein dass dieser Text eigentlich in einen anderen Thread gehört....
Jirka
Hallo,
warum soll das Ordnersymbol gespiegelt werden? Die Lasche hat doch die gleiche Ausrichtung wie die Lasche im GeoManager-Fenster?
Jirka
Hallo in die Runde,
ich habe mich etwas mit der Problematik Gonzo und TTF-Treiber beschäftigt. Die bisherigen Analyseergebnisse deuten darauf hin dass die Ursache in der (noch) zu großen Resource die der Bytecodeinterpreter belegt zu suchen ist. Diesbezüglich benötige ich von euch Testunterstützung.
Bitte geht mit der aktuellen GEOS-Distribution folgende Punkte durch:
1) Timeout für den Bildschirmschoner anpassen (ab besten auf 2 Minuten)
2) Falls Gonzo noch nicht installiert ist, bitte installieren und die Dialoge bis zu Registrierung der Dateiformate durch klicken. Im Dialog für die Dateiformate ok klicken, das sorgt für einen Neustart.
3) Gonzo starten. Funktioniert dann noch alles?
4) Warten bis der Bildschirmschoner aktiv wird. Funktioniert das?
5) GEOS wieder aufwecken. Funktioniert dann Gonzo noch?
Ich vermute dass es bei 3) bei vielen zum einfrieren/Programmabbrüchen in GEOS kommt. Dann in der Geos.ini folgende Zeilen einfügen:
[ttfDriver]
bytecodeInterpreterActive=false
Danach Punkt 3) bis 5) wiederholen. Funktioniert das?
Achtung die o.g. Zeilen in der Geos.ini funktionieren nur in der Geos-Distribution ab dem 18.11.2024.
Danke fürs testen.
Jirka
Das ist alles gerade ziemlich blöd. Wir könnten gerade auf golem.de eine Link auf die Seite platzieren (ich bin wegen eines Podcasts zu GEOS angesprochen worden) , aber dazu muss die Seite natürlich clean sein.
Oh, sehr interessant. Erzählst du uns bitte etwas mehr?
