Display- zusätzliche Schriftarten einkürzen?

Hallöle.
Ich sitz grade an meiner Wetterstation II (nicht transportabel, die soll ihren Job zu Hause tun).
Die hat, anders als die Kleine, ein TFT und ne RTC (in Wirklichkeit ist der ganze Kram, samt weiterem Gebimsel, auf ein Proto-Shield gelötet).

Da die auch nur auf nem UNO läuft, ich aber auch die gerne hübsch hätte, möchte ich wieder Custom-Schriftarten benutzen.
Allerdings fressen die so richtig Speicher... :frowning:
Nun: ich benötige den grössten Teil der Schriftarten überhaupt nicht.
Eigentlich nur die Ziffern...

Hat jemand eine Idee, wie ich die Adafruit-Schriftarten auf das Nötige reduzieren kann?
Einfach bissel was raus löschen wird eher nich funktionieren.... >:(

Rabenauge:
Einfach bissel was raus löschen wird eher nich funktionieren.... >:(

Doch, das geht, habe ich schon gemacht.

Wenn Du konkreter wirst, kann ich versuchen, Dir zu helfen.

Einfach bissel was raus löschen wird eher nich funktionieren....

Das geht. Dann stimmt aber die Zuordnung zu den ASCII Zeichen nicht mehr. Das kann man aber mit einer Funktion dazwischen anpassen. Also wenn du nur '0' - '9' hast machst du -16, so dass '0' so behandelt wird wie normalerweise das Leerzeichen

UTFT hat das für nummerische Zeichensätze praktisch schon eingebaut. Da wird für jeden Zeichensatz der Offset im Font selbst gespeichert. 0x20 für volle Zeichensätze und 0x30 für Zahlen

UTFT ist keine Alternative- ich kann die schlichtweg nicht leiden. :slight_smile:
Ich nehme schon immer die Ada, und dabei wird es auch bleiben. :slight_smile:
Alter Esel, ich weiss.... 8)

Anpassen- hm. Ich verstehe nicht so ganz, wie die Font-Dateien aufgebaut sind.
Es soll schon so laufen, dass ich normale Zahlen, die sich im Programmablauf ergeben, direkt nutzen kann (die Uhrzeit z.B.).
Sonst muss ich ja jedes Zeichen dauernd umrechnen...der Sinn wäre dann verfehlt.

Praktisch würde ich gerne z.B. die Datei FreeMono9pt7b.h so abändern, dass sie eben nur noch Ziffern enthält, und die dann halt als FreeMono9pt7bZ.h speichern-sowas braucht man ja doch öfter mal.
Es geht nicht um Strings!

Aber bitte: macht das nich einfach fertig, ich werd das einige Male machen müssen, und möchte verstehen, wie das geht.

Kürze einfach den Font!

Dann mach eine Funktion dazwischen die dir die ASCII-Codes anpasst. Also von jedem Zeichen 16/0x10 subtrahieren. Braucht nur zwei Funktionen: printNumChar() und printNumStr()

EDIT:
Geht wohl auch mit den Adafruit Fonts direkt wenn man die Metadaten der Fonts anpasst. Siehe unten

Rabenauge:
Aber bitte: macht das nich einfach fertig, ich werd das einige Male machen müssen, und möchte verstehen, wie das geht.

Oh weh, jetzt wird's schwierig. Einen Link hätte ich, aber keine Erklärung.

Ganz grob: In GFXglyph nimmst Du den bitmapOffset des ersten Zeichens, das Du nicht haben möchtest, zählst die Bytes in xyBitmaps und trennst die überflüssigen hinten ab. In GFXfont könnte man eventuell an "0x20, 0x7E, 29" was ändern, ist mir gerade entfallen. "0x30, 0x39, 29"? Die structs in gfxfont.h sind aufschlußreich.

Soweit aus dem Gedächtnis. Wenn Du mehr Hilfe benötigst, schmeiße ich mein Display mal an.

"0x30, 0x39, 29"

Ja. 0x20/0x30 sieht nach dem Offset aus. Dann kann man Post #4 ignorieren und den statt dessen die Daten im Font richtig angeben :slight_smile:

Hm-danke.
Viel von euerem Fachchinesisch hab ich nicht begriffen... :o

Aber kleinere Erfolge gibts: ich hab mal probehalber bei zwei Schriftarten den unteren Teil (die Liste, wo als Kommentare dahinter die Symbole stehn) gekürzt- das funktioniert und bringt auch eine -gewisse- Ersparnis im Speicherbedarf.
Aber vermutlich müsste man den oberen Teil auch noch kürzen, und ich hab keine Ahnung, was da weg kann.

Das ist doch ganz simpel. Schau dir die ASCII Tabelle an. Das erste druckbare Zeichen ist das Leerzeichen auf 0x20. Wenn also ein Zeichensatz damit anfängt hat man 0x20 als Offset. Wenn nun '0' das erste Zeichen ist hat man 0x30.

Man könnte auch mit dem Punkt anfangen. Ist z.B. für ein Datum praktisch. Der liegt zwei Zeichen davor auf 46/0x2E

Rabenauge:
Viel von euerem Fachchinesisch hab ich nicht begriffen... :o

Da Du keine fertige Lösung möchtest, helfen dann wohl nur genaue Fragen :slight_smile:

Okay.
Ich benötige also die Zeichen von 0x20 bis 0x3A- so hab ich den Doppelpunkt (für Uhren recht praktisch) mit dabei.
Soweit klar- aber die Font-Dateien enthalten oben ein grosses -hm- Array?
Darunter ne Tabelle, wo die einzelnen Zeichen auf "magische Weise" wohl definiert werden. :confused:

Diese Tabelle hab ich gekürzt-nachm Doppelpunkt kommt nix mehr.
Das funktioniert so auch (und läuft), aber meiner Meinung nach könnte aus dem grossen, oberen Datenfeld (wasauchimmerdasnuis) auch noch etliches weg- oder?

Wenn man sich mal das anschaut:

Dann stehen im Bitmap Teil die eigentlichen Zeichen. Und der Glyph Teil enthält das:

/* {offset, width, height, advance cursor, x offset, y offset} */

Dann kann man beide Arrays gleich kürzen

In xyBitmaps[] wird definiert, welcher Punkt angemalt wird. Da es sich um einen proportionalen Font handelt, werden unterschiedlich viele Bytes für ein Zeichen benötigt. Damit man weiß, wo die Bitmap eines Zeichens anfängt, benötigt man den bitmapOffset aus xyGlyphs[]. Zusätzlich width, height, xAdvance, xOffset, yOffset, die aber m.E. für das Kürzen keine Relevanz haben.

Beide Felder können reduziert werden.

Die tom_thumb hatte ich nicht in der Mache-bei der ist es alles kommentiert, das stimmt.
Aber die anderen Schrift-Definitionen sehen so aus:

Dort ist oben die Bitmap-Geschichte.

Weiter unten dann die GFXglyph....diese hab ich gekürzt.
Aber woher soll ich wissen, was aus dem oberen Teil weg kann? :roll_eyes:

Rabenauge:
Aber woher soll ich wissen, was aus dem oberen Teil weg kann? :roll_eyes:

Aus dem Offset. Beispiel mit FreeMonoBold12pt7b.h:

Letztes interessantes Zeichen sei ':', dann ist der Offset des nächsten Zeichens ';' 390. In FreeMonoBold12pt7bBitmaps[] müssen also 390 Bytes stehen bleiben. Ob es nun 389, 390 oder auch 391 Bytes sind, weiß ich jetzt nicht, habe ich ausprobiert.

Okay-das klappt.
Ihr seid meine Helden... :slight_smile:

Ich hab jetzt deutlich über 3kb Speicher einsparen können. :slight_smile:

Mal zusammengeschrieben, wie ich vorgegangen bin:

Zuerst habe ich die Glyphen-Liste von hinten bis an das letzte Zeichen gekürzt, was ich behalten wollte (bei mir der Doppelpunkt).
Den habe ich dann aufs Display geschrieben, und das grosse Bitmap-Feld von hinten so lange gekürzt, bis der doppelpunkt nicht mehr ordentlich im Display erschien.
Dann ist zu viel weg, also so lange wieder eingefügt, bis er da ist-fertig.

Mhm- würde das auch von vorne funktionieren?
Also die ersten Blöcke rauswerfen?
Nee oder?
Dann stimmen die Zuordnungen ja nich mehr?

Rabenauge:
Mhm- würde das auch von vorne funktionieren?
Also die ersten Blöcke rauswerfen?

Ja, da reicht dann aber Löschen nicht aus.

Wenn Du bis '+' löschen möchtest, wird der bitmapOffset von '+' gleich Null und von den restlichen Offsets wird der Offset von '+' subtrahiert. Und in Bitmaps[] löscht Du vorne so viele Bytes weg, wie in Offset stehen.