> ** FONT: **
> Have a look at http://www.czyborra.com/unifont/.
> UNIFONT is a freeware (GNU) bitmapped font, by Roman Czyborra et al., that
> is well suited for embedded applications.
> All CJK characters in the fonts are 16x16, but the alphabetic characters
> are half sized (8x16).
> The font is distributed as a plain-text file; bitmaps are in a trivial hex
> representation that may be easily transformed in the desired binary
> UNIFONT uses a 1 to 1 character-glyph approach, so it cannot easily
> support complex script with ligatures, context shaping, etc. But if you
> just plan to add support for CJK writing system, that approach should be
> The UNIFONT page also has plenty links to other pan-Unicode font projects.
> ** LIBRARIES: **
> If the problem is just 16-bit string-handling (and file I/O), the solution
> is quite straightforward: the standard C library <wchar.h> should be good
> enough for the task. Nowadays all ANSI-compliant C/C++ compilers should
> include their own implementation.
> If your compiler for embedded apps does not provide this, there are many
> freeware portable implementations around that you could get and recompile
> on your environment (Perhaps I still have my own poor man's implementation
> buried in somewhere in a ZIP file :-).
> However, I guess you also need to *display* text (why would you be asking
> for a font, otherwise?) and this is a less trivial task. Probably, you
> should come up with your own hardware-specific implementation of
> <wchar.h>'s output functions (wprintf(), putwc(), etc.) that fits your
> display devices. In this case you should be prepared to either:
> - introduce severe limitations to your designs, such as giving up the
> support for complex scripts (e.g. Arabic, and Indic scripts);
> - do a very hard work for supporting the whole Unicode range (consider:
> giants like Microsoft, after years of work, don't yet have it right, as
> far as I know).
> Another very different story is if you also need to support keyboard
> *input* of text (but, on embedded controllers, this is quite unlikely).
> For Far-Eastern script, this would mean to implement your own version of
> input functions (wscanf(), getwc(), etc.) than makes uses of
> dictionary-based "input methods" (as, of course, there are much more
> Chinese ideographs than keys on a keyboard).
> ** ALTERNATIVE: **
> There is also a way that you could use Unicode keeping your old byte
> strings. This is using a "transformation format" (the best one being
> UTF-8, that is now an official piece of Unicode itself) to convert Unicode
> characters into multi-byte sequences.
> In this case, you would only have to change your low-level routines that
> draw text on the display devices.
> All the rest of the application remains unchanged and keeps on using the
> good old 8-bit strings and K&R string-handling and I/O libraries
> (printf(), strcpy(), etc.).
> This approach, however, is advisable only if your application does
> "well-behaved" string handling (never truncate stings at an arbitrary
> location, never assume that a byte randomly extracted from a string is a
> valid character, never assume anything about bytes >= 0x80, etc.).
> But if, as I imagine, your application simply retrieves menu captions and
> error messages from a file, and sends them to a display (maybe doing
> occasional strcat()'s or sprintf()'s), this could be the winning approach.
> UTF-8 also has the advantage of keeping ASCII-derived Unicode characters
> (U+0000 to U+007F) unchanged, so that Latin-alphabet part of UTF-8 stings
> remains readable with any old ASCII editor.
> Marco Cimarosti (Italy, EU)
> -----Original Message-----
> From: Magda Danish (Unicode) [SMTP:firstname.lastname@example.org]
> Sent: 1999 September 15, Wednesday 19.14
> To: Unicode List
> Subject: FW: Unicode in Embedded hardware
> -----Original Message-----
> From: email@example.com [mailto:firstname.lastname@example.org]
> Sent: Tuesday, September 14, 1999 11:58 PM
> Subject: Unicode in Embedded hardware
> Dear Sirs,
> We are a Swedish company that develops and manufactures operator terminals
> for industrial automation. To be able to approach the Asian markets, we
> support more character sets. We use microcontrollers with dedicated RTOS,
> and our software is written in C. Our questions to you are:
> - Do you know any companies that sells library functions for f.ex Unicode
> string handling instead of standard 1-byte character string handling ?
> - Where can we find bitmap fonts for Unicode character set that can be
> in embedded environment ? Today, we use 16*16-pixel bitmaps for each
> Thank you in advance,
> Tommy Håkansson
> Beijer Electronics AB
> Box 325
> 201 23 Malmoe
> G&L Beijer Electronics AB Phone: +4640-358600
> Box 325 Fax: +4640-358601
> 201 23 MALMO Sweden WWW: www.beijer.se
This archive was generated by hypermail 2.1.2 : Tue Jul 10 2001 - 17:20:53 EDT