From Bugzilla Helper:
User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:0.9.8+) Gecko/20020222
Description of problem:
ttmkfdir cannot process font encodings with FIRSTINDEX
entry. To work around this problem, encoding files
with FIRSTINDEX were modified by commenting out
lines with FIRSTINDEX. I think this should be the
other way around. That is, ttmkfdir should be fixed
not to choke on FIRSTINDEX. At the moment, ttmkfdir
does not do anything with FIRSTINDEX. Then, it can
just ignore FIRSTINDEX line instead of refusing
to process font encoding files with FIRSTINDEX.
Version-Release number of selected component (if applicable):
Steps to Reproduce:
1.Put the original ksc5601.1992-3.enc.gz file(with FIRSTINDEX)
2.run ttmkfdir in ttfonts-ko directory
Actual Results: ttfonts-ko emits warning and refuses to work on ksc5601.1992-3.
Expected Results: It should produce ksc5601.1992-3 entries for three Korean
truetype fonts in addition to iso10646-1 and ksc5601.1987-0
Created attachment 49929 [details]
a patch to ttmkfdir2
My patch modifies encoding.l in ttmkfdir2 to make it ignore
FIRSTINDEX line in encoding files. The reason I'd like
to keep FIRSTINDEX line in encoding files is that
other parts of XFree86(freetype,X-tt or luit) may need it.
ksc5601.1992-3 entries wouldn't be produced unless
my patch to ksc5601.1992-3.enc(described in
my comment to bug 54087) is applied.
Changing component to XFree86 where ttmkfdir currently resides in RHL 7.3
This somehow fell between the cracks, since we've had a hack workaround
in place. Reassigning to ttmkfdir component for attention.
fixed ages ago, forgot to update here.