Peter: Please file bugs on both issues.
There are a few characters we special case when converting to glyphs - tab, cr, lf are it in the ASCII range, and we also filter bidi control characters and some other formatting characters. Everything else goes through the regular font CMAP, and if the font maps it, most of the time it will provide the missing glyph for these characters. If the font doesn't map the character at all, we use the missing glyph. The missing glyph typically looks like an empty rectangle. Currently the characters we map ourselves are the following. 0x0009, 0x000A, 0x000D, 0x200C, 0x200D, 0x200E, 0x200F, 0x2028, 0x2029, 0x202A, 0x202B, 0x202C, 0x202D, 0x202E, 0x206A, 0x206B, 0x206C, 0x206D, 0x206E, 0x206F You'll note we don't currently handle ZERO WIDTH SPACE (U+200B)... This is an implementation detail, of course, and some vendors (Apple, in particular) probably do something different. This is just FYI. Doug Peter B. West wrote:
Doug, I'm about to file an RFE for the SHY handling. Should I bug the ZWSP handling while I'm at it? On a related issue, I found when I was trying to get around the ZWSP issue that the fonts that gave me a box for ZWSP gave me the same thing for a NULL. Is there an expected behaviour for NULL? I'm trying to provide a hyphenator that is compatible with Java2D's text processing, hence the interest in these behaviours. Peter
=========================================================================== To unsubscribe, send email to [EMAIL PROTECTED] and include in the body of the message "signoff JAVA2D-INTEREST". For general help, send email to [EMAIL PROTECTED] and include in the body of the message "help".
