ttf-alee 11 업로드

글쓴이: alee / 작성시간: 화, 2006/10/10 - 3:50오후

ttf-alee 11을 업로드합니다.
한글날 記念으로 구슬체의 常用漢字 4888자 및 擴張漢字 2856자 領域에 한글 音價를
집어넣었는데 업로드가 하루 늦어졌습니다. 漢字에 該當하는 글자에는 한글과 區分하기
위해서 글자 위에 조그맣게 點이 찍히도록 했습니다. 漢字를 좋아하는 분께는 深刻한
蠻行이 될 것 같습니다.

한글날 기념으로 구슬체의 상용한자 4888자 및 확장한자 2856자 영역에 한글 음가를
집어넣었는데 업로드가 하루 늦어졌습니다. 한자에 해당하는 글자에는 한글과 구분하기
위해서 글자 위에 조그맣게 점이 찍히도록 했습니다. 한자를 좋아하는 분께는 심각한
만행이 될 것 같습니다.

그 외에 fontconfig 버전이 올라가면서 기존에 “Guseul”과 같이 영어로 나오던 한글
글꼴의 이름이 “구슬”과 같이 한글로 나오기 시작했는데, 이때부터 한글 호환 자모 영역에
옛글이 들어 있지 않으면 우선순위에서 밀려서 “Sans” 등으로 바인딩이 제대로 되지 않는
문제가 있어서 옛글용 호환 자모를 그려 넣었습니다.

File attachments:

첨부	파일 크기
ttf-alee-guseul-hanja.png	393.85 KB

Forums:

뉴스, 새소식

와 재밌습니다 :>

글쓴이: wkpark / 작성시간: 화, 2006/10/10 - 5:27오후

와 재밌습니다 :> 이런 재미난 발상을 하시다니~

한글날 기념으로 딱 맞겠네요~~

온갖 참된 삶은 만남이다 --Martin Buber

잘 하셨다고... 해야 할까

글쓴이: danskesb / 작성시간: 화, 2006/10/10 - 5:37오후

예전에 이런 글꼴이 있었다는 것을 얼핏 들었는데, 여기서 다시 탄생하는군요.
---- 절취선 ----
http://ubuntu.ksa.hs.kr

잘쓰겟습니다.

글쓴이: sellee / 작성시간: 화, 2006/10/10 - 5:48오후

항상 감사합니다.

점은 다른 걸로 바꾸는 게 어떨까요?

글쓴이: keizie / 작성시간: 화, 2006/10/10 - 6:25오후

방점과 헷갈리기도 하고, 눈에 거슬립니다.

그렇다면 어떤게 좋을까요?

글쓴이: alee / 작성시간: 화, 2006/10/10 - 7:41오후

한자라는 것을 “강조”하기 위해서 점을 덧붙였습니다.
방점과 혼동될 수 있다고 하셨는데, 바로 그 “방점”을 찍는 목적과 동일합니다.
그렇지만 더 나은 방법이 있다면 바꾸는 것에 저도 찬성합니다.
어떤 방법이 있을까요?

테두리가 될까요?

글쓴이: keizie / 작성시간: 화, 2006/10/10 - 10:15오후

구슬체면 이미 고정폭이니까 들쭉날쭉하진 않을 거라고 생각합니다. 테두리에 얇은 선이나 점선으로 테두리를 치는 게 어떨까요?

freetype에서 글꼴에 없는 글자를 표현할 때 테두리 안에 유니코드를 찍어주는 데서 왔습니다.

저도 처음에

글쓴이: alee / 작성시간: 화, 2006/10/10 - 10:28오후

저도 처음에 테두리를 생각했었는데
큰 크기에서는 관계 없지만 작은 크기에서는 테두리를 그릴 만한 공간이 없습니다.
공간을 마련하기 위해서는 글자 크기를 조금 축소해야 하는데, 그러면 힌팅 정보가 쓸모
없어집니다. 글자 크기를 그대로 유지하기 위해서는 글자의 위쪽 외에는 공간이 없습니다.

뿐만 아니라 글자마다 다 사각형 테두리가 그려져 있다면 위에 방점이 찍혀 있는 것 보다
오히려 더 보기에 불편할 것 같습니다.

wow

글쓴이: sheep / 작성시간: 수, 2006/10/11 - 1:00오전

한자가 원래 없던 글꼴 맞죠?

만행이라면 만행이네요...

alee님 센스쟁이....

--------
From Buenos Aires, Argentina
No sere feliz pero tengo computadora.... jaja
닥치고 Ubuntu!!!!!
To Serve My Lord Jesus
blog: http://sheep.tistory.com (블로그 주소 바꼈습니다)

--------
From Buenos Aires, Argentina
No sere feliz pero tengo computadora.... jaja
닥치고 Ubuntu!!!!!
To Serve My Lord Jesus
blog: http://sehoonpark.com.ar
http://me2day.net/sheep

정말...

글쓴이: budle77 / 작성시간: 수, 2006/10/11 - 1:25오전

정말 훌륭하십니다.
이런 멋진 일을 하시다니. ^^

===========================================
개발과 관리가 가능한 DBA를 목표로...

재미있네요.

글쓴이: codebank / 작성시간: 수, 2006/10/11 - 10:44오전

Gentoo에는 언제나 올라올지... :-)

------------------------------
좋은 하루 되세요.

Gentto에는 6.1까지만

글쓴이: highwind / 작성시간: 일, 2006/10/15 - 10:50오전

Gentto에는 6.1까지만 stable로 되어있고요.
Unstable한건 8.3까지밖에 없네요...

~x86 arch에서 말입니다.

http://packages.debian.org/unstable/x11/ttf-alee
여기에 가보았지만 직접 다운이 안되네요.
어떻게 구할수 있을까요?

=====================================
http://timothylive.net

echo

글쓴이: 정태영 / 작성시간: 월, 2006/10/16 - 8:35오후

echo PORTDIR_OVERLAY=/usr/local/portage >> /etc/make.conf
mkdir -p /usr/local/portage/media-fonts/alee-fonts
cd /usr/local/portage/media-fonts/alee-fonts/
cp /usr/portage/media-fonts/alee-fonts/alee-fonts/alee-fonts-8.3.ebuild ./alee-fonts-11.1.ebuild
ebuild alee-fonts-11.1.ebuild digest
emerge alee-fonts

젤 간단한 방법은 위와 같은 방법이고, 조금 귀찮지만 다른 사람들까지 위하는 방법은 젠투 버그질라에 alee-fonts version bumped 정도로 버그를 등록하는 것입니다.

한국인 메인테이너가 없어서인지 alee-fonts 나 unfonts, baekmuk-fonts 같은 (거의) 한국인들만을 위한 패키지들은 누가 신고해주지 않으면 알아서 올려주는 일은 거의 없습니다.

-----
오랫동안 꿈을 그리는 사람은 그 꿈을 닮아간다...

http://mytears.org ~(~_~)~
나 한줄기 바람처럼..

오랫동안 꿈을 그리는 사람은 그 꿈을 닮아간다...

http://mytears.org ~(~_~)~
나 한줄기 바람처럼..

kldp.net 프로젝트로

글쓴이: only2sea / 작성시간: 일, 2007/09/09 - 3:54오후

kldp.net 프로젝트로 등록되어 있는 gentoo-ko 에 가보시면
alee-fonts가 layman portage overlay에서 관리되고 있습니다.
다행히 최근 버전이 portage 메인 트리에 등록이 되었습니다.

블로그: http://turtleforward.blogspot.com

정말 훌륭하십니다. :

글쓴이: xx1 / 작성시간: 수, 2006/10/11 - 11:48오전

정말 훌륭하십니다. : )

근데, 김씨가 금씨가 되네요.

글쓴이: 돌부리 / 작성시간: 수, 2006/10/11 - 10:43오후

재미있는 폭거군요, 근데, 성으로 사용되는 金이 금으로 표시되는 문제가 있네요.

물론 그런 문제가

글쓴이: wkpark / 작성시간: 목, 2006/10/12 - 12:40오전

물론 그런 문제가 있겠지요. 그 이외에도 다음과 같은 문제점들이 가능하겠지요 :>

http://wiki.kldp.org/KoreanDoc/html/Hanja2Hangul/Hanja2Hangul.html

하지만 단지 글꼴만 바꾸는 것으로 모든 한자를 한글로 볼 수 있다는 점으로도 충분히 매력적일 듯.

P.S.:한자=>한글 변환 루틴 잘 알려진 것 없을까요?

온갖 참된 삶은 만남이다 --Martin Buber

Unihan database의 kHangul

글쓴이: lifthrasiir / 작성시간: 목, 2006/10/12 - 3:25오전

Unihan database의 kHangul 필드를 쓰는 게 좋을 것 같습니다. 다른 데이터베이스는 본 적이 없네요;

최근에는 접속이 안

글쓴이: 김도현 / 작성시간: 목, 2006/10/12 - 12:07오후

최근에는 접속이 안 됩니다만, 예전에 “진숙의 유니코드 입문서”라는 사이트에서 BMP 전 영역 한자의 한글음가 테이블을 발견한 적 있습니다. (여기서 버그 하나를 발견해서 김진숙님께 보고하여 고치기도 했습니다)

물론 전혀 한국에서는 쓰일 일이 없을 법한 한자까지 한글발음이 들어있어 그 출처가 어딘지 상당히 궁금했고 완전히 믿을 수 있는지도 자신이 없습니다만, 분명한 것은 Unihan DB가 제공하는 한글음가의 양을 능가하는 방대한 양이 들어 있었다는 것입니다.

저는 이것을 사용해서 hangul-ucs라는 TeX package를 개발하였습니다. TeX에서는 배열이 아닌 해시(Perl 용어를 써서 죄송합니다만 프로그래밍에 문외한인 저는 펄 밖에 몰라서요)를 다루기가 대단히 어렵기 때문에 Unihan DB를 이용하려면 조작을 가해야 하는 귀찮음이 있었고 hangul-ucs는 유니코드 전 영역을 (심지어 보충판까지) 지원하기 때문에 기왕이면 데이터 양이 풍부한 쪽이 좋다고 생각했기 때문입니다. 어쨌든 이것으로 한자 뒤에 조사가 올때 자동으로 조사를 결정하게 하기도 했고, 색인 정렬할 때 한자와 한글이 섞여있는 항목들을 가나다 순으로 소팅하기도 했습니다. 상당히 유용하더군요.

진숙의 유니코드 입문서는 지금 접속이 안되지만 한자-한글음가 변환테이블은 hangul-ucs cvs에 고스란히 남아 있습니다.

한중일 통합한자
http://cvs.ktug.or.kr/viewcvs/hangul-ucs/dhucs/tex-latex-dhucs/hanja_hg.tab

한중일 확장한자 A
http://cvs.ktug.or.kr/viewcvs/hangul-ucs/dhucs/tex-latex-dhucs/hjexa_hg.tab

한중일 호환한자
http://cvs.ktug.or.kr/viewcvs/hangul-ucs/dhucs/tex-latex-dhucs/hjcom_hg.tab

웹의 나쁜점...

글쓴이: wish / 작성시간: 금, 2006/10/13 - 7:10오후

"진숙의 유니코드 입문서" 라는 사이트 괜찮은 내용이 많았는데 요즘 접속이 안되서 아쉬울 때가 있더군요 ㅜㅜ

http://web.archive.org/web/20

글쓴이: 정태영 / 작성시간: 월, 2006/10/16 - 8:40오후

http://web.archive.org/web/20050208231016/www.jinsuk.pe.kr/Unicode/unicode-kr.html

archive.org 를 이용해보세요. 인코딩을 euc-kr 로 변경해가면서 봐야한다는 단점잉 ㅣㅆ끼는 하지만 아카이브되어있기는 합니다. :)

------
오랫동안 꿈을 그리는 사람은 그 꿈을 닮아간다...

http://mytears.org ~(~_~)~
나 한줄기 바람처럼..

오랫동안 꿈을 그리는 사람은 그 꿈을 닮아간다...

http://mytears.org ~(~_~)~
나 한줄기 바람처럼..

와

글쓴이: wkpark / 작성시간: 금, 2006/10/13 - 9:24오후

와 대단하네요~

일전에 krisna님의 Nabi 프로젝트에서 한자음에 대한 독음과 뜻을 다는 공동 프로젝트를 통해서 집어넣은 한자뜻이 약 9천5백자 정도 됩니다. 한자음은 유니코드의 kKorean을 바탕으로 스크립트로 뽑아내서 그것에 대해 뜻을 넣으면서 여러 오류들을 발견했던 것으로 기억하고요.

http://kldp.net/plugins/scmsvn/viewcvs.php/nabi/trunk/tables/candidate/?root=nabi

"진숙의 유니코드"에 있는 데이타는 어쩌면 윈도에 포함되어있는 정보를 바탕으로 한게 아닐까 하는 의심을 해봅니다 :> (그런데 윈도에 있는 몇몇 한자를 변환, 역변환 하면서 어쩌다가 잘못된 독음을 가진 한자를 발견했던 기억이 있습니다.)

온갖 참된 삶은 만남이다 --Martin Buber

나비 한자 독음과

글쓴이: 김도현 / 작성시간: 토, 2006/10/14 - 3:27오전

나비 한자 독음과 진숙 한자 독음이 서로 다른 것들이 눈에 띄여서 diff를 만들어 보았습니다. 다른 것이 자그만치 898개나 됩니다.

http://210.94.201.157/~nomos/KTUG/nabi-hanja/

그런데 그 차이의 대부분은 한자 하나가 여러 가지로 소리날 때, 나비는 각각 따로 등록한 반면, 진숙은 대표음가 하나만 취한 데서 생긴 것으로 보입니다. 이런 것은 정책의 차이이므로 어느 한 쪽의 잘못이라 보기 어렵겠습니다.

하지만 이 diff를 이리저리 살피다보면 실제로 나비의 버그나 진숙의 버그를 찾을 수 있을지도 모르겠네요.

제 생각에는 nabi의

글쓴이: alee / 작성시간: 토, 2006/10/14 - 10:27오후

제 생각에는 nabi의 정책은 별로 바람직한 정책이 아닌 것 같습니다.

예를 들어 “更”자를 입력하기 위해 한글로 “갱”이라고 입력한 후 한자 변환 키를 누르면
목록에 “更: 다시 갱”(경)과 “更: 다시 갱”(갱)으로 “경”으로 읽일 때의 글자와 “갱”으로 읽힐
때의 글자 둘이 모두 나옵니다. 이런 경우 입력하는 사람은 대부분 당연히 더 앞쪽에 나와 있는
“更”(경)을 선택하게 됩니다.

이렇게 입력된 문서는 한자로 입력된 상태로만 문서를 이용한다면 별 문제가 없지만 나중에
이 문서를 다시 한글로 변환할 때 처음에 입력자가 의도했던 글자인 “갱”으로 변환되는 대신
“경”으로 변환되는 문제가 있습니다.

nabi의 한자사전은

글쓴이: wkpark / 작성시간: 일, 2006/10/15 - 1:07오전

nabi의 한자사전은 정렬을 좀 더 고려해야 할 것으로 보입니다. KS X 1001/1002와 통합 및 호환 환자들이 모두 유니코드 순서로 정렬되어 있어서 불편함이 있습니다.
(유니코드 순서가 사용 횟수를 근거로해서 정렬되거나 한 자료가 아니기 때문에)
또 Variant에 대해서는 같이 모아놓아야 할 것 같고요.

독음이 여러개 있는 것은
1. 更다시 갱(경) 그리고 更 다시 갱(갱) 이런 식으로 뜻을 달거나,
2. 호환 한자에 대해서는 호환한자라는 것을 명시한다거나,
3. 호환 한자에 있는 음가를 존중해서(?) 반드시 호환 한자를 쓴다거나,
4. 호환 한자는 쓰지 않는걸로 한다거나,
등등의 토론이 있어야 되는게 아닐까 합니다.

지금 분위기(?)로 봐서는 3)과 1)이 택해지고 2)는 선택사항일 것 같습니다만,
----
이와는 별도로 아래 자료에 의하면

http://wiki.kldp.org/KoreanDoc/html/Hanja2Hangul/Hanja2Hangul.html

Quote:

표준 한자 코드에 있는 한자인 '佳'가 '가'와 '개'의 두 가지 음을 갖는 것처럼 복수의 음을 갖는 한자는 다음과 같이 2,725자이다.
1. 2음자(976자 * 2 = 1,952자)
2. 3음자(188자 * 3 = 564자)
3. 4음자(34자 * 4 = 136자)
4. 5음자(12자 * 5 = 60자)
5. 6음자(1자 * 6 = 6자)
6. 7음자(1자 * 7 = 7자)

그리고 '賈'가 '가'와 '고'의 두 가지 음 모두가 표준 한자 코드에 등록된 것처럼 복수 등록이 된 한자는 다음과 같이 262자이다.

1. 2회 등록(257종 * 2 = 514자)
2. 3회 등록(4종 * 3 = 12자)
3. 4회 등록(1종 * 4 = 4자)

복수등록은 제가 방금 확인해본 결과 KS X 1001 + KS X 1002 합해서 268자입니다.

(유니코드의 kCompatibilityVariant 항목중 KS X 1001/1002에 포함된 글자만)

모든 걸 제대로 지원할 자동화된 솔루션이(공개 소스) 지금은 없다 봐야할 듯.

온갖 참된 삶은 만남이다 --Martin Buber

그렇다면 이제

글쓴이: krisna / 작성시간: 월, 2006/10/16 - 1:15오후

그렇다면 이제 Unicode에서 한자 표현에 대한 컨벤션이 좀 정해질 필요가 있겠습니다.

위의 내용은 입력기에서 어떤 식으로 보여지느냐라는 건데, 한자 표현이 어떻게 되느냐를 먼저 생각
하는 편이 쉽겠습니다.

한 글자가 여러 음을 가지는 경우에 대해서:

1. 무조건 CJK 통합 한자 영역으로 표현한다. (호환 한자는 쓰지 않는다)
문제점: 본래 음가 정보를 잃어버린다.

2. 호환 한자가 있는 경우 KSC1001, KSC1002를 참조하여 호환 한자 영역으로 표현한다.
문제점: 모든 글자의 음가를 보존할 수 있는 것은 아니다. (복수 등록된 한자는 262자에 불과함)

이 표현 방법이 정해져야 입력기에서 어떤식으로 구현할 지 결정할 수 있겠지요.

또 두음법칙으로 음가가 두개로 나뉜경우는 어떻게 할 것이냐 문제도 생각해봐야 합니다.
두음법칙에 의한 것은 우리만 있는 문제로 모든 두음 법칙에 대해서 글자가 등록되지는 않은
것으로 알고 있습니다.

저는 단순히 통합영역만 사용하는 것이 쉬울 것 같습니다.

1번은 말씀하신

글쓴이: 김도현 / 작성시간: 화, 2006/10/17 - 1:04오전

1번은 말씀하신 이유로 아니 됩니다. “선거유세”가 “선거유설”이 된다면 가나다 정렬이나 자동조사 결정에 치명적인 오류가 발생하고 이를 나중에 기계가 바로 잡기가 대단히 어렵습니다.

2번이 올바른 방향이라고 봅니다. 사용자가 선거유세(說, U+F96F)를 입력하고자 한다면 통합한자 영역의 “말씀 설(U+8AAA)”글자는 (비록 이 글자의 제2순위 음가가 “세”라고 되어있다 해도) 후보로 보여주어서는 안 된다고 생각합니다. 호환한자 영역에 “세”라고만 발음되는 동일한 모양의 글자가 있으니까요.

두음법칙 문제는... 사실 호환한자영역을 살펴보면 상당수가 두음법칙 때문에 들어가 있는 글자들이란 사실을 알 수 있습니다. 이를테면 호환한자영역의 女(U+F981)는 “여” 발음만 가집니다. 통합한자영역의 女(U+5973)는 “녀” 발음을 가집니다.

물론 호환한자에 들어있는 것이 몇개 안 되어 한정적이란 문제가 있지만 한국에서 가장 흔히 쓰이는 것들이므로 의미는 충분하다고 봅니다. 망라적이지는 못하나 애써 유니코드에 집어넣은 feature를 사장시켜서는 안 된다고 봅니다.

결론적으로 호환한자영역에 당해 발음의 같은 모양 한자가 있다면 호환한자만을 후보로 제시하면 충분하다, 아니 그래야만 한다는 것이 저의 생각입니다.

두음 법칙 이야기를

글쓴이: krisna / 작성시간: 화, 2006/10/17 - 1:47오후

두음 법칙 이야기를 따로 꺼낸 것은
두음 법칙에 따른 글자들의 경우 입력하는 사람이 두음법칙을 무시한 한자로 입력할 가능성이 있기 때문에, 두음 법칙의 경우 예외로 그냥 통합영역을 바로 쓰는 것이 어떨까 하는 생각에서 였습니다.

다른 생각을 가지신 분들은 없는지 궁금하군요.

저는 김도현님

글쓴이: alee / 작성시간: 수, 2006/10/18 - 7:54오전

저는 김도현님 말씀에 찬성입니다.
애써 따로 코드를 만들어 둔 호환 영역을 사장시킬 필요는 없다고 봅니다.

또, 두음법칙의 경우에도 대부분의 사람은 그냥 음가대로 입력하지 애써
두음법칙을 무시한 음가로 입력하는 사람은 드물 것 같습니다.
간혹 그렇게 입력하는 사람이 있다고 해도 몇몇 그런 사람 때문에 나머지 사람이
입력하는 문서까지 전부 다 음가 정보를 잃어버리도록 할 필요는 없다고 봅니다.

결국 지금

글쓴이: wkpark / 작성시간: 수, 2006/10/18 - 11:08오전

결국 지금 시점에서는 예외 268개를 제외하고는 모두 통합 영역을 써야 된다는 거네요 :>

그럼 예외 이외의 2천여 복수 음가를 가질 수 있는 글자에 관한 정보는 어디서 구할 수 있을지도 궁금하군요.

두음법칙에 관련된 문자인지 아닌지는 초성이 ㅇ,ㄴ인 경우에 그것을 ㄹ로 대치해서 다른 글자를 동시에 찾아보는 식으로 할 수도 있겠고, 두음법칙을 고려해야 할 한자가 많지 않다면 단순히 테이블에 그것이 있는지 없는지로 판별할 수도 있겠죠. (메모리 낭비가 아까우면 candidate map처럼 외부로 빼버릴 수도 있고요.

온갖 참된 삶은 만남이다 --Martin Buber

그렇다면 나비의

글쓴이: krisna / 작성시간: 수, 2006/10/18 - 9:27오후

그렇다면 나비의 한자 사전 파일 작업을 다시 하는 것이 좋겠군요.
호환 영역에 한자가 있다면 호환 한자를 표시하도록 수정하도록 하겠습니다.

그러나 이제는 libhangul에서 데이터 파일을 관리하므로 libhangul에서 먼저 수정한후
그 것을 나비에 적용하는 방식으로 작업을 하겠습니다.

그나저나 이

글쓴이: wkpark / 작성시간: 금, 2006/10/13 - 10:05오후

그나저나 이 테이블도 alee님의 말씀대로라면 "김"에 대해 잘못이 있습니다. (perl을 써서 확인해 보았습니다.)
== 한중일 통합 ==

김 - U+91d1 金
금 - U+91d2 ?

== 한중일 호환 ==

금 - U+f90a 金

----
나비의 한자사전도 마찬가지 문제가 있지만, 금을 찾아보니 "성 金(금)"이라고 나와있고 이게 "김"인거네요.

온갖 참된 삶은 만남이다 --Martin Buber

Unihan DB에서

글쓴이: 김도현 / 작성시간: 토, 2006/10/14 - 3:43오전

Unihan DB에서 호환한자의 독음은 하나씩만 주어져있고, 통합한자 음가는 여러 개 주어져 있으면서 호환한자와 동일한 것을 후순위로 하고 있습니다.

U+91D1 KIM, KUM

U+F90A KUM

그렇다면 표준을 바꾸지 않는 한 U+F90A를 “금”, U+91D1을 “김”으로 읽는 것이 옳다고 봅니다.

네 제가 밑에도

글쓴이: wkpark / 작성시간: 토, 2006/10/14 - 9:59오전

네 제가 밑에도 인용했지만 그렇게 되어있네요.
현 표준 자료상으로는 MS의 IME가 하자가 없는 것입니다.

그런데 UniHan.txt를 틀렸다고 말했던 이유는
* 아래아한글에는 U+F90A를 김으로 U+91D1을 금으로 하고 있다. (확인 안됨)
* 통합한자에는 오류가 예상보다 많다는 것.
1. http://kldp.net/tracker/index.php?func=detail&aid=300783&group_id=275&atid=100275
1. http://lists.kldp.net/pipermail/hangul-hackers/2004-June/thread.html

등이었습니다.
-------
오늘 좀 자세히 들여다 보았습니다.

U+91D1 kDefinition gold; metals in general; money

U+91D1 kJapaneseOn KIN KON

U+91D1 kHanyuPinlu jin1(568)

U+91D1 kTang *gyim

U+91D1 kVietnamese kim

우리나라 뿐만 아니라 다른 곳에서도 U+91D1를 김으로 읽고 있는 듯 합니다.

그렇다면 음가 자체만을 두고 얘기하면 U+91D1를 金(김)이 맞습니다.
-------
그러나, 뜻을 보면 "gold"라고 되어있죠. 뜻으로만 본다면 김이 아닌 금인거죠 ㅡㅡ;;
(다른 alee님을 위시한 다른 분들이 틀렸다고 주장하시는 근거인 듯)

성 김은 우리나라에서밖에 안쓴다고 알고 있었는데, 오히려 "금"이라는 발음이 우리나라에서
만 쓰이는 소리일 가능성이 높군요. 이런 상식때문에 UniHan.txt가 틀렸다고 주장했던 근거가
아닌가 합니다.
-------
그렇다면, 다음 두가지를 얘기해야 하겠네요 ^^;;
* UniHan.txt가 맞다: 발음상 근거 - 금이라고 발음하는 나라는 우리밖에 없다.
* UniHan.txt가 틀리다: 뜻을 근거로 - 한자의 특성상 뜻을 기준으로 하는게 맞다. 그 뜻을 "gold"라고 다른나라가 여기므로, 다른 나라에서 모두 "김"이라고 발음해도 우리나라는 "금"이라고 하는게 맞다.

온갖 참된 삶은 만남이다 --Martin Buber

아래아한글은 제가

글쓴이: alee / 작성시간: 토, 2006/10/14 - 10:11오후

아래아한글은 제가 확인했습니다.

유니코드의 통합 한자 영역은 원래 음가를 기준으로 배열한 것이 아니라 한·중·일에서 같은 뜻으로 쓰이는 한자를 통합하여 배열한 것입니다. 따라서 U+91D1는 “gold”라는 뜻을 갖는 문자라고 봐야 합니다. 따라서 당연히 우리나라에서는 “금”으로 읽어야 합니다. 그렇지만 이미 대부분의 문서가 “김”과 “금”이 서로 바뀌어 입력되어 있으니 고치기에는 늦었다고 생각합니다. 고쳐달라고 요구해 봐야 MS에서 Windows의 IME를 고쳐 줄 것 같지도 않구요. UniHan.txt도 이제 이미 굳어진 관습에 맞게 가야겠지요.

금과 은...

글쓴이: knight2000 / 작성시간: 일, 2006/11/26 - 7:33오후

성 김(金)과 은(銀)은 그 소리가 매우 비슷합니다.
이것도 한중일 공통이죠.
그런 관점에서 본다면 어느 때에는 이 두 글자의 소리가 거의 같았다고 볼 수도 있습니다.

김과 금... 이 두 소리도 그러한 분화를 보여준다고 여기고 있습니다.
특히 우리나라 한자는 당나라 시절의 한자 독음에 가깝고,
일본 한자는 명나라 초기의 한자 독음에 가깝습니다.
그런데 현대 중국어 한자 독음은 우리나라나 일본과도 또 다릅니다. 우리나라와 일본은 金을 금(Guem), 김(Gim), 긴(킨, Kin)으로 읽지만, 중국에서는 진(Jin)이죠.
여기에서 일본어(가나)는 kin과 kim이 같으므로 굳이 '킨'이 아니라도 '킴'이라고 해도 무리가 없다는 사실입니다(물론 대부분 '킨'으로 읽습니다).

그냥 제 생각을 주절거려 보았습니다. ^^a

p.s.
갑자기 어릴 적에 마시던 킨 사이다가 생각나네요.
그 회사 사장 성씨가 金(Kin)이었다고 하던데...

===== ===== ===== =====
knight2000 of SALM.
SALM stood for SALM Ain't a Life Model.
SALM is not the life model, but SALM is just the life.

===== ===== ===== ===== =====
knight2000 of SALM.
SALM stood for SALM Ain't a Life Model.
SALM is not the life model, but SALM is just the life.

입력기의 버그인 것

글쓴이: alee / 작성시간: 목, 2006/10/12 - 9:00오전

입력기의 버그인 것 같습니다.

유니코드에는 한·중·일 통합 한자 영역에 한·중·일에서 공통으로 쓰이는 한자가 들어 있고,
한·중·일 호환 한자 영역에 글자는 같지만 음가가 다른 글자처럼 중복되는 글자가 들어 있습니다.
한중일 호환용 한자

쇠“금”자의 경우 한·중·일에서 공통으로 쓰이는 “쇠”라는 뜻을 갖는 글자이므로 통합 한자
영역에 들어 있는 0x91d1 코드에 해당됩니다. 반면 성씨의 “김”은 우리나라에서만 쓰이는
한자이므로 호환 한자 영역에 들어 있는 0xf90a 코드에 해당됩니다.

그런데 입력기의 버그인지 코드가 서로 뒤바뀌어 입력이 되네요. nabi나 imhangul도 그렇고,
테스트 해 본 결과 윈도의 IME 역시 마찬가지입니다. 유일하게 제대로 변환이 되는 것은 아래아
한글 뿐이군요.

여태까지 입력되어 있는 모든 신문기사 등에서 전부 코드가 뒤바뀌어 있다는 점을 감안해
金과 金의 음가를 뒤바꾼 버전을 다시 업로드합니다.

날개셋도 그러합니다.

글쓴이: keizie / 작성시간: 토, 2006/10/14 - 12:44오전

http://moogi.new21.org/zb41/view.php?id=bugreport&no=1255

윈도우 자체의 문제였다가 이후 다른 플랫폼까지 옮아간 것 같습니다.

유니코드의

글쓴이: wkpark / 작성시간: 토, 2006/10/14 - 1:30오전

유니코드의 UniHan.txt에서 잘못이 있군요. kHangul, kKorean 모두 잘못되어 있습니다.

U+F90A kKorean KUM

대신에 원래 금이 옳다고 여겨지는 것은 다음과 같습니다.

U+91D1 kHangul 김 금
...
U+91D1 kKorean KIM KUM

온갖 참된 삶은 만남이다 --Martin Buber

근데 이상하게 AA가 들어갑니다.ㅠ_ㅠ

글쓴이: nainu / 작성시간: 토, 2006/10/14 - 2:56오전

10.8 버전에서는 잘 나왔었는데
10.9 버전부터 다시 AA가 붙어 나옵니다.
우분투 사용중이구요 왜 이런지 궁금합니다. ㅠㅠ
한자는 잘 보이네요.ㅎㅎ
막상 입력은 조금 힘들다는 점이!

nainu in wonderland.

한자 입력할 때는 쥐약입니다

글쓴이: keizie / 작성시간: 월, 2006/10/16 - 12:00오후

한글을 치고 무심코 F9를 눌렀다가 당황했습니다. 확장영역의 한자만 드문드문 한자로 나오고 나머지는 다 한글..-_-;;

가나 영역도 채워보면 어떨까요?

글쓴이: keizie / 작성시간: 화, 2006/10/17 - 11:58오후

실은 예전에 alee님께 들었던 기억을 더듬어서 fontforge를 열어봤는데 버벅거리기만 하다가 kill 해버렸습니다. -_-;
히라가나나 가타가나로 적힌 게 있으면 읽을 수가 없어서 그러려니 하는데 한글로 어떻게든 적혀있으면 때려맞출 수 있겠다 싶어서요.

문제는 가나를 제가

글쓴이: alee / 작성시간: 수, 2006/10/18 - 8:06오전

문제는 제가 가나를 전혀 모른다는 것입니다. ㅡㅡ;
또, 채워 넣는다고 해도 한자만큼의 효과는 없을 것 같습니다. 한자의 경우
읽을 수만 있으면 뜻을 알 수 있는 경우가 많지만 가나는 읽어도 대부분의
사람이 뜻을 모르니까요.

그런데 선택한 글꼴에 해당 글자가 없으면 알아서 다른 글꼴로 나오지 않나요?

발음이라도 보이면 좀 낫지 않을까 하는 거죠.

글쓴이: keizie / 작성시간: 수, 2006/10/18 - 10:19오후

저는 가나로 아리가도, 스미마셍 등을 어떻게 적는지 모르지만 그 뜻은 대충 줏어들어서 알고 있습니다. 얼추 스미마셍으로 읽을만한 뭔가가 한글로 나와준다면 저한테는 도움이 되겠죠.

문제는..

글쓴이: Prentice / 작성시간: 금, 2006/10/20 - 1:27오전

문제는 일본어 음소와 한국어 음소를 1:1로 대응시켰을 때, 실제 음성과는 거리가 있는 물건이 나온다는 점에 있습니다.

한 예로 Kyoko에 해당하는 음소를 게임업계(?)에서 쓰는 표기법으로 한글화하면 쿄코가 되지만, 현행 외래어 표기법대로 하면 교꼬가 돼버립니다. 이를 제대로 판단하려면 어두와 어중, 어말을 구분해야하는데, 일어는 한자와 가나를 병기할 때는 띄어쓰기를 안하죠. 그렇다고 형태소분석이라도 하기는 너무 엄(?)하죠.

한자 관련된 토론이

글쓴이: 익명사용자 / 작성시간: 수, 2006/10/25 - 12:37오후

한자 관련된 토론이 열린 한글 프로젝트에서 시작되었습니다.

관심있으신 분 참여바랍니다 :>

http://kldp.net/projects/hangul/

http://lists.kldp.net/pipermail/hangul-hackers/2006-October/thread.html

:-$ PuTTY에서 쓸 수

글쓴이: purewell / 작성시간: 화, 2006/11/07 - 10:20오전

:-$ PuTTY에서 쓸 수 없다는게 참 아쉽습니다.
_____________________________
언제나 맑고픈 샘이가...
http://yubink.com - 강아지 필요하세요?
http://purewell.biz - 헙!!

_____________________________
언제나 맑고픈 샘이가...
http://purewell.biz

이것 참...

글쓴이: jachin / 작성시간: 금, 2006/11/24 - 10:50오전

매번 신세지게 됩니다. (_ _)

어서 몸으로 떼우는 방법을 터득해서 도움이 되어 드릴 수 있도록 노력하겠습니다.
====
( - -)a 이제는 학생으로 가장한 백수가 아닌 진짜 백수가 되어야겠다.

한자를 보고 싶은 사람은 어떻게 하지요?

글쓴이: 돌부리 / 작성시간: 수, 2007/05/02 - 11:40오후

구슬체를 사용하면서, 한자 글씨도 원래대로 보여주게 할 수 있는 방법(설정?)은 없을까요?
구슬체에서는 한글을 사용하고, 다른 글꼴에서는 한자를 사용하게 하는 방법이라든지...

경우에 따라 한자를 표기할 필요가 있어서요...

font matching을 하세요

글쓴이: keizie / 작성시간: 목, 2007/05/03 - 12:13오전

http://wiki.kldp.org/wiki.php/FontConfig 에서 글꼴 매칭이라고 나온 부분을 참조하세요.

개념을 설명하자면, 어떤 글꼴 이름에 '영문만 있는 글꼴 A'와 '한자만 있는 글꼴 B' 그리고 '한자영역에 한글을 채운 글꼴 C'를 차례로 붙이면, '영문만 있는 글꼴 A'를 쓰면서 한자영역을 호출했을 때 FontConfig는 한자영역에 대해서 B에 해당하는 glyph을 반환합니다.