Bug 50145 - Japanese letters on title-bar are mojibake-ed
Japanese letters on title-bar are mojibake-ed
Status: CLOSED RAWHIDE
Product: Red Hat Linux
Classification: Retired
Component: XFree86 (Show other bugs)
7.3
i386 Linux
high Severity high
: ---
: ---
Assigned To: Satoru SATOH
Aaron Brown
:
Depends On:
Blocks:
  Show dependency treegraph
 
Reported: 2001-07-27 04:53 EDT by Bill Huang
Modified: 2013-01-10 16:36 EST (History)
5 users (show)

See Also:
Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Environment:
Last Closed: 2001-11-05 08:22:02 EST
Type: ---
Regression: ---
Mount Type: ---
Documentation: ---
CRM:
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---


Attachments (Terms of Use)

  None (edit)
Description Bill Huang 2001-07-27 04:53:08 EDT
Description of Problem:
Almost on title-bar of all the application windows,letters get scrembled.

How Reproducible:
Always

Steps to Reproduce:
1. start a GUI application
2. 
3. 

Actual Results:
letters on title-bar get scrembled

Expected Results:
Japanese can be displayed correctly

Additional Information:
testing with latest-i386(Jul.26)
Comment 1 Bernhard Rosenkraenzer 2001-07-30 02:48:23 EDT
Please take a look at this, I don't know what it should look like...
Comment 2 Bernhard Rosenkraenzer 2001-07-30 02:53:33 EDT
Could this be related to kde-i18n using old-style po files?
Comment 3 Satoru SATOH 2001-07-30 04:44:54 EDT
I don't know it caused by old stuff, but I'll check kde-i18n.


BTW, strange to say, if I selected the TrueType fonts (utf-8 encoding)
and enable AA-displaying, it looks fixed.

Comment 4 Nakai 2001-07-30 12:29:24 EDT
AP people may be able to fix this bug.

And fix this both with bitmap fonts and TT fonts.
Comment 5 Glen Foster 2001-07-30 15:43:55 EDT
This defect is considered SHOULD-FIX for Fairfax
Comment 6 Satoru SATOH 2001-08-03 04:38:20 EDT
kcontrol: [look & feel] -> [font]:
To change the font to use normal (not bold which is the defalut) one
for the title of the window may fix this problem.

Which is the part to specify to use the _bold_ (not normal) font
for the title of the window? And why is the bold font specified?
Comment 7 Leon Ho 2001-08-05 20:07:17 EDT
The first available font on the font list (ie. xlsfonts | grep jisx) of normal
and bold font is a ttf, qt's fontguess took those ttfs to generate fontsets. 

Because xfs does not recognize the TTCap parameters in fonts.{scale,dir}, hence
it does not load the bold fonts for ttf. xtt module supports the TTCap
parameters. To fix bug 50145 and also able to use ttf bold font:

Edit /etc/X11/fs/config:
comment /usr/share/fonts/ja/TrueType

Edit /etc/X11/XF86Config-4:
  In Section "Files"
    Add FontPath "/usr/share/fonts/ja/TrueType"
  In Section "Module"
    Add Load "xtt"

restart xfs, reload X11 (ie. init 3; init 5)

This should fix this problem. 
Comment 8 Satoru SATOH 2001-08-05 21:20:29 EDT
I see. The way you told doesn't only efficient for this problem
but also fix #50941.

Thanks!
Comment 9 Bill Huang 2001-08-08 00:15:49 EDT
So it is a bug against XFree86-xfs and anconda.
since there is no XFree86-xfs component,I point to XFree86-jpfonts.

Aaron,would you please add XFree86-xfs component in bugzilla?
Comment 10 Paul Gampe 2001-08-08 00:21:55 EDT
The xfs support for asian language font extensions is going to be accross
japanese/korean/trad chinese/simp chinese.  

The solution lies either with modifications to the XF86Config file or patches to
xfs, so perhaps this should be assigned against XFree86?
Comment 11 Yu Shao 2001-08-08 05:28:20 EDT
About xfs, we have made some progress. Briefly, within X, there are two sets of
TrueType font handling codes, one called FreeType, the other is
Xtt which is developed by Japanese mainly for CJK fonts. One of these should be
linked to the libXfont library, either FreeType or Xtt, so xfs
can use.

At the moment, FreeType code is compiled and linked to libXfont, this is the
default configuration.  This is also why we have problems with CJK fonts. What
we need to do is just strip the FreeType code, link Xtt code into libXfont.

Right now, I've got some problems when compile Xtt to a shared library, by using
"
#define BuildFreeType NO
#define BuildXTrueType YES
#define XTTInLibXFont YES"
in spec file, the new libXfont still doesn't work. We are still debugging here
in Brisbane, anybody has any idea about this?

BTW, is there any reason we intentionally built FreeType into libXfont before?
Comment 12 Nakai 2001-08-08 08:51:13 EDT
I think this problem is ttfonts-ja, ttfont-ko, ttfont-zh_CN
ttfont-zh_TW.

There is a member of xtt is in Japan office, and he says xtt
is sucks, and will never be maintained. So I don't want to use
xtt unless there is so fatal reason.
Comment 13 Yu Shao 2001-08-08 20:45:49 EDT
TTCap extension examples:

Here are 3 lines took from fons.dir with TTCap extension:

bkai00mp.ttf -Arphic Technology Co.-AR PL KaitiM
Big5-medium-r-normal--0-0-0-0-c-0-big5-0
ai=0.3:bkai00mp.ttf -Arphic Technology Co.-AR PL KaitiM
Big5-medium-i-normal--0-0-0-0-c-0-big5-0
ds=y:ai=0.3:bkai00mp.ttf -Arphic Technology Co.-AR PL KaitiM
Big5-bold-i-normal--0-0-0-0-c-0-big5-0

Basically, the first line tells xtt how to generate the normal font. The second
line, by
using TTCap extension "ai=0.3", xtt knows how to generate fonts by slanting 0.3
(units, some degree ...). The third line's "ds=y" means "double striking of the
face", so we got the bold font.

Details: http://x-tt.dsl.gr.jp/doc/cur/INSTALL.eng
Comment 14 Mike A. Harris 2001-08-14 04:50:33 EDT
We are in freeze, so any changes made to fix this, *must* not be
far reaching.  IOW, switching core library code from freetype to
xtt is definitely a no-no.  I dunno how this will end up being
resolved, but it should be done in a way that is not going to
destabilize the XFree86 release.

I have added .ttc to the xfs initscript so that .ttc files are now
caught also when xfs starts up.  Hope this also helps with CJK for
you guys.  Let me know if there is anything I can help with.

I've also Cc'd Owen.  Please Cc Owen and myself on any font issues.
Thanks.
Comment 15 Owen Taylor 2001-08-14 19:48:22 EDT
The questions that comes to my mind are:

 - Where are the bold fonts that KDE is trying to use configured?
 - Can we configure them to use the non-bold fonts for bold
   as well?
Comment 16 Leon Ho 2001-08-15 20:38:46 EDT
This may be a solution for Fairfax:
Make sure you have taken all the fonts with medium and bold. 
e.g.
-wadalab-gothic-medium-r-normal--0-0-0-0-c-0-jisx0208.1983-0
-wadalab-gothic-bold-r-normal--0-0-0-0-c-0-jisx0208.1983-0

modify changes to fonts.scale, fonts.dir
touch fonts.dir (prevent xfs script to run ttmkfdir to regenerate the file
again, as it has some problems detecting CJK charsets on some ttf fonts)

Restart xfs. You should able to use "bold ttf font" (it will still use normal
type instead of bold type, however this should solve the problem)

P.S. as a safely-net, in CJK ttfonts spec file, at post-install, may need add
"touch fonts.dir" to prevent xfs script updates fonts.{dir,scale}
Comment 17 Mike A. Harris 2001-09-18 04:13:40 EDT
Any progress made on this ssato?

IMHO, the best solution is to extend Freetype to support what is required,
or xfs.. depending on where the specific problem lay.  This is likely something
that will have to be done upstream however unless Owen or someone else familiar
or brave enough is willing to dig into it.
Comment 18 Mike A. Harris 2001-11-05 08:21:55 EST
Can someone update the status of this?
Comment 19 Mike A. Harris 2002-08-22 04:53:34 EDT
Since there hasn't been any feedback on this bug in ages, and I've
pinged twice above about it, I presume the problem is no longer
present, and am closing this bug.

Note You need to log in before you can comment on or make changes to this bug.