Red Hat Bugzilla – Bug 81717
Japanese text installer fonts is dirty
Last modified: 2013-01-10 16:39:25 EST
From Bugzilla Helper: User-Agent: Mozilla/5.0 (X11; U; Linux i686; ja-JP; rv:1.0.1) Gecko/20020830 Description of problem: Japanese text installer fonts is dirty and far from the market requrements. Version-Release number of selected component (if applicable): How reproducible: Always Steps to Reproduce: 1. Run Text Installer with Japanese mode 2. Oops 3. Additional info: We should use k14 fonts for the installer.
Created attachment 89368 [details] k14ucs.bdf - k14 Unicode font converted from k14 in X.
Created attachment 89369 [details] 7x14ja-RH.bdf.bz2 - result of 'mergebdf 7x14.bdf k14ucs.bdf'
Created attachment 89370 [details] 7x14ja-RH.bgf - bdftobogl -f 7x14ja-RH.bgf
Just merge the attached fonts and it works here with newt sample test program.
Have you tested with Korean and Chinese?
This font is for Japanese only. It's a wrong assumption that all CJK fonts are best to show with same 16 bit size. We should separate J at least for this 14 bit font. Separating CJK for install disk will take effect to reduce disk size.
are all the 14 dot glyphs centered in a 16 dot cell?
14 dot fonts are in 14 dot cell, so might be in 16 dot cell. Alphabets are in 7x14, and Japanese fonts are in 14x14. 7x14 alphabets should be used with 14x14 CJK fonts, and 8x16 alphabets should be used with 16x16 CJK fonts.
fonts are perfectly readable-- just an opinion that one font is better than another (fair enough). Changing severity to enhancement.
The glyph issue is so important that you cannot decide. Users would laugh at our localize level with a glance before install. If you still cannot understand the difference between k14 and the poor font, please never touch any Japanese related issues in the distro. We cannot ship the product with such dirty font, anyway.
Can we merge bdf on 7x14, k14 (JP) with Gulim14 (that needed to be converted to UCS) (KR) so that thoughout the screen we will have 14x14? That will be same as we have currently - we only have ja and kr bdf font in bterm.
see bug 82888; we need coverage for zh_TW and zh_HK. (Strangely enough, coverage for simplified GB2312 seems to be present)-- so we would need a 14x14 big5-charset-based unicode bdf font as well.
OK. I have merged the font merged from 7x14 + k14 + gulim14 (converted from euc-kr to UCS2) + bsmi00lp (generated from ttf) + gbsn00lp (generated from ttf). By tested it bterm with anaconda, I could not "really" tell the different glyphs from different font file in TC and SC. AFAIS, there aren't any missing glyphs anymore from TC. We need to test again from installing env though. havill, msw, nakai, please have a spin on it.
Created attachment 90023 [details] CJK test font - 1
In our case which we have limited resources on bdf & ttf to use, IMO we only have three ways: - leave as it is. ie. use ucs-fonts-asian - use ZYSong18030 to generate a whole set of bdf from ttf2bdf - use 14x14 fonts which has two nice bdfs - k14 and gulim14 and then make up other glyphs from TTFs I will choose the 3rd option - korean and japanese text display are pretty nice afterward.
Comment #16 font works and all kanji glyphs are for Japanese. cat ja.po in anaconda and I've read all.
can you add the bdf sources you used to make that last bgf font to this bug? (and give me the order you used for mergebdf) thanks.
Created attachment 90075 [details] 14x14cjk.bdf.bz2
I use this command: ./mergebdf 7x14.bdf k14ucs.bdf gulim14-ucs.bdf bsmi00lp.bdf gbsn00lp.bdf > 14x14cjk.bdf Also we may include the possible license into the package. Baekmuk Gulim: /usr/share/doc/ttfonts-ko-1.0.11/ttfonts-ko/COPYRIGHT AR PL Mingti2L Big5 and AR PL SungtiL GB: /usr/share/doc/ttfonts-zh_TW-2.11/doc/arphicpl.txt
fix in latest bogl