Rockbox mail archive
Subject: Re: Different charsets, loadable fonts, unicode ....
From: Greg Haerr (greg_at_censoft.com)
> I am attaching a patch with my recent works on loadable fonts.
> Eventually, I stopped on following format: 0xBD 0xFC <height> [ char
> len char bitmap]. Format is pretty strict. 0xBD 0xFC is a magic
> (stands for BDF compiled). <height> is one byte (up to 255 which is
> 10 times more than enough). After that exactly 256 char bitmaps each
> preceded by one byte number of bytes in bitmap.
Not bad. But the limit on 256 bitmaps will be a big problem
when trying to support unicode. There's also a couple of
other pieces of info that might be nice to have in the font,
should we ever want to support multiple fonts. Suggested
1. Have both max width and height (bdf bounding box) information
in the file. This allows the system to select a font based on
height/width, if desired. In addition, the ascent (baseline) comes
in extremely handy. I've found the following [minimal] information
to come in very handy:
char fontname; /* fixed size font name, might differ from
short maxwidth; /* max width of font*/
short height; /* max height of font = ascent+descent*/
short ascent; /* ascent (baseline) height*/
short firstchar; /* first character of font*/
short size; /* size of font (# encodings)*/
This stuff could all be in a fixed-size header in the font file.
In this way, it doesn't increase size requirements at runtime,
if not used.
2. Encodings should be handled the same way that
BDF fonts are convered to PCF format, for the X server.
(PCF is a compiled font format for small size).
The BDF encoding array can be stored in the font
file, which maps (from the font firstchar) an array of
unicode-indices to the font glyph index.
In other words, the following additional information should
be in the font header, in order to allow for unicode:
short numglyphs; /* # of glpyhs in font*/
short defaultchar; /* default character*/
short encoding[size]; /* offsets to each glyph per encoded char*/
The variable-sized encoding array could be the last item in
a fixed-size header.
The way that BDF/PCF uses the encoding array is this: if the
font does not define a glyph for the index, then the value
is 0xffff. Otherwise, it is the glyph index. If a request to
display a non-mapped character is made, use
All this may sound complicated, but it isn't much more work
than you've already accomplished, and paves the way for
complete unicode support. Unicode can be easily supported
when reading ID3 tags by merely indexing the encoding
array, and displaying the glyph or default character.
If the index is less than the firstchar, or greater than fontsize,
then the default char is also displayed. No need to
worry about code pages, etc, since ID3 is already
in unicode, and so are the BDF fonts.
3. Finally, if you want variable-width fonts, then you
need one additional array in the header:
char widths[numglyphs]; /* width of each glyph*/
Hope this helps!
> 3. Encoding, unicode....
> One issue that needs to be addressed is encoding. All filenames on
> Archos are unicode while most id3 tags and system messages are not.
> For now I implemented very preliminary hack for filenames that just
> maps all non 0 pages to page 04 (Cyrillic) and does proper adjustment
> for encoding of characters in AJF. Example: Cyrillic letter A maps to
> 0xC0 in non unicode font and to 0x0410 unicode. This simplest thing
> just sees 04 codepage and takes lower byte and adds 0xB0 to it.
> Eventually, it should look at the code page and map it to proper font
> and conversion table.
> So proposed solution would be to define codepage in AJF file and also
> give somehow conversion table. Then in setting one would say that page
> 04 maps to cyrillic.ajf + cyrillic.tbl. And similar for other pages.
> Probably 2 pages in addition to default would be enough.
> And non unicode should map directly to font where position of
> character defines it's encoding.
> One more conversion.
> I don't know about other languages, but Cyrillic has few different
> encodings. For now I just hardcoded conversion table in bdf2ajf but
> eventually it should be externalized. It's not an issue for anybody
> who does not go beyond 0x7F character (which is the case now anyway).
> 4. Finally how to apply patch.
> Unpack ajf_diff.zip to some directory, say, /tmp/ajf_diff.
> Checkout clean code as of 07/11/02:
> mkdir ~/test
> cd ~/test
> cvs co apps firmware tools
> cd /tmp/ajf_diff
> ./apply.sh ~/test
> Now thing is patched.
> Switch to tools and do make.
> then create build dir and configure in it.:
> cd ~/test/tools
> cd ..
> mkdir build
> cd build
> Enter target platform: (defaults to Recorder)
> 1 - Archos Player old LCD
> 2 - Archos Player/Studio new LCD
> 3 - Archos Recorder
> Loadable fonts support? (y|n) [n]
> Build (N)ormal, (D)ebug or (S)imulated version? (N)
> Created Makefile
> Now copy ajbrec.ajz and system.ajf to Jukebox and you are done.
> Notice that system.ajf is 6x10 font, so I did proper height adjustment
> in firmware (it was hardcoded to 8 originally). In general it looks
> Now enjoy and tell me what you think....
> Alex Gitelman
Page was last modified "Jan 10 2012" The Rockbox Crew