From: Greg Haerr <greg_at_censoft.com>
Date: Fri, 13 Sep 2002 08:01:49 -0600

: 1. Why is the internal font format using 2 bytes for every horizontal line
: when there is no letters that wide? Wouldn't it make more sense to use a
: format that adjusts to the widest character and uses no more than that?

The 2 bytes per line is from the X11 font standard (.bdf), where the
minimum storage length (MWIMAGEBIT) is an unsigned short. Since
I started using standard font stuff, that limit remained. This is another
item that I can work on getting smaller, but didn't want to at first
since I'm trying to not introduce bugs into the system with
this complex task. (Unfortunately, it seems that there's already
a problem with loading that doesn't occur in the simulator... I think
this may be related to trying to draw off the bottom of the lcd
screen?)

[The original good justification for unsigned short (and unsigned long in
Microsoft fonts/bitmaps) has good justification on most systems, but
not on rockbox: on most systems, it's far quicker to draw bitmaps
using int loads/stores in video memory, so the minimum bitmap
size is moved to 32 bits. That's why images and fonts are padded
to a larger boundary with unused bits. On X11, they compromised,
and moved to a 16-bit pad. On rockbox, it appears that
all bitmaps are essentially rotated, so this doesn't have value (the height
would need padding, except we're not writing to a framebuffer anyway). I
haven't
figured out whether the Jukebox hardware is running in portrait mode,
or the hw just requires it this way...]


:
: 2. The rotate function. Why is that made on init and not on load?

It's made on init because the compiled-in fonts have to be rotated
also. The rotate occurs right after load for loadable fonts.


: Also, I
: think it makes a slightly naive operation when it assumes that the rotated
: bitmap never outgrows the source image size. Of course, the 2-byte thing
: for the previous paragraph helps out here to prevent this from happening
: very often. A single letter that is 14x10 pixels big uses 10*2=20 bytes in
: the .fnt format. But when rotated to rockbox internal bitmap it'll require
: 14*2=28 bytes...

I thought I had this figured out, but you've proved me wrong here.
When width > height and height is just a little over a multiple of 8,
this is going to occur. I use memset with a fixed length of the source
bitmap, so this will just chop some of the character in the current code,
and never crash the system,
but this will have to be rewritten. This means we can't use the original
static space the font file was read into, and increases either
the storage space required or the font algorithm load complexity.

Of course, all this could be done prior to writing the .c or .fnt file,
but (as you will see if you look at bdf2c) it's going to be complicated
and error-prone. I would like to work on this after we get font
loading and display initially working on rockbox.

Regards,

Greg



:
: --
: Daniel "Bagder" Stenberg -- http://rockbox.haxx.se/
:
Received on 2002-09-13