Forum: Mikrocontroller und Digitale Elektronik Wie ist der Font des GLCD Font Creators von apetech aufgebaut?


von C. H. (hedie)


Lesenswert?

Hallo zusammen...

Ich bin derzeit daran, mir eine kleine Lib für ein Nokia6100 Display zu 
erstellen...

Ich kann bereits Texte anzeigen, jedoch habe ich den Font dazu mühsam 
von hand erstellt... Meine Aufbau sieht derzeit so aus

0 0 0 0 0
0 0 0 0 0
0 0 X 0 0
0 X 0 X 0
X 0 0 0 X
X X X X X
X 0 0 0 X
0 0 0 0 0

Man sieht es leider etwas schlecht... Es sollte ein A sein
Die X stehen dabei für eine 1
Oben ist das LSB unten das MSB

Es ist also ein Byte pro Spalte. Und so gebe ich auch meinen Font aus, 
Spaltenweise. Dies Funktioniert einwandfrei... Nur möchte ich nicht 
immer
von hand neue Fonts erstellen müssen.

Also wollte ich den Font Creator verwenden. Doch leider verstehe ich das 
Format nicht richtig... Wie komme ich da an die Daten welche ich 
anzeigen muss? Und wie sind diese Aufgebaut? Falls jemand also eine 
Beschreibung dazu hat, wäre das Klasse :)

Von hier ist der FontCreator 
Beitrag "KS0108 GLCD Routinen"

EDIT -> Aus einem unerklärlichen grund, wird dieser Link: 
mikrocontroller.net/topic/ks0108-glcd-routinen

Zu dem hier
Beitrag "KS0108 GLCD Routinen"

Hier ein Auszug eines Fonts

Danke schonmal
1
/*
2
 *
3
 * new Font
4
 *
5
 * created with FontCreator
6
 * written by F. Maximilian Thiele
7
 *
8
 * http://www.apetech.de/fontCreator
9
 * me@apetech.de
10
 *
11
 * File Name           : verdana_9.c
12
 * Date                : 19.11.2010
13
 * Font size in bytes  : 4662
14
 * Font width          : 10
15
 * Font height         : 10
16
 * Font first char     : 32
17
 * Font last char      : 128
18
 * Font used chars     : 96
19
 *
20
 * The font data are defined as
21
 *
22
 * struct _FONT_ {
23
 *     uint16_t   font_Size_in_Bytes_over_all_included_Size_it_self;
24
 *     uint8_t    font_Width_in_Pixel_for_fixed_drawing;
25
 *     uint8_t    font_Height_in_Pixel_for_all_characters;
26
 *     unit8_t    font_First_Char;
27
 *     uint8_t    font_Char_Count;
28
 *
29
 *     uint8_t    font_Char_Widths[font_Last_Char - font_First_Char +1];
30
 *                  // for each character the separate width in pixels,
31
 *                  // characters < 128 have an implicit virtual right empty row
32
 *
33
 *     uint8_t    font_data[];
34
 *                  // bit field of all characters
35
 */
36
37
#include <inttypes.h>
38
#include <avr/pgmspace.h>
39
40
#ifndef NEW_FONT_H
41
#define NEW_FONT_H
42
43
#define NEW_FONT_WIDTH 10
44
#define NEW_FONT_HEIGHT 10
45
46
static uint8_t new_Font[] PROGMEM = {
47
    0x12, 0x36, // size
48
    0x0A, // width
49
    0x0A, // height
50
    0x20, // first char
51
    0x60, // char count
52
    
53
    // char widths
54
    0x00, 0x01, 0x03, 0x06, 0x05, 0x09, 0x06, 0x01, 0x03, 0x03, 
55
    0x05, 0x07, 0x02, 0x03, 0x01, 0x04, 0x05, 0x05, 0x05, 0x05, 
56
    0x05, 0x05, 0x05, 0x05, 0x05, 0x05, 0x01, 0x02, 0x06, 0x06, 
57
    0x06, 0x04, 0x08, 0x07, 0x05, 0x06, 0x06, 0x04, 0x05, 0x06, 
58
    0x06, 0x03, 0x04, 0x06, 0x05, 0x07, 0x05, 0x07, 0x05, 0x07, 
59
    0x06, 0x05, 0x07, 0x06, 0x07, 0x09, 0x05, 0x07, 0x05, 0x03, 
60
    0x04, 0x03, 0x06, 0x06, 0x02, 0x05, 0x05, 0x04, 0x05, 0x05, 
61
    0x04, 0x05, 0x05, 0x01, 0x02, 0x05, 0x01, 0x09, 0x05, 0x05, 
62
    0x05, 0x05, 0x03, 0x04, 0x04, 0x05, 0x04, 0x05, 0x05, 0x04, 
63
    0x04, 0x05, 0x01, 0x05, 0x06, 0x08, 
64
    
65
    // font data
66
    0xBE, 0x00, // 33
67
    0x07, 0x00, 0x07, 0x00, 0x00, 0x00, // 34
68
    0x20, 0xF8, 0x2E, 0xE8, 0x3E, 0x08, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, // 35
69
    0x88, 0x94, 0xFF, 0xA4, 0x44, 0x00, 0x00, 0xC0, 0x00, 0x00, // 36
70
    0x0C, 0x12, 0x92, 0x6C, 0x10, 0x6C, 0x92, 0x90, 0x60, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, // 37
71
    0x6C, 0x92, 0x92, 0xAC, 0x40, 0xB0, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, // 38
72
    0x07, 0x00, // 39
73
    0xFC, 0x02, 0x01, 0x00, 0x40, 0x80, // 40
74
    0x01, 0x02, 0xFC, 0x80, 0x40, 0x00, // 41

von holger (Gast)


Lesenswert?

Ich versuchs mal;)

>static uint8_t new_Font[] PROGMEM = {
>    0x12, 0x36, // size

size ist die Größe des Fonts, bzw wie viel Speicher belegt der.

>   0x0A, // width

Ignorieren, unten kommt eine Tabelle mit char widths

>    0x0A, // height

Die Höhe des Fonts. 10 Pixel, in der Tabelle unten also zwei
aufeinander folgende Bytes die vertikal gezeichnet werden.

>    0x20, // first char

Der Code des ersten Zeichens hier 0x20 = 32 = Space = Leerzeichen

>    0x60, // char count

Anzahl der Zeichen im Font ab first char.

>    // char widths

Hier beginnt die Tabelle mit den Breiten der Zeichen

>    0x00, 0x01, 0x03, 0x06, 0x05, 0x09, 0x06, 0x01, 0x03, 0x03,

0x00 ist die Breite für das Zeichen mit dem Code 0x20 = 32.
Der Wert ist 0. Es stehen also keine Werte dafür in der Tabelle!
Siehst du dann gleich.

0x01 ist die Breite für das Zeichen mit dem Code 0x21 = 33
0x03 ist die Breite für das Zeichen mit dem Code 0x22 = 34

usw.

>    // font data

Hier beginnen die Pixeldaten für jedes Zeichen

>    0xBE, 0x00, // 33

Das Zeichen mit dem Code 33 = 0x21
Du siehst oben das die Breite 0x01 ist. Also zwei Bytes wenn man
die Höhe berücksichtigt.

>    0x07, 0x00, 0x07, 0x00, 0x00, 0x00, // 34

Das Zeichen mit dem Code 34 = 0x22

Du siehst oben das die Breite 0x03 ist. Also sechs Bytes wenn man
die Höhe berücksichtigt. Die ersten beiden Bytes sind die erste Spalte
des Zeichens. Byte drei und vier die zweite Spalte, Byte fünf und sechs
die dritte Spalte.

von C. H. (hedie)


Lesenswert?

Achsoooooo :)


Vielen Dank :) Deine Beschreibung ist wirklich sehr ausführlich!

Das bedeutet, das die Daten identisch abgelegt sind...
Mit den unterschied, das wenn die zeichen grösser als 8 bit sind also 8 
pixel, ist das nachfolgende byte, einfach die zweite ebene der spalte :)

Hoffe ich habe das so korrekt verstanden :)

ich sehe, das nur so viele Daten wie nötig in der Tabelle vorhanden 
sind.
Zb. bei Leerzeichen steht für die Breite ja 0x00 also 0

Ich gehe davon aus, das ich die Zeichen zuerst nach ihrem Muster in der 
Tabelle ausgebe und danach mit leerem Inhalt auffülle, bis die 
Zeichenbreite erreicht ist, oder?

Oder gebe ich nur soviel aus wie auch in der Tabelle steht (halt das 
minimum) und erzeuge in abhängigkeit vom gewünschen abstand noch 
leerspalten?

(Was sieht besser aus? )

Nach meinem verständniss müsste ich im Algorithmus die erste version 
anwenden. Da ansonsten zb ein Leerzeichen mit einer breite von 0x00 
nicht dargestellt würde. Mit version 2 würden dann bei diesem Font 10 
Leerspalten eingefügt...

von holger (Gast)


Angehängte Dateien:

Lesenswert?

>Ich gehe davon aus, das ich die Zeichen zuerst nach ihrem Muster in der
>Tabelle ausgebe und danach mit leerem Inhalt auffülle, bis die
>Zeichenbreite erreicht ist, oder?

Nein.

>Oder gebe ich nur soviel aus wie auch in der Tabelle steht (halt das
>minimum) und erzeuge in abhängigkeit vom gewünschen abstand noch
>leerspalten?

Ja so machst du das. Im einfachsten Fall fügst du eine Leerspalte ein.
Kannst auch zwei oder drei nehmen. Wie es dir gefällt.

>Nach meinem verständniss müsste ich im Algorithmus die erste version
>anwenden. Da ansonsten zb ein Leerzeichen mit einer breite von 0x00
>nicht dargestellt würde. Mit version 2 würden dann bei diesem Font 10
>Leerspalten eingefügt...

Such mal nach GLCDFontCreator2.1.jar.

Der erzeugt auch für das Leerzeichen Code. Siehe unten.

    // font data
    0x00, 0x00, 0x00, 0x00, 0x00, 0x00, // 32
    0x80, 0x3E, 0x00, 0x00, // 33

Beispiel Font im Anhang.

von C. H. (hedie)


Lesenswert?

holger schrieb:
> Such mal nach GLCDFontCreator2.1.jar.

Vielen Dank für die Antwort...

Google findet leider nichts...

Falls du die Software haben solltest, lade Sie doch bitte wenn möglich 
hoch :)

Gruss

von holger (Gast)


Lesenswert?


von Claudio Hediger (Gast)


Lesenswert?

Vielen Dank :)

von Oliver (Gast)


Lesenswert?

Noch eine Ergänzung: Wenn der Fonthöhe kein vielfaches von 8 ist, so 
sind die Daten im untersten Byte so nach "unten" verschoben, daß keine 
nachfolgenden Nullen auftauchen Ein senkrechter Strich in einem 
11-Bit-Font ist also nicht 0xFF 0xE0, sondern 0xFF 0x0E.

Die lib schiebt das unterste Byte dann entsprechend nach oben.

Oliver

von Claudio Hediger (Gast)


Lesenswert?

Oliver schrieb:
> Noch eine Ergänzung: Wenn der Fonthöhe kein vielfaches von 8 ist, so
> sind die Daten im untersten Byte so nach "unten" verschoben, daß keine
> nachfolgenden Nullen auftauchen Ein senkrechter Strich in einem
> 11-Bit-Font ist also nicht 0xFF 0xE0, sondern 0xFF 0x0E.
>
> Die lib schiebt das unterste Byte dann entsprechend nach oben.
>
> Oliver

Mit der Lib meinst du nehme ich an, das C File zur ausgabe des Fonts und 
nicht den FontCreator oder?

Also das Bedeutet, die Daten Sähen etwa so aus

X
X
X
X
X
X
X
X

0
0
0
0
X
X
X
0

Ist eigentlich bei der Ausgabe des FontCreators das MSB des bytes oben 
oder unten? Ist bei mehrzeiligen fonts (höher als 8) das erste byte in 
der Tabelle das obere oder das untere?

von Karl H. (kbuchegg)


Lesenswert?

Claudio Hediger schrieb:

> oder unten? Ist bei mehrzeiligen fonts (höher als 8) das erste byte in
> der Tabelle das obere oder das untere?

Meine Erfahrung bei solchen Dingen:
Am einfachsten ist es immer, so etwas einfach auszuprobieren.

Lass dir einen Font erzeugen und verfolge für 1 bekanntes Zeichen 
(meinetwegen ein 'A') die Bytes in der Datenstruktur. Du weißt, was 
rauskommen muss und wenn man sich dann die 1 und 0-en einfach aufmalt 
sieht man schnell was Sache ist. Zudem hat man dann die Gewissheit, dass 
man den Aufbau der Struktur verstanden hat, was eine gewisse Sicherheit 
bei der Programmierung gibt.

So ein Detail, wie jetzt dieses hier, probiert man einfach aus, indem 
man einfach eine der beiden Varianten annimmt. Hat man die falsche 
Annahme getroffen, dann sehen die Zeichen 'in sich verdreht' aus. Das 
erkennt dann auch ein Blinder und man dreht dann einfach die Bytes 
entsprechend um.

von Claudio Hediger (Gast)


Lesenswert?

Karl heinz Buchegger schrieb:
> Claudio Hediger schrieb:
>
>> oder unten? Ist bei mehrzeiligen fonts (höher als 8) das erste byte in
>> der Tabelle das obere oder das untere?
>
> Meine Erfahrung bei solchen Dingen:
> Am einfachsten ist es immer, so etwas einfach auszuprobieren.
>
> Lass dir einen Font erzeugen und verfolge für 1 bekanntes Zeichen
> (meinetwegen ein 'A') die Bytes in der Datenstruktur. Du weißt, was
> rauskommen muss und wenn man sich dann die 1 und 0-en einfach aufmalt
> sieht man schnell was Sache ist. Zudem hat man dann die Gewissheit, dass
> man den Aufbau der Struktur verstanden hat, was eine gewisse Sicherheit
> bei der Programmierung gibt.
>
> So ein Deteil, wie jetzt dieses hier, probiert man einfach aus, indem
> man einfach eine der beiden Varianten annimmt. Hat man die falsche
> Annahme getroffen, dann sehen die Zeichen 'in sich verdreht' aus. Das
> erkennt dann auch ein Blinder und man dreht dann einfach die Bytes
> entsprechend um.

Danke :)

Hab ich gemacht... Mir ist die Struktur jetzt klar...

Damit eventuell auch andere Davon Provitieren, werde ich eventuell eine 
kleine Doku schreiben...

von Oliver (Gast)


Lesenswert?

Claudio Hediger schrieb:
> Also das Bedeutet, die Daten Sähen etwa so aus

Nö ;) Fehler meinerseits. Das sieht soe aus:

1
1
1
1
1
1
1
1

0
0
0
0
0
1
1
1

Das ist dann 0xFF 0x07

Oliver

von Claudio Hediger (Gast)


Lesenswert?

Achjaa nochwas...

Bei der Geposteten Version des GLCD Font Creator 2.1

Funktioniert die Export funktion nicht... Habe nur ich das problem?

von Claudio Hediger (Gast)


Angehängte Dateien:

Lesenswert?

Anbei noch meine kleine Doku :)

Bitte melde dich an um einen Beitrag zu schreiben. Anmeldung ist kostenlos und dauert nur eine Minute.
Bestehender Account
Schon ein Account bei Google/GoogleMail? Keine Anmeldung erforderlich!
Mit Google-Account einloggen
Noch kein Account? Hier anmelden.