KTUGFaqKTUG FAQ
![[http]](/wiki/imgs/http.png)
DVIPDFMx › TeXmacs&value=Yhchoe/TitleIndex › ��됬맦&value=파일업로드 › ActiveX&value=ActiveX › ViEditor › 옛한글처리
제가 현재 찾을 수 있는 범위에서 간단한 목록을 만들어보겠습니다. 참고가 되시면 좋겠고, 부족한 것은 보충해주십시오.
이 논의는 원래 KSX1001 범위 밖의 한글 쓰기와 병행해서 진행되었지만, 이 글에서는 옛한글 처리와 관련된 것만 정리하겠습니다.
[편집]
1 글꼴의존적 방법 ¶
이 "폰트 의존적 방법"이라는 명칭은 제가 붙인 것인데, MS-Word나 아래아한글(HWP)에서 "고어"를 처리하는 방법과 동일한 방법을 TeX/Omega를 이용해서 조판하는 방법을 가리킵니다.
"고어"라는 표현은 저도 마음에 안 듭니다. 심정적으로는 신정식 님의 "1933년 이전 한글 표기법"에 동의하지만 너무 길어서.... 중세한글문자라는 것도 "중세"라는 단어가 가진 함축 때문에 문제가 될 수 있겠는데.... 최근 모두들 사용하는 "옛한글"도 괜찮은 것 같습니다. 이 글에서는 고어, 중세한글, 옛한글을 엄격하게 구분하지 않고 혼용하겠습니다.
이 때 입력 엔코딩은 UTF-8이지만, 옛한글에 해당하는 코드는 폰트 자체에 하드코딩된 것을 이용합니다. 그러므로 사실상 이 방법으로 입력을 하려면, U+를 이용해서 VIM이나 다른 에디터를 이용할 수도 있겠지만 실제로는 너무나 번거로워서 WORD나 아래아한글을 그대로 이용하는 것이 현실적인 대안이 됩니다.
폰트로부터 Unicode.sfd에 정의된 순서로 글자들을 추출하고 DVIPDFMx(당시는 dvipdfm-cjk)를 이용하여 조판을 합니다.
이 방법이 아마도 제가 알고 있는 한 옛한글을 TeX으로 조판한 최초의 예가 아닌가 합니다. 이 방법을 처음 선보인 ChoF 님의 글입니다.
49
49
글꼴의존적인 방법은 말 그대로 글꼴에 들어 있는 고어 문자를 이용하는 것입니다. 여기서 사용된 글꼴은 nBatang 또는 nGulim이었는데, 이 글꼴에 포함된 고어 문자가 일정한 규칙을 따르는 것도 아닌 데다가, 표준도 아니어서, TeX/Omega에서 사용하기에는 상당히 망설여졌습니다. 사실은 TeX/Omega에서 처리하기 위하여 WORD나 한/글로 입력한다는 것 자체가 정서적으로 견디기 어려웠던 점도 있습니다.^^
조금 부연 설명을 첨가하자면, 더 좋은 방법이 이미 존재하는데, PUA영역을 쓰게끔 글꼴과 소프트웨어를 만든 것은 사용자의 눈을 가리운 것입니다. 글꼴회사와 M$의 맞장구로밖에 볼 수 없겠죠 (즉, 정서에 맞지 않지만, 엉터리 방법이라는 말입니다) 윈도우즈에서 사용할 수 있는 Indic Script를 쓰는 방법이 GSUB를 쓰는 방법이고, 지금 하려는 GSUB를 구현하는 것은 새로운 것을 고안하는 것이 아니라 이미 있는 방법을 써먹자는 것이죠. (GSUB/GPOS/GDEF 등등은 트루타입 오픈이라는 마이크로소프트/아도브/애플의 표준 제안입니다) --WkPark
[편집]
2.1 준비과정 ¶
옛한글의 코드는 폰트-의존적 코드여서는 안 된다는 데 무언의 합의가 있었고, 그것은 자연스럽게 첫가끝을 사실상의 표준으로 받아들이도록 만들었습니다. 이 과정에서 첫가끝코드의 중세국어 또는 옛한글 입력 방법과 관련하여 중요한 진전이 있었습니다. 윈도 사용자에게는 Yudit의 중세국어 입력 방식이 정말 반가운 "사건"이었는데 이것은 신정식 님의 노력으로 가능해진 일로 압니다. 105
(신정식 님과 박원규 님께서 주로 기여하신 중세국어 입력 및 화면 디스플레이 문제에 대해서는 저보다 박원규 님께서 정리해주시면 감사하겠습니다. 특히 ViEditor과 Mozilla 관련된 부분이 이 글에 추가되었으면 합니다.)
105
(신정식 님과 박원규 님께서 주로 기여하신 중세국어 입력 및 화면 디스플레이 문제에 대해서는 저보다 박원규 님께서 정리해주시면 감사하겠습니다. 특히 ViEditor과 Mozilla 관련된 부분이 이 글에 추가되었으면 합니다.)
이 패치된 ttf2tfm은 MiKTeX-KTUG에 포함되어서 배포되고 있습니다.
[편집]
2.2 mslvt 패키지 ¶
ChoF 님께서 HLaTeX 확장판(HLambda)을 이용하면서, 첫가끝 코드에 해당하는 문자를 oGulim 또는 oBatang에 있는 조합용 자소를 조합하여 조판할 수 있는 방법인 mslvt 패키지를 테스트용으로 올리셨습니다.
99
99
이 뒤로 한동안 이 문제에 관한 논의가 중단되었다가, 박원규 님의 은바탕 글꼴(은글꼴) 발표와 더불어 논의가 재개되기 시작했습니다.
좀 명확히 집고 넘어갈 것이 있는데, oGulim글꼴을 쓴다는 것은 이미 글꼴 의존적인 방법이라는 뜻이였습니다.
oGulim은 한양에서 만든 것이고, 글꼴 배치도 표준적이지 않으며, GSUB를 지원하지 않고 반드시 oGulim의 글꼴 조합 법을 알아야, 혹은 지원해야 이 글꼴을 쓸 수 있습니다.(mslvt가 이 글꼴을 지원하는 것이 되겠군요) 이 글꼴에 GSUB를 넣으면 oGulim도 일반적인 조판법으로 글꼴을 사용할 수 있게 됩니다 (mslvt없이) (oGulim을 위한 GSUB를 시범삼아 집어 넣을까, 혹은 시간이 걸리더라도 새로 글꼴을 만들고 그곳에 GSUB를 넣어야 할까 망설이고 있습니다. ^^;;)
jamoUnBatang.ttf나 CODE2000.ttf는 GSUB가 들어있지 않는데도 간단한 TeX조판에 쓸 수 있는 이유는, 첫가끝코드가 합리적으로 개발되었기 때문이지 글꼴의 zero-width의 트릭 때문은 아닙니다. UniCode 스펙에 중성과 종성은 zero-width라고 되어있습니다. (이게 최근에 신정식님에 의해 고쳐진 것인지는 잘 모르겠군요.) xterm이나 ViEditor에서 첫가끝 한글을 구현이 간단했던 이유이기도 하지요. --WkPark
[편집]
2.3 은글꼴과 CJK패키지 ¶
이 방법은 중성과 종성 문자에 width=0을 부여하고 해당하는 코드가 들어오면 거기에 맞추어서 자소 문자를 찍어주는 방법으로 중세문자를 표현하는 방식이라고 생각됩니다. 즉 CJK패키지 자신이 중세 국어를 이해하는 것은 아니고 다만 코드에 부여된 글꼴 상의 문자를 불러주는 것인데, 그런 점에서는 글꼴-의존적인 점이 있다고 생각됩니다. 그러나 이것은 어디까지나 첫가끝 코드를 처리하는 방법 가운데 하나에 불과하므로 "글꼴의존적 방법"이라고 부를 수는 없겠지요.
[편집]
2.4 UniCode 엔코딩(UTF-8)을 이용한 용비어천가의 조판 ¶
이것이 
1089에서 제가 한 일이었는데, 첫가끝코드로 입력된 중세문자는 mslvt를 이용하고 u8hangul을 쓰는 점에서는 맨 처음의 mslvt와 같은 것이지만, mslvt에서는 UKS-HL.sfd 문자 정의를 이용하여 문서를 조판하도록 하였던 것을 Unicode.sfd를 사용함으로써 KSX1001 및 UniCode 상의 모든 한글 문자, 그리고 거기에다가 KS X 1002:1991로도 표현하지 못하는 한자까지 처리한 것입니다.
1089에서 제가 한 일이었는데, 첫가끝코드로 입력된 중세문자는 mslvt를 이용하고 u8hangul을 쓰는 점에서는 맨 처음의 mslvt와 같은 것이지만, mslvt에서는 UKS-HL.sfd 문자 정의를 이용하여 문서를 조판하도록 하였던 것을 Unicode.sfd를 사용함으로써 KSX1001 및 UniCode 상의 모든 한글 문자, 그리고 거기에다가 KS X 1002:1991로도 표현하지 못하는 한자까지 처리한 것입니다.
현재까지 논의된 범위에서는 이 방법으로 만들어진 용비어천가가 중세문헌(문자가 아니고)을 조판하는 데 비교적 성공적인 결과를 보여주었다고 생각합니다.
[편집]
3 해결 안 된, 해결되어야 할 문제들 ¶
- CJK패키지에 mslvt와 유사한 방식으로 첫가끝 처리 루틴을 만드는 것은 어떨까 하는 것이 신정식 님과의 대화 중에 제가 말씀드렸던 것입니다.
- 은글꼴(바탕)에 포함된 고어 자소 부분이 좀더 발전하였으면 합니다. 신정식 님께서는 PUA 영역을 이용하여 oGulim과 같은 방식의 고어 자소 처리 방식을 제안하셨고 박원규 님께서는 GSUB 이용방법을 발견하였다고 하시므로, 이 부분에 큰 발전이 있을 것으로 기대합니다.
- 은글꼴(바탕)의 한자 문제가 조금이라도 개선되기를 기대합니다. 중세문헌 처리에서 정말 심각한 것이 한자 문제더군요.
- 첫가끝으로 입력된 문자가 행끝에 오면 Lambda가 죽어버리는 현상을 발견했습니다. 아마도 첫가끝의 코드들을 또 행끝에서 나누려고 시도하는 모양입니다. 이 부분을 처리하는 루틴이 추가되어야 할 듯합니다.
- u8hangul(HLambda)는 시험판이고 그래서 기능상의 제약이 좀 많습니다. 실용적으로 사용하려면 이 UniCode용 HLaTeX이 조금 더 발전해야 하리라고 생각합니다.
- 중세문헌의 라이브러리가 만들어졌으면 좋겠습니다. 현재까지 제가 만든 것은 훈민정음언해와 용비어천가뿐인데, 제가 아는 한 중세문헌을 첫가끝으로 처리한 텍스트 라이브러리 자체가 희귀한 상황이라고 생각됩니다.
- 굵은 글꼴 문제는 심각합니다. 현재 중세국어 조판에 사용되는 nGulim, oGulim, nBatang, oBatang이 모두 굵은 글꼴이 없지요.
- ChoF 님의 mslvt2.sty는 첫가끝 코드 중에서 현대 한글에 해당하는 글자는 nBatang(nGulim)의 글자로 치환하여 식자되도록 설정되어 있습니다. 그렇다면 첫가끝코드로 입력된 글자 중에서 현대 한글로 바꿀 수 있는 글자는 바꾸는 스크립트를 작성할 수 있다면 좋겠다는 생각이 듭니다. ChoF 님께서는 첫가끝 조합된 글자를 nBatang/nGulim에 있는 고어 문자로 치환하는 스크립트도 생각하셨던 것 같은데, 이것은 도저히 불가능한 일처럼 보입니다.(시간이나 비용 면에서....)
이 부분은 신정식님께서 작업중이셨던 것으로 알고 있습니다. --WkPark2004-09-12 오랜 시간이 지나서 불현듯, 갑자기 이 계획이 현실로 옮겨졌습니다. 6000여자의 한양PUA 완성형 옛한글 글리프를 한글 자모조합 코드로 바꾸는 변환 테이블이 작성되고 있습니다. HanyangPuaTableProject. --Karnes
- 이밖에 해결되어야 할 문제가 있다면 생각나는 대로 추가하겠습니다. 토론을 기대합니다.
.png ":)")
일본의 미운 
