C Font Array

Janiiix3

Aktives Mitglied
28 Sep 2013
1.291
10
38
Hannover
Sprachen
C, C#
Zuletzt bearbeitet:

LotadaC

Sehr aktives Mitglied
22 Jan 2009
3.088
57
48
Hennigsdorf
Sprachen
BascomAVR, Assembler
Ist das für jedes einzelne Zeichen gedacht?
Was meinst Du mit "das"?
Bei "char widths" beginnt 'ne Tabelle, die (oh welch Überraschung) für alle Zeichen die jeweilige Pixelbreite auflistet. Also die Anzahl Words, aus denen sich das jeweilige Zeichen zusammensetzt.
Bei "font data" beginnt die Tabelle, die (oh welch Überraschung" die eigentlichen Pixeldaten enthält. Der Font ist 14 Pixel hoch, deswegen zwei Byte (ein word) pro Spalte.
Zitat aus Deinem Link:
uint8_t font_Char_Widths[font_Last_Char - font_First_Char +1];
// for each character the separate width in pixels,
// characters < 128 have an implicit virtual right empty row

uint8_t font_data[];
// bit field of all characters
 

Janiiix3

Aktives Mitglied
28 Sep 2013
1.291
10
38
Hannover
Sprachen
C, C#
Okay.

Wenn Ich jetzt das Zeichen..


CodeBox C und C++
0xFC, 0x02, 0x02, 0x02, 0x02, 0xFC, 0x0C, 0x10, 0x10, 0x10, 0x10, 0x0C, // 48


Darstellen möchte, wo steht jetzt die Breite? Wenn Ich mich nicht verzählt habe, müsste die Breite 4 Bytes sein?

Sehe Ich das richtig, dass die Tabelle nicht der ASCII Tabelle folgt?
Das heißt Ich müsste die einzelnen Zeichen raus rechnen? Oder gibt es eine bessere Möglichkeit`?
 

LotadaC

Sehr aktives Mitglied
22 Jan 2009
3.088
57
48
Hennigsdorf
Sprachen
BascomAVR, Assembler
Wenn Ich jetzt das Zeichen..48..Darstellen möchte, wo steht jetzt die Breite?
Logischerweise in der "char widths"-Tabelle.
// char widths
0x00, 0x01, 0x03, 0x08, 0x07, 0x0A, 0x08, 0x01, 0x03, 0x03,
0x05, 0x07, 0x01, 0x04, 0x01, 0x04, 0x06, 0x03, 0x06, 0x06,
0x07, 0x06, 0x06, 0x06, 0x06, 0x06, 0x01, 0x01, 0x06, 0x06,
0x06, 0x06, 0x0D, 0x09, 0x07, 0x08, 0x08, 0x07, 0x07, 0x09,
0x07, 0x01, 0x05, 0x08, 0x07, 0x09, 0x07, 0x09, 0x07, 0x09,
0x08, 0x07, 0x07, 0x07, 0x09, 0x0D, 0x08, 0x09, 0x08, 0x02,
0x04, 0x02, 0x05, 0x08, 0x02, 0x06, 0x06, 0x05, 0x06, 0x06,
0x04, 0x06, 0x06, 0x01, 0x02, 0x06, 0x01, 0x09, 0x06, 0x06,
0x06, 0x06, 0x04, 0x05, 0x04, 0x06, 0x07, 0x09, 0x06, 0x07,
0x06, 0x03, 0x01, 0x03, 0x07, 0x07,
Wenn Ich mich nicht verzählt habe, müsste die Breite 4 Bytes sein?
Nö, sechs...
0xFC, 0x02, 0x02, 0x02, 0x02, 0xFC, 0x0C, 0x10, 0x10, 0x10, 0x10, 0x0C, // 48
Sehe Ich das richtig, dass die Tabelle nicht der ASCII Tabelle folgt?
Klar folgt das der ASCII - beginnend mit Nummer 32="". Nummer 33="!" usw.
Rechnen mußt Du aber trotzdem jedesmal, da es sich um einen Font mit variabler Zeichenbreite handelt. Du kannst also nicht Zeichenbreite mal (ASCIInummer-Startindex) rechnen, sondern mußt die einzelnen Breiten aller Nummern bis dahin aufaddieren.
Oder gibt es eine bessere Möglichkeit`?
Was'n für Dich "besser"?
Man könnte statt der "Zeichenbreiten-Tabelle" auch 'ne Tabelle einführen, die auf den Start der tatsächlichen Zeichen im Speicher zeigt. Dort müßte dann auch die Anzahl der Bytes/Words für dieses Zeichen erscheinen (oder ein bestimmtes Charakter-Ende-Byte).
Diese Variante würde einen schnelleren Zugriff auf die Pixeldaten erlauben - aber eben mehr Speicher kosten.
Variante drei könnte die Pixeldaten generell als fixed width font (bemessen am breitesten Zeichen) im Speicher parken (jedes Zeichen linksbündig), und beim Zugriff dann komplette Leerspalten (oder meinetwegen mindestens doppelte Leerspalten) als Charakter-Ende interpretieren lassen. Der Zugriff wäre etwa genauso schnell wie bei fixed width Fonts, aber kostet eben auch ordentlich Speicher.
 
Zuletzt bearbeitet:

LotadaC

Sehr aktives Mitglied
22 Jan 2009
3.088
57
48
Hennigsdorf
Sprachen
BascomAVR, Assembler
Es sind nicht vier Bytes, sondern:
  • erstens Words (weil der Font dort 14 Pixel hoch ist, und somit jede Spalte mit zwei Bytes = einem Word codiert wird)
  • zweitens sind es sechs Spalten (also sechs Words) nämlich 0xFC02, 0x0202, 0x02FC, 0x0C10, 0x1010 und 0x100C
Genau diese sechs steht in der genannten Tabelle
 

LotadaC

Sehr aktives Mitglied
22 Jan 2009
3.088
57
48
Hennigsdorf
Sprachen
BascomAVR, Assembler
Kleine Korrektur zu Struktur der Pixeldaten.
Am Beispiel des Zeichens 48 has Du wie gesagt sechs Spalten, je zwei Byte. die zwölf Bytes sind:
0xFC, 0x02, 0x02, 0x02, 0x02, 0xFC, 0x0C, 0x10, 0x10, 0x10, 0x10, 0x0C
Die erste Hälfte (die ersten sechs Byte) bilden den oberen Teil des Zeichens, das LSB ist oben.
Die zweite Hälfte bildet den unteren Rest, auch hier von oben nach unten - allerdings mit zwei "Leerzeilen" dazwischen (da eben nur 14pt und nicht 16pt-Font).
0xFC02020202FC
Code:
°°°°°°
°1111°
1°°°°1
1°°°°1
1°°°°1
1°°°°1
1°°°°1
1°°°°1
0x0C101010100C
Code:
°°°°°°
°°°°°°
1°°°°1
°1111°
°°°°°°
°°°°°°
°°°°°°
 
Zuletzt bearbeitet:

Janiiix3

Aktives Mitglied
28 Sep 2013
1.291
10
38
Hannover
Sprachen
C, C#
Wozu sind dann diese ersten beiden Bytes?


CodeBox C und C++
// char widths
0x00, 0x01..


@Dirk
Wieso klappt das farbige hinterlegen hier nicht?
 
Zuletzt bearbeitet:

Dirk

Administrator
Teammitglied
28 Jan 2007
4.225
123
63
Mittelhessen, Giessen
Sprachen
C, Assembler, Pascal, C++, PHP, Java
@Dirk
Wieso klappt das farbige hinterlegen hier nicht?
In der Code-Box werden Textformatierungen grundsätzlich als Code angezeigt. Ich hatte dies schon einmal erwähnt, da du öfter mal formatierten Text postet, was sich aber dann schlecht lesen lässt.
 

Janiiix3

Aktives Mitglied
28 Sep 2013
1.291
10
38
Hannover
Sprachen
C, C#
In der Code-Box werden Textformatierungen grundsätzlich als Code angezeigt. Ich hatte dies schon einmal erwähnt, da du öfter mal formatierten Text postet, was sich aber dann schlecht lesen lässt.
Formatiert? Ich habe da überhaupt nichts formatiert. Habe diesen Text aus dem Editor raus kopiert und hier eingefügt.
 

Dirk

Administrator
Teammitglied
28 Jan 2007
4.225
123
63
Mittelhessen, Giessen
Sprachen
C, Assembler, Pascal, C++, PHP, Java
Jan im Beitrag 8 hast du es gerade wieder gelöscht.

Und ggf. kopierst du auch Textformatierungen über die Zwischenablage in den Editor.
 

LotadaC

Sehr aktives Mitglied
22 Jan 2009
3.088
57
48
Hennigsdorf
Sprachen
BascomAVR, Assembler
Wozu sind dann diese ersten beiden Bytes?
Jedes Byte in der width-Tabelle legt die Pixelbreite eines Chars fest. Ein Char kann also maximal 255 Pixel breit werden. Dein Font beginnt mit ASCII(32) und endet mit ASCII(128). Das steht doch alles im, von Dir selbst verlinkten Listing.
Das erste Byte ist die Breite von ASCII(32).
Das zweite ist die Breite von ASCII(33).
Das Dritte ist die Breite...
Das erste ist das Leerzeichen, Breite=0, deswegen auch keine Pixeldaten in der Font-Tabelle.
Es wird eigentlich gar nichts gezeichnet, ABER wegen
characters < 128 have an implicit virtual right empty row
erscheint eben doch ein Leerzeichen.
Das Zweite Byte in der Width-Tabelle ist die Breite von ASCII(33). Ein Pixel breit. Das Ausrufungszeichen. In der Font-Tabelle gelten also die ersten beiden Bytes (nach dem Leerzeichen, was ja leer war), also 0xFE und 0x14.
Für das Ausrufungszeichen ist also auf die Basisadresse der Tabelle die breite aller vorherigen ASCIIs (das Leerzeichen=0) zu addieren, ab dieser Adresse sind ein (=Breite des "!" nach der Tabelle) mal zwei Bytes auszulesen.
 

Janiiix3

Aktives Mitglied
28 Sep 2013
1.291
10
38
Hannover
Sprachen
C, C#
Und nun müsste Ich noch eine Funktion schreiben die mir die "Startadressen" raus rechnet sehe ich das richtig?
 

LotadaC

Sehr aktives Mitglied
22 Jan 2009
3.088
57
48
Hennigsdorf
Sprachen
BascomAVR, Assembler
Jain...

Ich würde eher davon ausgehen, daß es eine entsprechende Bibliothek bereits gibt, und daß diese auf genau so strukturierte Font-Daten zugreift. (Also entsprechende Zugriffsfunktionen in der Bibliothek implementiert sind)
 

Janiiix3

Aktives Mitglied
28 Sep 2013
1.291
10
38
Hannover
Sprachen
C, C#
Habe es endlich geschafft und verstanden wie dieses Array aufgebaut ist. Wenn man erst mal den Bogen raus hat, ist es eine wirklich schöne Sache mit diesem "Font Array"
Vorallem kann man damit ruck zuck und ohne großen Aufwand andere Fonts einbinden.
 

LotadaC

Sehr aktives Mitglied
22 Jan 2009
3.088
57
48
Hennigsdorf
Sprachen
BascomAVR, Assembler
Vorallem kann man damit ruck zuck und ohne großen Aufwand andere Fonts einbinden
???
Andersrum.. das ist ein Font, der eingebunden werden kann. Genau das ist ja der Sinn des Codes.
Es gibt irgendwo eine Bibliothek (in C oder Arduinesisch (möglicherweise sogar in der IDE selbst enthalten)), die solche inkludierten Fontdaten vererbeiten kann/erwartet.
created with FontCreator
...läßt ferner vermuten, daß es einen Code-Generator gibt, der diese Daten automatisch erzeugt hat. Im Idealfall kann er fertige Fonts importieren (zB vom Betriebssystem) und umwandeln.

Sowas in der Art zum Beispiel...
 

Über uns

  • Makerconnect ist ein Forum, welches wir ausschließlich für einen Gedankenaustausch und als Diskussionsplattform für Interessierte bereitstellen, welche sich privat, durch das Studium oder beruflich mit Mikrocontroller- und Kleinstrechnersystemen beschäftigen wollen oder müssen ;-)
  • Dirk
  • Du bist noch kein Mitglied in unserer freundlichen Community? Werde Teil von uns und registriere dich in unserem Forum.
  •  Registriere dich

User Menu

 Kaffeezeit

  • Wir arbeiten hart daran sicherzustellen, dass unser Forum permanent online und schnell erreichbar ist, unsere Forensoftware auf dem aktuellsten Stand ist und der Server regelmäßig gewartet wird. Auch die Themen Datensicherheit und Datenschutz sind uns wichtig und hier sind wir auch ständig aktiv. Alles in allem, sorgen wir uns darum, dass alles Drumherum stimmt :-)

    Dir gefällt das Forum und unsere Arbeit und du möchtest uns unterstützen? Unterstütze uns durch deine Premium-Mitgliedschaft!
    Wir freuen uns auch über eine Spende für unsere Kaffeekasse :-)
    Vielen Dank! :ciao:


     Spende uns! (Paypal)