Rockbox mail archiveSubject: Re: Re: Different charsets, loadable fonts, unicode ....
Re: Re: Different charsets, loadable fonts, unicode ....
From: Greg Haerr <greg_at_censoft.com>
Date: Sat, 13 Jul 2002 13:24:49 -0700
> 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.
You've got a point. I didn't think that we'd need to support
multiple fonts at runtime, actually - for some reason
I was thinking that the entire system would run using unicode
say, Cyrillic. But you're saying that the system would
run in say, ASCII, and the Cyrillic-tagged ID3 files
would display with a different font.
But this still doesn't change much with regards to a font
format - unless you want to discard the encoding information
in the BDF font, and use a codepage table instead.
> 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.
I definitely think you should use the prebuilt unicode encoding
that's available to us in BDF - it far simplifies other folks
adding their own fonts - just compile any BDF and it
will automatically work, without effort.
> Than you will
> have to map non-unicode font to unicode (unless proper font already
> exists) - I have to research the issue some more.
I completely agree with you here - we definitely don't want
to put multiple fonts into one font, etc, and build new
encoding tables... ;-(
> 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; /* fixed size font name, might differ from
> GH> filename*/
> GH> short maxwidth; /* max width of font*/
> GH> short height; /* max height of font =
> 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.
It's all available - I use this in my own project, Microwindows
> 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.
I have an idea - just reserve the structure locations in
the font, and don't use them for now. What we definitely
don't want to do is to change the font format later -
that's why I'm suggesting these from experience. In
Microwindows, for instance, my internal font format
is the smallest possible, but still with all the information
required to use the font.
If you reserve the locations, I can write code to fill
them in later if we want to use them.
> 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
> So even if id3 tags can be unicode there must be a way to distinguish
> if they are in Unicode or not.
I think you should take this to the list. My references state
explicitly that the ID3 tags are supposed to be 16-bit
unicode. I guess what you're saying is that people are
using Windows software that writes them using codepage
8-bit characters? Geez... this will be complicated.
> 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.
Perhaps staying with codepage then, since you don't
have unicode fonts now will be OK. Where is the
codepage information, is it implicit in the font? How
do you know to add 0xB0 to the index, will this
need to change per font? If so, then the 0xB0
should be in the font file, or we're not really adding
user-changeable font support.
> 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
> It's easy to put this width array but, honestly, I don't see a
> need for it in the scope of the project.
Some people have been asking for variable-width fonts.
> Thanks a lot, I really appreciate your comments.
Received on 2002-07-13