From Bugzilla Helper: User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.0.1) Gecko/20020826 Description of problem: /usr/share/fonts/ko/TrueType/fonts.dir has no valid entries for ko_KR.eucKR. Version-Release number of selected component (if applicable): How reproducible: Always Steps to Reproduce: 1.looks at /usr/share/fonts/ko/TrueType/fonts.dir 2. 3. Actual Results: fonts.dir contains only ascii-0 and iso10646-1. Expected Results: fonts.dir should contains ksc5601.1987-0 at least. Additional info:
From fresh installation or upgrade? Upgrade usually will run ttmkfdir from xfs initscript because there must be some files newer than fonts.dir, which it breaks the fonts.dir. I saw the changelog that Mike has disabled the premade fonts.scale previously. How does premade fonts.scale breaks?
fresh installataion. ttfonts-ko generates even fonts.scale on %%post. I'm sure ttmkfdir has a problem at least.
If you really want to generate fonts.scale from ttmkfdir instead of the premade one (which IMHO is better because we can get rid of some unused charsets), the sane way to do is modify ttfonts-ko and xfs initscript to use "ttmkfdir -e /usr/X11R6/lib/X11/fonts/encodings/encodings.dir" to get the encodings directories from there. By default right now ttmkfdir only searchs encodings.dir in the currect directory.
Hi Mike, can we use this patch, it just set ttmkfdir's default encodings.dir as the system default.
Created attachment 74844 [details] ttmkfdir-default-encodings.dir-patch.diff
Details here: http://post-office.corp.redhat.com/pipermail/eng-ap/2002-April/000896.html
Me and David Joo are investigating this...
fixed on latest ttmkfdir