Hi, FYI, below is my message sent to [EMAIL PROTECTED] to address newly found problems in ksc5601.1987-0.enc (a part of which was originally introduced in v1.2 of the file) as well as old problems for which I submitted patches to [EMAIL PROTECTED] a few months ago.
Jungshik Shin ------- Hello, Attached is a new patch that makes obsolete my patches (assigned A.895 and A.990) sent on March 2? and April 25 this year. My previous patch (A.895) addressed the problem of ksc5601.1992-3.enc file with ttmkfdir2 (used by some Linux distributions such as RedHat to generate fonts.scale file: see http://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=54087). The other patch of mine (A.990) added two new characters in KS X 1001:1998(ksc5601.1987-0.enc) and JOHAB(ksc5601.1992-3.enc). The patch I'm including addresses two new problems I found today as well as those fixed by A.895 and A.990. Therefore, A.895 and A.990 should be discarded and this patch should be applied in place of them. Two new problems fixed by this patch are: - ksc5601.1987-0.enc still has some spurrious entries which are not harmful but takes unnecessary disk space. For instance, the code range 0x3110 - 0x311E is not valid in KS C 5601-1987, but those code points are included in ksc5601.1987-0.enc. - The way some characters are mapped Unicode codepoints are not consistent with other widely used mappings such as Glibc 2.x, libiconv and XFree86's own ksc5601.h and ksc5601.1992-3.enc. For instance, 0x212D(in KS C 5601) is mapped to U+FF5E, but that's different from other mappings widely used on platforms where XFree86 is used. The exception to this might be Mac OS X. Apple's Korean mapping is different from Microsoft's mapping on which Glibc 2.x, libiconv and ksc5601.h are based. Anyway, I think that it's better to make ksc5601.1987-0.enc in line with what's used by Glibc 2.x, libiconv and XFree86's ksc5601.h and ksc5601.1992-3.enc. Thank you in advance for your kind attention, Jungshik Shin
font.enc.patch.2.gz
Description: Binary data
