WebMagick

Quote from nschu

Eine Zeichentabelle GEOS UNICODE wäre hilfreich hat jemand sowas ?

Ja, habe ich, aber leider nicht in schön .

Habe mal die Textdatei angehängt, die ich für unsere Konvertierungsarbeiten mit Rainer benutzt habe. Sieht vielleicht erstmal verwirrend aus, aber für dich wären nur wenige Spalten interessant.

Einige Anmerkungen dazu:

• Ist eine Textdatei im UTF-8-Format.
• Spalte "Quelle": der Hex-Code des Geos-Zeichens
• Spalte "Quelle UTF-8": der Hex-UTF-8-Code des Geos-Zeichens
• Spalte "Z": Darstellung des Zeichens
• Spalte "Beschreibung": Name des Zeichens

Alternativ kannst du auch die Zeichenpalette MacRoman https://de.wikipedia.org/wiki/Macintosh_Roman nutzen. Die bietet auch gleichzeitig eine schöne Übersicht und man kommt schnell an den Hex-Code jedes Zeichens.
Geos hat den Zeichensatz vom Mac fast identisch übernommen. Die Ausnahmen:

• Zeichen DE und DF: sind in Geos y´ und Y´ (die lassen sich hier nicht korrekt eingeben?!), auf dem Mac die Ligaturen fi und fl
• Zeichen F0: in Geos nicht definiert, auf dem Mac der Apfel

Viel Erfolg !

Quote from sebi

Wo sind denn die Zeichen irrtümlich vertauscht? In der Schriftdatei oder im Treiber-Code?

Es wäre ja vermutlich besser, die Schriftdatei korrekt aufzubauen anstatt Korrekturen in den Treiber einzubauen

Die sind aber richtig in den originalen Fonts , und ist eine manuelle Bearbeitung die sehr kompliziert ist und auch noch Fehleranfällig !

Ich werde mal den Font Nimbus Sans anpassen !

Gruss von Nico

Man kann übrigens auch im Quelltext nachschauen, welches Zeichen wo sein soll:

Hier nun der Nimbus Sans überarbeitet mit Fix von Jirka !

Habe nun doch mit Autohint wie vorher gemacht , das sieht besser aus !

Gruss von Nico

Zeichentabelle Geos.

Geos-Zeichensatz.pdf

Gruss von Nico

Das Problem mit den Unterstrichen ist vermutlich eine Regression von diesem Fix: https://github.com/bluewaysw/pcgeos/pull/756

Da hatte ich die HTML-Aufzählungen so geändert, dass die Zahl (oder der Punkt) genau die gleichen Zeichenattribute verwendet wie der Rest des Eintrags. Das ist vermutlich bei Farben, Fettdruck, Schriftart auch ganz sinnvoll, aber vermutlich sollte man Unterstreichungen da abschalten. wenn es andere Browser auch so machen.

Updated fonts PR#915 erstellt.

Gruss von Nico

Liebe Font-Designer,

habt ihr euch bei der Gelegenheit auch mal den Symbol-Font angesehen? Da sind auch diverse Zeichen nicht an der Stelle, wo sie sein sollten! Bei den dreiteiligen Klammern (im Original ganz unten) müsste man noch mal schauen, welche Zeichen zusammengehören.

LG
Rainer

Quote from Rainer

habt ihr euch bei der Gelegenheit auch mal den Symbol-Font angesehen?

Ja, für unsere Exporte hatte ich damals auch Übersetzungstabellen von Symbol PS zu UTF-8 erstellt. War ganz schön fummlig.

Hier die Exportdatei. Nochmal ein Stückchen unübersichtlicher, da etliche Zeichen im Zeichensatz mehrfach vorkommen, das steht dann als Meldung da. Außerdem sind die Zeichen aus dem Ascii-Bereich, die den Ascii-Zeichen entsprechen, nicht aufgeführt (es stehen also nur die Ascii-Ausnahmen drin).

Vielleicht hilft es ja trotzdem.

Alle Zeichen im Font , nur 2 Punkte kann ich nicht lösen.

Gruss von Nico

nschu Sehr cool! Allerdings sind die Zeichen in den letzten drei Zeilen noch eine Position zu weit rechts. Ursache ist das als Punkt dargestellte Zeichen auf Position 0xCA. Dort gehört das auf der Seite liegende U mit dem Unterstrich hin, das jetzt rechts davon ist. Dann rutschen die anderen Zeichen (Hoffentlich) nach.

Ich halte die Kompatibilität der Zeichensätze zu älteren Dokumenten für extrem wichtig. Deswegen bin ich dir wirklich dankbar Nico, dass du dich da so reinhängst! Ich würde es echt blöd finden, wenn ich mir die Arbeit gemacht hätte, eine Formel mit dem Symbol-Font zusetzen und dann meinen Schülern sagen müsste (nur als symbolischen Beispiel) "Stellt euch vor, diese Blume hier ist jetzt ein Pfeil nach rechts".

Unter URW Symbol gehören immer 3 nebeneinander stehende Zeichen zusammen (hier in einem GeoWrite Dokument). Der scheinbar zusätzliche Strich auf 0xEF dient dazu, die geschweiften Klammern zu verlängern.

Die Datei dazu hängt dran.

LG
Rainer

Quote from Rainer

nschu Sehr cool! Allerdings sind die Zeichen in den letzten drei Zeilen noch eine Position zu weit rechts. Ursache ist das als Punkt dargestellte Zeichen auf Position 0xCA. Dort gehört das auf der Seite liegende U mit dem Unterstrich hin, das jetzt rechts davon ist. Dann rutschen die anderen Zeichen (Hoffentlich) nach.

Ich halte die Kompatibilität der Zeichensätze zu älteren Dokumenten für extrem wichtig. Deswegen bin ich dir wirklich dankbar Nico, dass du dich da so reinhängst! Ich würde es echt blöd finden, wenn ich mir die Arbeit gemacht hätte, eine Formel mit dem Symbol-Font zusetzen und dann meinen Schülern sagen müsste (nur als symbolischen Beispiel) "Stellt euch vor, diese Blume hier ist jetzt ein Pfeil nach rechts".

Unter URW Symbol gehören immer 3 nebeneinander stehende Zeichen zusammen (hier in einem GeoWrite Dokument). Der scheinbar zusätzliche Strich auf 0xEF dient dazu, die geschweiften Klammern zu verlängern.

Die Datei dazu hängt dran.

LG
Rainer

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

Den Satz mit C3 und D5 verstehe ich leider nicht.

Würde Rainer beipflichten, daß der Punkt in CA zu viel ist und sich dadurch die Folgezeichen verschieben. Außerdem scheinen noch an anderen Stellen Zeichen zu fehlen.

Wenn ich einfach nur Rainers und deinen Screenshot rein optisch (!) vergleiche, fallen mir diese Unterschiede auf: (Hoffe, ich habe mich bei den Positionen nicht verzählt. Dies sind die Positionen auf deinem Bild.)

• Position 4F: Fehlt eine Art Unterstrich?
• Position B5: die teilweise Unendlichkeit fehlt.
• Position CA: Der Punkt kommt weg.
• Positionen CB bis FF: müßten alle eine Position nach links rücken (da der Punkt in CA wegfällt).
• Position F0 (eig. EF): da fehlt eine Klammer
• Position F6 (eig. F5): da fehlt der untere Teil des Integrals
• Position F7 (eig. F6): da fehlt eine Klammer

Grüße!

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 Jirka!

Die technischen Details sind doch das Spannendste, das Salz in der Suppe, die Kirsche in der Sahne :).

Da hätte ich noch ein paar kleine Fragen:

• Der 16-Bit-Code, in den der Geos-Char-Code gewandelt wird, wäre dann zufällig UTF-16?
• 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?
• 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?

Besten Dank für eventuelle (technische) Antworten

Dieser Punkt CAhex verschiebt die restlichen Zeichen der Punkt ist aber nicht im Program mit dem ich den Font bearbeite :

Das einzige was noch hift ist dieses Zeichen zu versetzen damit die restlichen Zeichen nach vorne rücken.

Klammern klappt:

Gruss von Nico

Quote from sebi

Den Satz mit C3 und D5 verstehe ich leider nicht.

Würde Rainer beipflichten, daß der Punkt in CA zu viel ist und sich dadurch die Folgezeichen verschieben. Außerdem scheinen noch an anderen Stellen Zeichen zu fehlen.

Wenn ich einfach nur Rainers und deinen Screenshot rein optisch (!) vergleiche, fallen mir diese Unterschiede auf: (Hoffe, ich habe mich bei den Positionen nicht verzählt. Dies sind die Positionen auf deinem Bild.)

• Position 4F: Fehlt eine Art Unterstrich?
• Position B5: die teilweise Unendlichkeit fehlt.
• Position CA: Der Punkt kommt weg.
• Positionen CB bis FF: müßten alle eine Position nach links rücken (da der Punkt in CA wegfällt).
• Position F0 (eig. EF): da fehlt eine Klammer
• Position F6 (eig. F5): da fehlt der untere Teil des Integrals
• Position F7 (eig. F6): da fehlt eine Klammer

Grüße!

• Position 4F: Fehlt eine Art Unterstrich? Ist da !
• Position B5: die teilweise Unendlichkeit fehlt. Hinzugefügt !
• Position CA: Der Punkt kommt weg. Nicht möglich !! Nicht im Fonteditor !

• Positionen CB bis FF: müßten alle eine Position nach links rücken (da der Punkt in CA wegfällt)

  Durch das verschieben des Symbols "Seite liegende U mit dem Unterstrich* an freie Position rücken die restlichen Zeichen an die richtige Position.

• Position F0 (eig. EF): da fehlt eine Klammer
• Position F6 (eig. F5): da fehlt der untere Teil des Integrals Korrigiert durch das versetzen !

• Position F7 (eig. F6): da fehlt eine Klammer

  Gruss von Nico

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

Jirka brachte die Lösung des geheimnisvollen Punkts : 00A0 fehlte im Font !

Da hätte ich noch lange suchen können ! UFF Danke !

Ich war echt am Aufgeben !

Gruss von Nico

Schön, daß ihr die fragliche Stelle gefunden habt! Irgendwas mußte ja faul sein.

Aber das interessiert mich jetzt doch mal: Was fehlte da? Auf den Screenshots sah die A-Reihe ja immer vollständig aus, mit dem Punkt auf Position A0.