Hi and thank you for your answer, I was hoping to hear from you. I was already thinking about this after examining the Font.c and the private header.
Here is what I think: 1. The fontMap is contracted on the fly. 2. A fake subfont featuring few unused "character codes" is added to the system. 3. On a first run we run a "calibration loop" - set the starting subfont index to 0 and create the master font and the subfont; call CharWidth() for say 3 or 30 (no matter) of the unused chars; on !=expected widths - undefined the two fonts, increase the subfont index; do it again until success. Should take a up to a second to calibrate the font. May even calibrate it on every run if this is fast enough. What do you think about this? I have one more question â is there a decent way to extract all the printable char codes on a Japanese device? To clarify âall the printableâ I mean all the char codes that are in the hierarchical âstdFontâ and need to be in my replacement font for the replacement to be valid? I need to completely replace the font, as to keep the input of the system â if it was for printing only, there would be no FontType involved at all. Please, share your thoughts! Best, Ilia. -- For information on using the Palm Developer Forums, or to unsubscribe, please see http://www.palmos.com/dev/support/forums/
