I've written a little Hiragana/Katakana flashcard app and created my own custom kana fonts (from the PD Kana/Kanji fonts used by JWPce, etc). However, I'm looking to add some more functionality and am reworking my character/font processing. I'm a little confused by the Palm (and tools) font support.
Rather than do something arbitrary, I'd like to create a Unicode font that contains the Latin and kana codepoints (maybe adding some kanji later). However, it doesn't look practical to do this as the Palm font format doesn't support sparse fonts (yes, I know it allows for sparse glyphs/images, but the font bitmap and offset tables are dense)
The glyph offset and width tables are dense, but only within a min/max character code range.
and the kana are up at 0x3000 - alot of table entries which could quickly get me to the record size limit (this applies for resources as well as pdbs, doesn't it?)
If you mean resource databases (.prc) versus .pdb record databases, then yes.
Palm OS supports Japanese. How do they deal with the large font issue?
Via a hierarchical font structure, where the top-most font maps a potentially wide (> 255) character code to a sub-font (referenced via an index) and a glyph index.
I don't see any Palm support for aggregating fonts that cover different regions of the codepoint space.
There's no documented support for user-defined hierarchical fonts.
So, the only solution I see right now is creating fonts with an arbitrary dense glyph mapping and have my app convert between UCS2 and that mapping before drawing the chars via WinDrawChars. This is basically how my app works now, anyway. It's just a little annoying that I can't leverage standards more and other apps can't leverage my fonts without explicit support added.
You can easily apply the same approach as Palm OS, where the high (most-significant) byte of the 16-bit UCS-2 character code is used as a font resource ID offset, and the low byte is the glyph index. So all of the Hiragana & Katakana characters would fit into a single sub-font, with a resource ID of <base>+0x30, as these characters are all 0x3041...0x30FE.
Final thing, Pilrc only supports creating font resources with < 256 glyphs and doesn't support codepoints greater than 255 even though the Palm format does.
The Palm format doesn't really support glyph indexes > 255, which is why the hierarchical font format is used for Japanese/Chinese/Korean.
-- Ken -- Ken Krugler TransPac Software, Inc. <http://www.transpac.com> +1 530-470-9200
-- For information on using the Palm Developer Forums, or to unsubscribe, please see http://www.palmos.com/dev/support/forums/
