Bug ID: JDK-4549043 RFE: Java doesn't display all characters in the windows symbol font.

Versions (Unresolved/Resolved/Fixed)

The Version table provides details related to the release that this issue/RFE will be addressed.

Unresolved : Release in which this issue/RFE will be addressed.
Resolved: Release in which this issue/RFE has been resolved.
Fixed : Release in which this issue/RFE has been fixed. The release containing this fix may be available for download as an Early Access Release or a General Availability Release.

To download the current JDK release, click here.

Other
5.0 tigerFixed

If you start the windows Charmap program on NT/2000/XP and look at the symbol
font it includes some punctuation and mathematical symbols and numerals 0-9 
that aren't visible when you browse the same font using the JDK supplied
Font2DTest. I believe the reason for this may go back to JDK 1.1.x when you
could only use logical fonts like "dialog" and those characters already came
from some other font (ie Arial.ttf). For clients which want to use the symbol
font directly for mathematical purposes it would be useful if the JDK would
display all the characters in that font.

CONVERTED DATA BugTraq+ Release Management Values COMMIT TO FIX: tiger FIXED IN: tiger INTEGRATED IN: tiger tiger-b08

14-06-2004

EVALUATION The mapping table for MS Symbol in cmaps.h doesn't contain all of the characters in the encoding. Can be verified by viewing the fonts in Font2DTest ###@###.### 2001-12-05 ============================ "Symbol.ttf" and "Wingding.ttf" have historically been used as components of all JDK logical composite fonts (dialog etc) and because these fonts could be examined it was possible to create custom mappings which mapped some of the code points in these fonts into unicode code points. This means the fonts do not display anything in the private use area (try viewing wingdings and windings2 and you will see the different treatment) and also do not display all the contents of the font except when viewing "all glyphs". There are a number of options here - stop enumerating all these fonts (wingdings, wingdings2, symbol etc), because symbol encoded fonts in general aren't useful in unicode apps. - Enumerate them all as currently and choose from several more behaviours (a) continute the special treatment of symbol.ttf, wingdings.ttf, such that select code points map into unicode code points (b) map all code points for all fonts in the private use area, as currently happens for all symbol fonts EXCEPT "Symbol.ttf" and "Wingding.ttf" (c) Map their code points into the Latin range, which isn't correct but may be closer to what "end-users" expect because of the behaviour of native apps. (a) is the status quo, but almost any other combination of (a), (b), (c) is plausible. (b) is the simplest, although (a)+(b) is the most compatible. You could even do (a)+(b)+(c) but that seems like a lot for what has not been a very widely requested feature. We don't need the special treatment in 2D/Swing composites, (as the JRE's Lucida already covers all these code points) but its tricky to distinguish that case, so if its continued for one case perhaps its continued for all. Better still might be to get rid of these from all composite fonts, but someone may depend on these code points in AWT apps, and it would almost certainly change the overall font metrics, and some apps seem sensitive to this. ###@###.### 2003-03-17 ============================ We have opted for (B) to be consistent with other symbol encoded fonts. Solicited feedback from users. Changing this seems to be acceptable, ###@###.### 2003-04-28 =============================

28-04-2003