From: Tat Tang <tat_tang_at_yahoo.com>
Date: Fri, 21 Mar 2003 05:41:58 -0800 (PST)

Hi Greg,

Good to speak to you!


> > * New font format. Current format is compact in
> > memory, but expensive when reading characters into
> the
> > LRU cache (2 or 3 disk reads, memcpy and a
> rotation).
>
> 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
Rockbox specific.

> The rotation has been discussed before and could
> easily be pre-rotated with a bit set in the .fnt
> header
> file. I would like to make sure the font file
> specifies
> whether the bitmap is rotated so we don't end up
> with
> 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
    read width

    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
code:

    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
calculated.

Adding the CHARSET_REGISTRY is also useful. This
allows
the tree and wps to display Unicode and Big5 strings
at
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
> this
> > > patch, or who are looking
> > > > for Simplified (GB), Japanese or Korean
> versions.
>
> Are you planning on using fixed-size .bdf files for
> this
> 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
description.

UCHAR version[4]
UCHAR name[64]
UCHAR copyright[256]
UCHAR charset[32]
USHORT maxwidth
USHORT height
USHORT ascent
ULONG firstchar
ULONG defaultchar
ULONG size
Repeated structure size times
UCHAR width
MWIMAGEBITS bits

Regards, Tat..

> Regards,
>
> Greg
>
>


__________________________________________________
Do you Yahoo!?
Yahoo! Platinum - Watch CBS' NCAA March Madness, live on your desktop!
http://platinum.yahoo.com
Received on 2003-03-21