Font header file construction

The Dot Matrix Display (DMD) is a 32x16 array of high-brightness LEDs for visually striking effects. [Product Page]
Post Reply
Brissieboy
Posts: 131
Joined: Fri Sep 20, 2013 7:25 am

Font header file construction

Post by Brissieboy » Thu Oct 10, 2013 2:11 am

I want to produce a custom limited character set font to utilise the full 16 pixel height of the DMD for a particular application. I started by dismantling the existing files to work out how they are constructed and I have a few unresolved questions and observations:
1. What is 'Width' used for? It does not appear to have much relevance to the data in the file (except with a fixed width font).
2. The first 2 bytes in the data are documented as the size of the font data. However these values are nowhere near the actual size of the data.
Examples: in Arial_Black_16.h the size is shown as 0x30 0x86 (12,422 dec) but the data is actually 1,642 bytes long. Is this value actually used anywhere? Correcting the value makes no difference to the sketch size or use of the full character set.
Any ideas just what this is or where it comes from?
3. Is there any documentation available on the construction of these files?
4. There appears to be an error in the data in the comments at the top of these files created by Fontcreator2. The 'Font last char' appears to be a calculated value from the 'Char Index' and 'Char Count' entries in Fontcreator2 but is always appears to be 1 too high.

Brissieboy
Posts: 131
Joined: Fri Sep 20, 2013 7:25 am

Re: Font header file construction

Post by Brissieboy » Thu Oct 10, 2013 3:41 am

And where in the file is the character spacing specified?

angusgr
Freetronics Staff
Freetronics Staff
Posts: 853
Joined: Tue Apr 09, 2013 11:19 pm
Location: Melbourne, Australia
Contact:

Re: Font header file construction

Post by angusgr » Fri Oct 11, 2013 1:31 am

Hi Brissieboy,
Brissieboy wrote:I want to produce a custom limited character set font to utilise the full 16 pixel height of the DMD for a particular application. I started by dismantling the existing files to work out how they are constructed and I have a few unresolved questions and observations:
The Fontcreator2 tool that made the original fonts is unfortunately no longer available. The glcd font-creator tool creates compatible header files: http://www.mikroe.com/glcd-font-creator/

I had to reverse engineer this format a bit for the FTOLED library, and I used a different approach to DMD, so you may get some insight by looking there as well: https://github.com/freetronics/FTOLED/b ... xt.cpp#L12 and the FontHeader struct here: https://github.com/freetronics/FTOLED/b ... LED.h#L413 . I commented fairly heavily as I was figuring out the format as I went!
Brissieboy wrote: 1. What is 'Width' used for? It does not appear to have much relevance to the data in the file (except with a fixed width font).
AFAIK it's only necessary to use it if you have a fixed width font (fixed width is flagged by the size field being set to zero.) Which is pretty odd, why not just set the width field to zero. I can't answer that one, maybe it's a nominal or maximum width on variable width fonts?
2. The first 2 bytes in the data are documented as the size of the font data. However these values are nowhere near the actual size of the data.
Examples: in Arial_Black_16.h the size is shown as 0x30 0x86 (12,422 dec) but the data is actually 1,642 bytes long. Is this value actually used anywhere? Correcting the value makes no difference to the sketch size or use of the full character set.
Any ideas just what this is or where it comes from?
I don't know. It isn't used (apart from testing for zero) in either the DMD nor FTOLED libraries. It's possible they are two 8-bit fields relating to specific lengths (one may be the number of width entries for variable width fonts.)
3. Is there any documentation available on the construction of these files?
Not that I know of, I'm afraid. It may have vanished at the same time as FontCreator2.
4. There appears to be an error in the data in the comments at the top of these files created by Fontcreator2. The 'Font last char' appears to be a calculated value from the 'Char Index' and 'Char Count' entries in Fontcreator2 but is always appears to be 1 too high.
This sounds likely. :)
And where in the file is the character spacing specified?
Not specified. I think both libraries leave a one-column gap between characters (font purists will gasp at the terrible kerning!) In theory you could always add empty columns as part of the bitmap, at the expense of flash space.


In general, my suggestion would be to use glcd font creator if you can. Otherwise take a look at the FTOLED source (along with the DMD source) and feel free to ask more questions if you have any.

- Angus

TheRevva

Re: Font header file construction

Post by TheRevva » Fri Oct 11, 2013 2:58 am

angusgr wrote:[Snipped out stuff]
The Fontcreator2 tool that made the original fonts is unfortunately no longer available.
The glcd font-creator tool creates compatible header files: http://www.mikroe.com/glcd-font-creator/
That's quite a NICE tool!!! Thanks HEAPS for the link 'coz it's going to save me some serious 'number crunching' to develop the huge fonts I'm going to be needing soon. (My font height will be 96 pixels... Gulp!)
While it doesn't 'optimise' the resultant font to eliminate any wasted space at the right of each character, it's easy enough to 'post-process' the resultant 'C' code to achieve this. (i.e. glcd holds the raw bitmap data as a 'fixed size' bit image even if the font is actually a proportional font!)
A simple 'C' program could quickly optimise the resultant byte array generating a usable font.
It's interesting to note that the character width table that precedes that bit image data includes an 'offset pointer' into the byte array to locate where the raw image data begins. (Personally, I think this should be 'built in' to the DMD library as it can save CPU time when trying to display characters towards the end of the font!)
Another alternative would be to leave the image data as 'fixed width' (thereby allowing the system to implicitly calculate where each characters image begins) and revert to a single byte entry in the character width component. (This would be more 'wasteful' of storage space though).

Anyway, thanx again dude!

Brissieboy
Posts: 131
Joined: Fri Sep 20, 2013 7:25 am

Re: Font header file construction

Post by Brissieboy » Fri Oct 11, 2013 4:54 am

Thanks for all the info angusgr.

I suspected that most of the header information was redundant. I was unable to find anywhere that it was used in the library.

I have had a play with GLCD Font Creator, but as far as I can tell it does not correctly handle proportional fonts over 8 pixels high. It could generate the character data, but it does not produce the character size information (the jump table) or the 6 byte header. It only produces a fixed width character set based on the width of the widest character. I can't get it to supply a proportionally spaced set. I think this was made for a specific purpose and is not really intended for general use.
I can do better than that with a simple excel spreadsheet.

TheRevva

Re: Font header file construction

Post by TheRevva » Sun Oct 13, 2013 9:40 am

OK, I've done a little bit more 'background research'.
I still don't have 100% concrete answers for all the questions Brissieboy asked, but I _do_ have some hints that MIGHT be correct. Your guess is as good as mine.

I found a couple of places where the glcd font creator had been used to create fonts and it _appears_ that the initial two bytes that we've been thinking of as a 'font size' is often used as a pointer to the NEXT font in an array of fonts In such 'arrays' of fonts, the first two bytes of each successive font holds a value calculated as the _STARTING_ address of the .font + the length of the current font. (For example, if the first font in the array of fonts had a length of 0x1234 bytes the second font had a length of 0x0711 bytes and the third font had a length of 0x0200 bytes, then the first two bytes in the third font would be 0x1234 + 0x711 + 0x0200 = 0x1945 as that is where the FOURTH font would be placed.) A value of 0x0000 signifies 'end of list'.

Next finding is that there is a java version of a glcd type font creator that looks like it creates the exact format of fonts used within DMD. You can find it at: http://code.google.com/p/glcd-arduino/d ... p&can=2&q=. Obviously, you'll need to have java installed. To run it, unzip the file and run the 'Start.bat'.
It's nowhere NEAR as 'nice to use' as the one angus linked above, but it would save a lot of post creation editting of the font files

The character width specified in the header is likely to be an 'en width' (which is the width of the letter 'n'). Font fanatics / officianados have their own unique jargon including 'en', 'em' etc. I would guess this width is included in the font for other software that needs access to the 'en' width. (NB: The 'en' width specified in the table doesn't include the mandatory 1 pixel 'gap')

Anyway, HTH!

angusgr
Freetronics Staff
Freetronics Staff
Posts: 853
Joined: Tue Apr 09, 2013 11:19 pm
Location: Melbourne, Australia
Contact:

Re: Font header file construction

Post by angusgr » Sun Oct 13, 2013 11:57 pm

TheRevva wrote: Next finding is that there is a java version of a glcd type font creator that looks like it creates the exact format of fonts used within DMD. You can find it at: http://code.google.com/p/glcd-arduino/d ... p&can=2&q=. Obviously, you'll need to have java installed. To run it, unzip the file and run the 'Start.bat'.
It's nowhere NEAR as 'nice to use' as the one angus linked above, but it would save a lot of post creation editting of the font files
Excellent, thanks! I think this may have been the tool I was thinking of but I found the other one first.
TheRevva wrote: The character width specified in the header is likely to be an 'en width' (which is the width of the letter 'n'). Font fanatics / officianados have their own unique jargon including 'en', 'em' etc. I would guess this width is included in the font for other software that needs access to the 'en' width. (NB: The 'en' width specified in the table doesn't include the mandatory 1 pixel 'gap')
Ah, I never knew what 'em' stood for! Thanks.

- Angus

TheRevva

Re: Font header file construction

Post by TheRevva » Tue Oct 15, 2013 7:21 am

angusgr wrote:Ah, I never knew what 'em' stood for! Thanks.
I guess I could have said that 'em' stands for Micro$oft too, but given that I am a far bigger supporter of Linux (specifically Slackware for the past 20 odd years) than either Mickey$oft or Lemon, I tend to use an entirely different bunch of letters to define them <Grins>
(And I would expect those letters would trigger the phpBB profanity alerts if I were to use them here.)

Editted to remove my own _stupid_ anal comments... Face->SLAP!!!
Last edited by TheRevva on Thu Oct 17, 2013 6:49 am, edited 1 time in total.

angusgr
Freetronics Staff
Freetronics Staff
Posts: 853
Joined: Tue Apr 09, 2013 11:19 pm
Location: Melbourne, Australia
Contact:

Re: Font header file construction

Post by angusgr » Wed Oct 16, 2013 9:53 pm

TheRevva wrote: Speaking of phpBB, you're really not supposed to have removed the phpBB copyright message from the footer of the forum pages??? Hehe
I wasn't aware of such a restriction, do you have some more information about it? As far as I know we're free to do anything we want with the output of the phpbb program. The program itself is copyright phpBB and GPL licensed, but the output from the program (ie the web page) isn't. The notes in the page source makes it pretty clear we're using phpBB (which is an excellent mature Free Software forum program, that we're plenty grateful for!) (Here's a thread on the phpBB forum saying much the same thing.)

Post Reply