From: Daniel Stenberg <daniel_at_haxx.se>
Date: Wed, 11 Sep 2002 08:39:46 +0200 (MET DST)

On Tue, 10 Sep 2002, Greg Haerr wrote:

> OK - I've finally got around to designing and implementing a complete font
> solution for Rockbox.

Uff. *Great work Greg!* Though I would've enjoyed it if you'd told us you
were working on this, it would've saved me from doing the same work in my
end... :-)

Ok, never mind. I know you know this stuff and we will all appreciate your
work. I'll keep my changes as a backup for a while just in case.

> Current design comments:
> 1. The current source is basically a mess. There are zillions of #ifdefs
> for in core fonts, proportional fonts, and loadable fonts, and none are
> compatible. There are no structures, everything's a char *. Usage and
> definitions of the lcd_xxx API differs depending on what's defined, and,
> worse, non-lcd API's have crept into the applications code (ajf_xxx).

The plan has been to move over to one single set of functions. We just needed
the loadable stuff to work firt before we could do that work.

> I can submit a patch that sorts all this out, but it may have ramifications
> to the immediate useability of the CVS tree until folks who wrote original
> applications code make some changes that will be necessary. For instance,
> when any font is allowed, the font height won't always be 8, and there's
> tons of #ifdefs for this crap already. I then need to merge the whole
> LCD_PROPFONTS, LOADABLE_FONTS, and LCD_CHARCELLS madness.

LCD_PROPFONTS and LOADABLE_FONTS should get canned.

HAVE_LCD_CHARCELL is for Player screens.

However, we've already before discussed separating the single lcd.c into two
separate files. like lcd-bitmap.c and lcd-charcell.c. I think it would help
out to make this mess a little less painful.

> 2. I've designed a program to convert any BDF file to either a .c file or a
> loadable font file. When a loadable font is loaded, it's internal
> structure is exactly like that of a compiled-in font. This saves a lot of
> code and makes the system design nice.

Right, this is exactly the same idea I had and was going for in my fixing-up!

> 3. Currently, the entire patch is coded under LCD_PROPFONTS, which allows
> the older original font to run for the time being, as well as the AJF
> loadable fonts. But what we _really_ need to do is move to a single new
> font format.

I'm all for moving into your format in one single *big* step. Then clean-up
the places in the sources that don't deal with it.

> 4. My patch is currently against 1.3, rather than CVS. This may mean
> problems, I wasn't able to get the CVS source. What is the best way we
> should go about all of this?

If you post your patch here to the list, I'll grab it and apply it and make
sure it builds with the latest and greatest.

> : 1. The .ajf file format is totally undocumented. We can't have that.
>
> FIXED. Also, I recommend we move to a .fnt extension, it will be more
> intuitive for users, and people can pass fonts around and know they're
> fonts.

I think that's a better extension name, yes.

> Rewritten. The new design uses a variable width array per character only
> when the font is proportional. There's only a single draw routine, unlike
> the 4 or 5 we've got now. firmware/drivers/lcd.c needs some serious
> cleaning up. I can submit a patch for all of this, if desired.

I think it would be good. Possibly splitting the file in two as mentioned
above.

> Also, I don't yet have full unicode working, since the applications
> themselves don't use unicode. The font routines are ready, though.

Ah, cool. I'm personally a unicode-cluebie, but I guess having the support is
good so that we then can move things over to true unicode.

> Let me know how I should proceed with my patch, and how we will keep
> everything together during the conversion period. Basically, what I'm
> trying to say is that I can submit a patch that seriously solves all major
> issues, but there will be a period when all applications functionality
> needs to be tested.

Personally I think we can have a day or two with a somewhat unstable font
situation until we've cleared all things up. Another option could be to
make a branch in CVS and do the font-cleaning in a separate branch so that
people can still run around with the current way if they really want to.
(Branching causes other problems so I would personally like to avoid it.)

-- 
Daniel "Bagder" Stenberg -- http://rockbox.haxx.se/

Received on 2002-09-11