Daniel, > . The ChrHorizEllipsis and ChrNumericSpace macros return the >correct space and ellipsis chars, but will a 3.1 device display >the incorrect chars for an app that used the horizEllipsisChr and >numericSpaceChr constants in earlier fonts? 1. The horizEllipsisChr character exists in the Latin font (which closely follows Windows code page 1252) at location 0x85, even in 3.1 (and later) roms. The glyph has been mirrored down to 0x18 so that every character encoding (e.g. Shift JIS for Japanese) will have this glyph available, and in the same location. 2. The horizEllipsisChr character does NOT exist at location 0x85 in fonts on a Japanese device. Basically for any device using a non-Latin character encoding, location 0x18 is the only safe character code. 3. The numericSpaceChr character still exists in the Latin font at location 0x80, but its days are numbered. This slot will be used in the future for the Euro character. For better migration, the glyph was left unchanged, but developers should be modifying their code to use 0x19 in the future. > . Using these macros will be difficult, if not impossible, in >resource (PilRC) files. Perhaps it will be possible with some >"TRANSLATION" tricks? 4. Using two resources with different character codes is one solution. > . Does the addition of a WChar data type means that the PalmOS can >support Unicode? 5. Unicode could be supported in the future (the new text-related APIs are encoding-neutral). -- Ken Ken Krugler TransPac Software, Inc. <http://www.transpac.com> +1 650-947-9222 (direct) +1 408-261-7550 (main)
