# GLCD Font Structure

Can anybody tell me, how to calculate the //size-value in the upper font data section of a GLCD font?

A sample font coming with the GLCD library has the following structure:

#ifndef VERDANA24_H
#define VERDANA24_H

#define VERDANA24_WIDTH 10
#define VERDANA24_HEIGHT 24

static uint8_t Verdana24 PROGMEM = {
0x0E, 0xF9, // size <-------------------------------- how is this calculated?
0x0A, // width
0x18, // height
0x30, // first char
0x0B, // char count

// char widths
0x10, 0x0D, 0x0F, 0x0F, 0x11, 0x0F, 0x10, 0x10, 0x10, 0x10,
0x04,

// font data
0x80, 0xF0, 0xFC, 0x7E, 0x0E, 0x0F, 0x07, 0x07, 0x07, 0x07, 0x0F, 0x1E,
0x7E, 0xFC, 0xF0, 0x80, 0xFF, 0xFF, 0xFF, 0x00, 0x00, 0x00, 0x00, 0x00,
0x00, 0x00, 0x00, 0x00, 0x00, 0xFF, 0xFF, 0xFF, 0x01, 0x0F, 0x3F, 0x7E,
0x70, 0xF0, 0xE0, 0xE0, 0xE0, 0xE0, 0xF0, 0x70, 0x7E, 0x3F, 0x0F, 0x01, //48

0x38, 0x38, 0x38, 0x38, 0x3C, 0xFF, 0xFF, 0xFF, 0x00, 0x00, 0x00, 0x00, …, … (380 more bytes following)
}

How are the first two bytes “//size” calculated?

hanshuckebein

Size will be 0x0EF9 i.e. 3833 bytes.

Since you have a 24 pixel height, you need 3 bytes per pixel width.
So the first character in your font is the digit zero 0x30 with width=16 and total 48 bytes.

The font has only got 11 characters. So I would expect about 600 bytes for the header, width table, bitmap table.

I would guess that someone has cut down a regular font to just leave the 10 digits plus a colon.
And forgotten to adjust the size properly.

There is no "standard" for anything. I suspect that the "size" is not used or is an inappropriate name.

David.

hanshuckebein,
It looks like you are looking at a font file for the GLCD v3 library.
That library is quite old, has many issues, and is no longer maintaned.
I would recommend moving to openGLCD or some other library that is being maintained.

In terms of format. That format comes from Thiele's original glcd library and his fontCreator tool.
That field originally was supposed to be the size of the font data in bytes stored as a big endian value.
However, the code in glcdFontCreator has a bug and miscalculates it, so the value is pretty much meaningless other than there are some magic values for that field that GLCD v3 and openGLCD use to determine font data types and rendering styles.

So the field is actually being used for something other than a font data size in the code.
The library supports two types of fonts. Fixed width and variable width.
That field determines the type of font data that follows. (each type of font uses a different data format)
If both bytes are 0 (zero) then the font is fixed width, if not, then it is variable.

But like I said the GLCD v3 library is no longer maintained, (has been for nearly 5 years) and has many issues including not working with many current Arduino boards and IDEs.

openGLCD has slightly expanded that format and here is a comment from the openGLCD text header file that explains its usage in openGLCD:

``````//
// FONT_LENGTH is a 16 bit Big Endian length field.
// Unfortunately, FontCreator2 screwed up the value it put in the field
// so it is pretty much meaningless. However it still is used to indicate
// some special things.
// 00 00 (fixed width font with 1 padding pixel on right and below)
// 00 01 (fixed width font with no padding pixels)

// any other value means variable width font in FontCreator2 (thiele) format with pixel padding
``````

Although I wrote the rendering code that is in the latest GLCD v3 library and that is in the openGLCD library, I am no fan of this font format. It messy and in fact Theile's GLCDfontcreator had a bug in it that created incorrect bytes when fonts were not exact multiples of 8 bits in height that makes the rendering code very messy and complicated since it has to work around this.
Michael and I had a long discussion about fixing/correcting this when GLCD v3 was created, and even though we knew the issue and had the code to fix it, we made the painful decision to leave the bug in GLCDFontCreator, and hence the "broken" font data format, to maintain backward comparability with the older ks0108 library and any user created fonts.
In retrospect, it probably would have been better to fix it at that point in time.

openGLCD has pulled forward this font format for compability with GLCD v3 and ks0108 library fonts.

At some point, I plan to dump this font format and move to something that is better that will also make the rendering code and bit simpler and more efficient as well as support multiple font formats.

--- bill