From: Greg Haerr <greg_at_censoft.com>
Date: Wed, 19 Jun 2002 09:39:42 -0600

: > - is there a way to update the character table set to handle another
: > language (arabic, japan ...) I only need to know how to update the charset
: > . I know that it is defined as an array in chartables.c but is there some
: > tools to make it easier ?
:
: The charsets (they are in three sizes) in chartables.c were donated by Gary
: Czvitkovicz. I don't know what kind of tool he used to create them. If you
: read this Gary, we're eager to know!
:
: The charsets are also a bit limited, as they don't supply any characters
: above 0x7f. I would personally like to see full ISO-8859-1 support... Again,
: we can use some help here!

I looked at this code, and think it needs improvement also. I have ideas
for a shorter-term and longer-term solution. (and code also, hows that!):

1. In the short term, I suggest that we move to more general-purpose
font rendering code. In my Microwindows Project (http://microwindows.org)
I have written all the code to do this, and it's extremely small. Basically,
I've got a BDF->.c file converter, as well as code that will draw the font.
In this case, the chartables.c file can be quickly replaced with a much-more-
readable .c file created from the bdf file converter, which allows looking
at or modifying the characters, as well as adding completely new fonts
quickly. Once the bits are in place, the existing rockbox code can be
used to draw the character.

2. In the longer term, the entire mid-level access to the display could
be replaced, IMHO. This code could easily come from Microwindows,
and would treat the display always as an entirely graphical area, of course
supporting text output. But then Benoit's interesting suggestions could be
easily
implemented, regarding anything multimedia or image-based. For instance,
having a .bmp or .gif file on HD with the same name as a song could easily
be displayed while that song is playing, etc...

I've been meaning to jump in and code all this myself, but the codebase
was moving very very quickly, and I haven't had the time to finish
everything in one night. (also, the current developers are _extremely_
capable...)

If you like, I can either code this up when I get a bit more time, or I
can consult/provide an API and advice on how to get this done quickly.


:
: > - Finally is it possible to display only the file that could be handled
: > (like the actual Archos firmware) mp3 file, directory , and txt file and
: > perhaps bmp readable file.
:
: It is certainly possible to make the software do this. We already have a BMP
: image file viewer, and the other day I kind of started on a text viewer.

We ought to have a better defined lcd_xxx interface, before too much
code gets written for graphical stuff. I realize we're just targeting the
Archos box, but if the lower level changes, a lot of code might have
to be rewritten. A small and better abstracted draw-code API will
pay off in droves here.

In fact, moving to a little-more standard graphical API would allow
all sorts of other games to be easily ported to the rockbox. Then
we might get to a really neat feature: user-loadable programs/extensions that
actually run on the rockbox but aren't linked directly with archos.mod...

Regards,

Greg



:
: > Actually I did found the Actual Archos interface nicer as the RockBox, but
: > I think that will no longer be like it.
:
: The Rockbox UI is indeed a bit crude still, yes. We welcome all contributions
: that improve it, be it code or suggestions on how to proceed.
:
: --
: Daniel Stenberg -- Rocking the box => http://bjorn.haxx.se/rockbox/
:
Received on 2002-06-19