Description of problem: Using the character map utility and confirming with either the character description provided by charmap or by checking the Unicode books, one can see that incorrect Unicode numbers have been assigned to a few CJK chars. Version-Release number of selected component (if applicable): 2.11-26 (assuming the component of ttfonts-zh_TW is correct) How reproducible: Always Steps to Reproduce: 1. launch gucharmap on a FC2 system with all three (CJK) langs installed 2. Select "Common" (<- why isn't this translated in Japanese locale?) area, scroll down to U+32A4 3. or... just look at this bug description with mozilla on cjk fc2, and compare to a windows/mac box with a complete unicode font installed. Actual results (assuming you're viewing this bug with CJK FC2 Mozilla): "circled high" (U+32A4): 㤠"circled medium" (U+32A5): 㥠"circled low" (U+32A6): 㦠"circled left" (U+32A7): 㧠"circled right" (U+32A8): 㨠Expected results: something similar to U+32A3: 㣠for example: U+32A4: circled é« U+32A5: circled ä¸ U+32A6: circled ä½ U+32A7: circled å·¦ U+32A8: circled å³ Additional info: The glyph at U+32A9 isn't even rendering correctly... it's either missing something in the top left or the "女 radical" is squashed.
typo in Additional Info: s/U+32A9/U+32A8 (ã¨)
argh! yet another typo in Additional Info: s/top left/top right/ (but you know what i mean âº)
I have switched to different CJK font in gucharmap. When I see the wrong glyphs from U+32A4 - U+32A8, i right click the glyph and see the glyph is coming from Kochi Mincho. Assigning to correct component. Fortunately, we should have more chance to fix Kochi* in upstream than any other CJK fonts. Tagoh-san, would you able to contact upstream about it?
ok. I just sent an e-mail about it to the upstream then. I'll wait the response from the upstream. we can modify the font with fontforge say and use it instead of the original one, though.
this problem should be fixed in 1.2-36. please try it again.
I checked with dist-fc3:1.2-36 rebuilt for fc2. It sort-of fixes the problem-- by deleting the glyphs. U+32A4 to U+32A8 are now not mapped to glyphs, and instead produce their Unicode hex numbers. So I guess this can be called fixed, if no glyphs have been made for these codepoints.
ok. closing this bug then. thanks
sorry tagoh, spoke to soon. the new font lacks: U+3000 fullwidth ideographic space you can reproduce this with ja IIIMF by typing "(" or ")", hitting convert twice, and noticing that the candidate window for conversion options includes half-width parenthesis + full width space (where the full width U+3000 is in hex notation.
I couldn't reproduce that problem. my test box has only ttfonts-ja installed, and nothing ~/.fonts.conf and ~/.fonts directory. $ rpm -qa | grep ttfonts ttfonts-ja-1.2-36 actually when I chose U+3000 with Kochi Gothic and Kochi Mincho on gucharmap, it's not in hex notation. plus, when I looked at U+3000 on fontforge, there are an outline font on that. so it's not a bug in ttfonts-ja, I think.
Due to Bug#139798, this changes was just reverted so that I have no time to investigate fontforge right now. repoening.
Fedora Core 2 is now maintained by the Fedora Legacy project for security updates only. If this problem is a security issue, please reopen and reassign to the Fedora Legacy product. If it is not a security issue and hasn't been resolved in the current FC3 updates or in the FC4 test release, reopen and change the version to match.
Bug is present in FC3
This problem is resolved in the next release, with Sazanami fonts. We aren't planning to provide a resolution for this problem. Kochi fonts isn't maintained in upstream anymore and there is no way of fixing this in the open-source way ATM it seems once we tried to fix this but it caused another problem. Backporting Sazanami fonts for the deployed systems is difficult without taking a lot of risks.