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)
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): ã¨
something similar to U+32A3: ã£
U+32A4: circled é«
U+32A5: circled ä¸
U+32A6: circled ä½
U+32A7: circled å·¦
U+32A8: circled å³
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:
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
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
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
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.