Grafik-Display/TFT Schriftarten ablegen+komprimieren

[Nils S. (kruemeltee)]

Hi,

ich schreibe gerade an etwas, das ich zum Ausgeben von Schrift auf einem 
reinem Grafik-TFT nutzen will.

Soweit klappt das ganz gut, indem ich die ASCII-Tabelle als Bitmap in 
einem Grossen Array ablege und dann in der Ausgabe Bit für Bit entweder 
ein Pixel setze oder nicht.

Eine 8x16px-Tabelle dabei hat nun schon ca. 1,5kb, grössere brauchen 
dann schnell viel mehr.

Bei Kleinbuchstaben und z.B. 5x7-Schriten gibt's viele Nullen am Stück 
und auch sonst sieht man oft Muster in den Werten.

Wie kann man solchen Overhead möglichst geschickt vermeiden?
Ich dachte an Kompression wie z.B. RLE.

Oft sind Zeichen nicht alle Bits breit, also eine oder mehrere vertikale 
Null-Linien entstehen dabei. In den abgelegten Daten kann RLE keine 
Folge von selben Daten darin erkennen und das spräche wieder für 
intelligentere Kompressionen.
Das lohnt aber den Aufwand nicht, denke ich.

[Sascha W. (sascha-w)]

Hallo,

also wenn man erst mal immer nur die für die Zeichen notwendige Anzahl 
an Pixelspalten ablegt kann man schon mal einiges sparen. Das lässt sich 
auch relativ einfach erledigen, in dem man eine zusätzliche Tabelle hat 
in der die Breite der einzelnen Zeichen vermerkt ist. Bei der Ausgabe 
muss man halt ein wenig addieren um die entsprechende Startposition 
auszurechnen.
Der Fontconverter dens hier auch irgendwo im Forum gibt erstellt die 
Daten auch in diesem Format, bietet aber auch die möglichkeit der 
komprimierung - womit ich mich allerdings noch nicht beschäftigt habe.
Bei der Umwandlung von Fonts sollte man aber mal durchschauen, ob für 
die Zeichen die man braucht auch wirklich die volle Zeichenhöhe 
erforderlich ist - oft wird die nur von irgendwelchen exotischen Zeichen 
benötigt.

Echte Komprimierung braucht hat zusätzliche Rechenzeit und Speicher - 
muss man abwegen.

Sascha

[Georg (Gast)]

Sascha Weber schrieb:
> die man braucht auch wirklich die volle Zeichenhöhe
> erforderlich ist - oft wird die nur von irgendwelchen exotischen Zeichen
> benötigt.

Es gibt Fonts mit einem "Shift"-Bit, weil fast alle normalen Zeichen 
entweder eine Unterlänge haben (g) oder eine Oberlänge (h), aber nicht 
beides, daher werden Zeichen mit Unterlänge mit einem Bit gekennzeichnet 
und das Bitmuster um n Zeilen nach unten verschoben. Nur das j macht ein 
problem, aber das kann man auch ohne Unterlänge zeichnen.

Georg

[Nils S. (kruemeltee)]

> Echte Komprimierung braucht hat zusätzliche Rechenzeit und Speicher -
> muss man abwegen.

Naja, RLE ist sehr schnell, statt z.B. 16 Null Bytes in einer 
Pixel-Zeile braucht das nur zwei Bytes (0, 16).

Einfach ein Offset für die Bitposition errechnen, darauf kam ich nicht, 
werd ich das auch mal ausprobieren.