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.
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
Gast
#4116025
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
> 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.