Display/Render Unicode Characters?

Are you planning to support them all in a single firmware version? Is ROM space tight? Can you afford to double your string space? What kind of display are you using? Do you need to support kanji or will your users accept kana?

The Roman (including accents and special characters like slashed-0 and beta for German "ss" sound) and Cyrillic alphabets can be represented legibly in a 5x7 matrix. For kana 5x8 is better though I've seen katakana applications on 5x7. Kanji is more challenging, 16x16 is a good size to choose though not necessarily the minimum.

If you're working with a large bitmapped display, you will not want to reinvent this wheel. Use a graphical environment with appropriate rendering software built in. I recommend X, of course :)

I was thinking that it will be a single firmware release for all regions. But if this is not practical then this will have to be reconsidered. At present I do not enough knowledge of what memory space requirements and extra fuctionality that would impose on the design.

I'm not sure what ROM size to allow for.

Do I have to store the full Kanji character set in 16x16 bitmaps for all characters?

I assume that I will have to assume all characters (e.g. Roman/ASCII) shall be 16x16 so that whn I go to Kanji the correct space is available.

We are targeting a fairly large display something in the order of 25cm x 18cm.

Thanks, BM

This is a question of your font renderer. A vector font rendering engine will not use bitmaps at all. If you write your own font renderer, you'll probably use bitmaps. But kanji is not an alphabet, so you're not likely to need the entire character set; you might only need a few dozen characters (plus kana).

Roughly speaking, you should assume western characters are 1/2 the width of Asian characters. So the "correct" thing to do is use 16x16 for kanji and kana and 8x16 for Western text. However if you are displaying romaji in a Japanese environment you should use 16x16 for consistency with other operating systems. In other words your user interface should be designed around 16x16 in Japanese mode and 8x16 in Western mode.

Note: to implement Japanese text you need a minimum of (some number of kanji) + all of hiragana + all of katakana.

So we are talking about a 32-bit processor with lots of RAM and ROM, which means you want to use an operating system (or you really like pain). I suggest Linux and X.

Just for future reference, it's "ess-tzet," not "beta." Alt-0223 (ß, if we're in the same character encoding). The glyph is similar looking, but different from beta. It's actually a digraph, consisting of a long "ess" followed by a short "ess."

If you've looked at old documents, you'll see a character used that looks much like a lower-case 'eff' (f) where you'd expect to see an 'ess' (s). This is the long "ess," and isn't used anymore. If you look at ess-tzet, you'll see it's a digraph of a long 'ess' followed by a short 'ess', with the top of the long 'ess' curving over the top and into the top of the short 'ess'. It's lower-case only, and AIUI, in the process of becoming obsolete, though it certainly hasn't disappeared in the 20-some years since I heard that...

Apologies for the digression. Regards, -=Dave

I knew how to say it, but not how to spell it - since when I was learning German, I always just used the character :) Also called Schafer's S in some references.

The oldest German books I have are from after the First World War (naval handbooks published in the early 1930s), printed in gothic script, and they use the =DF character.

I'm aware of the "f"-looking long 's', but as far as I'm aware the rule is that this character occurs anywhere 's' appears other than the last character of a word. I was under the impression this was a calligraphic thing rather than a pronunciation detail.

It's not in any such process. The Swiss version of German has basically got rid of it a long time ago except in proper names, but there have been no real chances to its usage in standard German that would aim at its extinction.

The only actual change was an attempt to organize a streamlining of orthographic rules that causes it to be used a lot less. It ended up being the most messed-up reform project in the history of the language. It was a good, clean project as long as the experts were running it; then politicians got involved, abused it as a weapon in their usual mud-slinging contents, then even more politicians and that ugly monster called "public opinion" got involved. The end result is utter mayhem.

It's not in any such process. The Swiss version of German has basically got rid of it a long time ago except in proper names, but there have been no real chances to its usage in standard German that would aim at its extinction.

The only actual change was an attempt to organize a streamlining of orthographic rules that causes it to be used a lot less. It ended up being the most messed-up reform project in the history of the language. It was a good, clean project as long as the experts were running it; then politicians got involved, abused it as a weapon in their usual mud-slinging contests, then even more politicians and that ugly monster called "public opinion" got involved. The end result is utter mayhem.

I've seen it spelled many ways. Wikipedia uses ess-tsett

It's really just a phonetic spelling of s-z in German. In English, we'd spell it ess-zee.

Same here, though, looking at the rules on the about.com page, I would guess I often used it incorrectly.

ITYM scharfes S ("sharp s" in German).

Regards, -=Dave

Yes, I apparently understood incorrectly. This was the impression of an outsider. I haven't studied German in many years.

Apologies for the misinformation.

-=Dave

When you say lots of RAM and ROM could you estimate the size?

When you say Linux and X is this your experience lies or is there advantages to be gained with this? What about Windows CE which seems to be keen on internationalization or other embedded OS, QNX Neutrino, VxWorks, Nucleus ....?

Thanks!!

Back on the topic. Does anyone have any practical experience of implementing embedded system for different languages?

It depends on what you need to do! Say 64Mb RAM and 16Mb flash, but you could optimize it smaller or bloat it larger with features.

I pick these because the cost of entry is low, I KNOW this combination does what you need, and there are certain other advantages, such as being able to develop and test the software directly in a desktop environment.

Linux (or FreeBSD, if you prefer) is supported on many more platforms than WinCE; you have a better opportunity to select the hardware that's right for your application.

I'm not sure what GUI options are commonly available with those, but I know that in at least some cases it's X.

Yes. In my personal opinion, the issues are *not* in the display side programming, but really in a) visual design of the system to cope with size differences b) Translation issues - who does it etc.

Stephen

Stephen,

Thanks for the input. I was trying to get a feel for what consideration I would have to place on the board. i.e. flash sizes, ram sizes.

If I have to have the complete bitmap of all Kanji characters as well as other characters bitmaps then this could be a considerable amount of space to allow for on the embedded device. The two points you mentioned are being considered but my concern just now is helping define the electronic requirements.

Thanks

The next set of questions are: display technology required display performance CPU production volume development timescale

In general, Flash is pretty cheap and the use of sparse character tables can save space. If the required display performance is low, you can always use serial Flash.

Stephen