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):
Steps to Reproduce:
1.looks at /usr/share/fonts/ko/TrueType/fonts.dir
Actual Results: fonts.dir contains only ascii-0 and iso10646-1.
Expected Results: fonts.dir should contains ksc5601.1987-0 at least.
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
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]
Me and David Joo are investigating this...
fixed on latest ttmkfdir