font table format

[NikolaiPrzewalski]

Hallo Oliver, jetzt muss ich leider doch noch einmal nachfragen. (Ärgerlich, wenn man bedenkt, wieiviele Tickets Du am Wochenende weggeschafft hast - aber hier hört mein Verstehen des U8G2-Systems auf.)

Font_Table.zip

Ich habe mit dem bdfconv.exe einen Auszug aus dem Font open_iconic_all_4x.bdf erstellt. Wenn ich mir das Ergebnis anschaue (siehe view -> Output.txt), geht der Sprung des letzten Zeichens mit Unicode < 255 in eine mit Nullen gefüllte Lücke und nicht auf das erste Zeichenmit Unicode >= 255, das erst zwei Bytes später kommt.

Beim Durchsuchen der Glyphen mit u8g2_font_get_glyph_data() fällt das nicht auf, weil für Zeichen >= 255 sowieso direkt eingesprungen wird in start_pos_unicode. Mir ist das Ganze aufgefallen, weil ich eine Funktion schreiben wollte, die alle Zeichen des Fonts hintereinander ausgibt.

Ist das eine Designentscheidung, ein Missverständnis meinerseits oder ein Bug?

Viele Grüße Nicolas

[olikraus]

Ärgerlich, wenn man bedenkt, wieiviele Tickets Du am Wochenende weggeschafft hast

Naja, ich wollte mal wieder ein Release machen... Aber so ist das halt...

Wenn ich mich recht entsinne, war das eine Designentscheidung. Die null-lücke markiert das Ende der nicht-unicode Zeichen. Darüber wird die Such-Schleife verlassen: https://github.com/olikraus/u8g2/blob/master/csrc/u8g2_font.c#L608

[NikolaiPrzewalski]

Wenn man's weiß, kann man es ja berücksichtigen. Danke für die Information! Ich pflege das demnächst in die Font-Doku ein.

[olikraus]

wow, ganz schön fleißig

[NikolaiPrzewalski]

Nur aus Neugier: Wie läßt Du Dir eine Übersicht über den Zeichensatz auf dem Target anzeigen?

[olikraus]

Auf dem Target? Also für u8g2 gibt es ein bitmap target (TGA), das ist einbebaut in die font tool chain: https://github.com/olikraus/u8g2/blob/master/tools/font/build/build.c#L1088

Ausserdem besitzt bdfconv eine option, die das TGA bild erzeugt (das sieht ein bischen anders aus). Es wird dann als bdf.tga abgespeichert (man kann den Namen nicht abändern). Das passiert hier: https://github.com/olikraus/u8g2/blob/master/tools/font/bdfconv/main.c#L430

[olikraus]

Kleines Update: In Version 2.23 (noch nicht released) wird sich das Font Format leicht abändern. Die Doku ist bereits auf dem aktuellen Stand. Ziel war es, den Zugrif auf die Unicode Glyphs zu beschleunigen (issue #596).

[NikolaiPrzewalski]

Meinst Du bei der Adresse ("the above calculated address points to the junp table") die Adresse bei Offset 21+22 zeigt nicht mehr auf das erste Glyph mit Unicode >= 0x0100, sondern auf den neuen Glyph-Table 2 ?

[NikolaiPrzewalski]

Spontan fiele mir ein: Wenn die Adresse bei Offset 21 weiterhin auf den ersten 16-Bit-Glyph zeigte, und im Byte davor der Offset zur Glyph-Offset-Tabelle 2 hinterlegt wäre, wäre das neue Format 100% kompatibel zum Vorgänger. Etwa so:

• letztes 8-Bit-Glyph
• Null-Byte als Marker für Ende des 8-Bit-Bereichs
• Neuer Glyph-Table
• Offset des neuen Glyph-Tables
• Erstes 16-Bit-Glyph

Die alte Library würde einen neuen Font einfach wie bisher durchsuchen. Die neue Library würde in einem alten Font die Sprungmarke vermissen (ist ja ein Null-Byte) und kann dann auch den althergebrachten Weg wählen.

Das benötigte allerdings exakt einen Sprung mehr. Keine Ahnung, inwiefern Rückwärtskompatibilität überhaupt ein Thema ist.

[olikraus]

Nun, es ist schon umgesetzt. Es ist nicht Rückwärtskompatibel. Das macht auch keinen Sinn. Es hätte nur unnötig Code erfordert. Auch die Fonts sind schon alle neu berechnet (wenn man die Version 2.23 und aufwärts verwendet). Und ja, es ist sozusagen eine Tabelle 2 hinzugekommen. Das Ganze befindet sich sozusagen im Beta Stadium und wird gerade hier und dort getestet. Aber es sieht ganz gut aus. Für CJK Anwendungen, ist U8g2 bis zu 20x schneller.

Im Grunde sind aber die Änderungen im Code minimal.

[NikolaiPrzewalski]

Wenn die Arbeit mit dem Neuberechnen aller Fonts schon erledigt ist, ist mein Vorschlag natürlich sinnlos.