Rockbox mail archiveSubject: Re: Chinese, Japanese, Korean rockbox
Re: Chinese, Japanese, Korean rockbox
From: Tat Tang <tat_tang_at_yahoo.com>
Date: Fri, 21 Mar 2003 05:41:58 -0800 (PST)
Good to speak to you!
> > * New font format. Current format is compact in
> > memory, but expensive when reading characters into
> > LRU cache (2 or 3 disk reads, memcpy and a
> Please keep me posted on your changes with the
> font format.
Will keep you posted!
> My original design was to perform a
> single disk read into memory, but that got thwarted
> when I realized it wouldn't work due to longword
> alignment problems with the SH processor.
I think the problem got solved, the 1.4 release code
adds some padding to the header and does some pointer
fiddling to longword align the offsets. Though perhaps
you mean that as a result, the .fnt format is
> The rotation has been discussed before and could
> easily be pre-rotated with a bit set in the .fnt
> file. I would like to make sure the font file
> whether the bitmap is rotated so we don't end up
> a multitude of slightly different .fnt file formats.
Thanks, found the thread in the archive. Adding a
rotation bit in the header sounds like a good idea.
> Also - what's the issue with the LRU cache, can
> you detail this a bit more?
If the font is too large to fit into the statically
allocated buffer, it is converted into a cache. Each
cache entry stores the character code, width and
bitmap. Loading an entry looks like this:
calculate file pos of width
seek to width file pos
calculate file pos of offset
seek to offset file pos
read image offset
calculate file pos of image
seek to image file pos
read image into temp buf
shuffle byte order of temp buf
rotate bits into cache
This gets performed for every character. If the cache
fills up, this may happen multiple times for the same
character. A different font format allows simpler
calculate file pos of entry
seek to file pos of entry
read entry (width and image)
This font format omits offsets. The width is placed
just before the image, enabling a single read.
Each image is stored in the file as maxwidth * height
(adjusted for rotation) so file positions are easily
Adding the CHARSET_REGISTRY is also useful. This
the tree and wps to display Unicode and Big5 strings
the same time. Of course, this means allowing multiple
fonts (but that is another discussion). The charset
registry might also be useful for autodetecting the
encoding of character streams.
> > > > Are there other people who are interested in
> > > patch, or who are looking
> > > > for Simplified (GB), Japanese or Korean
> Are you planning on using fixed-size .bdf files for
> purpose, or would another type font also work? I've
> shared code with the Microwindows project, and I've
> got there a number of GB2312, Japanese, and Korean
> fonts and formats.
At the moment I'm taking fixed-size Chinese .bdf files
and patching in proportional ascii range characters.
I'm open to suggestions on non-bdf font formats. If
you know of something that is close to what's been
described, then I'd be happy to investigate.
I took a quick look at Microwindows and found some
16x12 fonts, which would be nice to use as I only
have 16x16 fonts.
Putting everything together, here's a preliminary file
Repeated structure size times
Do you Yahoo!?
Yahoo! Platinum - Watch CBS' NCAA March Madness, live on your desktop!
Received on 2003-03-21