From: Alex Gitelman <alex_at_fg-soup.com>
Date: Fri, 12 Jul 2002 20:00:14 -0700

Hi Greg,


>> I am attaching a patch with my recent works on loadable fonts.

GH> Great work!
Thanks


>> Eventually, I stopped on following format: 0xBD 0xFC <height> [ char
>> len char bitmap]. Format is pretty strict. 0xBD 0xFC is a magic
>> (stands for BDF compiled). <height> is one byte (up to 255 which is
>> 10 times more than enough). After that exactly 256 char bitmaps each
>> preceded by one byte number of bytes in bitmap.

GH> Not bad. But the limit on 256 bitmaps will be a big problem
GH> when trying to support unicode.
I agree that it's a limitation. But in reality most people will only
need 2-3 different charsets. My idea was that you map different code
pages to different fonts. (Of course of the same size and family).
So I would end up with something like having system_00.ajf and
system_04.ajf ( for Cyrillic fonts). System at boot up would just
index them.
On the other hand I think that having encoding map in the font and
store all required chars makes
a lot of sense, too. Still the fact is that our large font would most
likely have to be compiled from several different fonts. Than you will
have to map non-unicode font to unicode (unless proper font already
exists) - I have to research the issue some more.




GH> 1. Have both max width and height (bdf bounding box) information
GH> in the file. This allows the system to select a font based on
GH> height/width, if desired. In addition, the ascent (baseline) comes
GH> in extremely handy. I've found the following [minimal] information
GH> to come in very handy:
GH> char fontname[32]; /* fixed size font name, might differ from
GH> filename*/
GH> short maxwidth; /* max width of font*/
GH> short height; /* max height of font = ascent+descent*/
GH> short ascent; /* ascent (baseline) height*/
GH> short firstchar; /* first character of font*/
GH> short size; /* size of font (# encodings)*/

That , probably is worth doing. Some of this info may not be
available, though.

GH> All this may sound complicated,
That's a good point. Honestly, I mostly deal with much
higher level UI and don't really have a deep knowledge in
the area. May be I will get some over time, any suggestions
and comments are welcome.
I also prefer Windows environment, so my X knowledge is dated
few years back when I was in colledge.


GH> then the default char is also displayed. No need to
GH> worry about code pages, etc, since ID3 is already
GH> in unicode, and so are the BDF fonts.

Not to my experience. My original objective was to
display properly my collection of songs. Their id3 tags
are not Unicode - they show properly with non-unicode mapping. Fat is
unicode.
So even if id3 tags can be unicode there must be a way to distinguish
if they are in Unicode or not. Changing id3 tags is not an option.
I am thinking of having non-unicode to unicode map specified in
system preferences.
Also BDF. There are probably already BDF fonts for Cyrillic Unicode
but all what I have is a bunch of fonts in 3 different non-unicode
encoding. I am pretty sure that most other languages outside
of Western European scope would also have similar problems.
Well, I may not know enough.

GH> 3. Finally, if you want variable-width fonts, then you
GH> need one additional array in the header:
GH> char widths[numglyphs]; /* width of each glyph*/

I thought about it, but to support variable widths bunch of changes
to firmware need to be done because most UI tasks are done
through character positions. Which makes sense because
there other devices than recorder with bitmap screen. Lots
of #ifdef statements must be placed all over which complicates the
code.

It's easy to put this width array but, honestly, I don't see a
need for it in the scope of the project.


Thanks a lot, I really appreciate your comments.
Best Regards
Alex
Received on 2002-07-13