KTUGFaqKTUG FAQ
You have an ambitious nature and may make a name for yourself.
FrontPage › 옛한글처리/Discussion
2010-03-03 옛한글처리에 있던 내용을 이쪽으로 옮깁니다.
TeX/Omega LaTeX/Lambda를 이용한 중세한글처리에 대하여 2003년 3월, 게시판에 올렸던 글을 바탕으로 이후의 발전과정을 요약하고 보충한 것입니다. from 
1096 --Karnes
1096 --Karnes
제가 현재 찾을 수 있는 범위에서 간단한 목록을 만들어보겠습니다. 참고가 되시면 좋겠고, 부족한 것은 보충해주십시오.
이 논의는 원래 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 DHHangul 페이지에서 이루어진 옛한글 관련 토론 ¶
*주* 아래 토론은 KTUGFaq DHHangul 페이지에서 이루어진 토론입니다. 매우 중요한 논의라고 생각하기 때문에 이 위치에 인용해두겠습니다. 이 토론은 2003.12.27부터 2004.1.17 사이에 이루어진 것으로 기억합니다. 이 논의 중에 등장했던 옛한글 처리 방식은 이제 OpenType GSUB/GPOS 방식을 제외하고 모두 구현되었습니다. --Karnes
이제 중세국어 처리에 뭔가 일치된 의견이 필요하지 않은가 하는 생각이 듭니다. 실용적 관점에서 보자면 중세국어를 (완성형으로) 포함하고 있는 글꼴은 한양계열의 몇몇 글꼴밖에 없는 것으로 알고 있습니다. MS nBatang, 한컴바탕, hybatang 이 셋은 사실상 동일한 글꼴이지요? 그리고 nGulim 정도인데, 이것을 첫가끝 코드와 붙여쓰려면, 아무튼지 코드변환테이블이 있어야하는 것이라는 생각이 드네요. 게다가 현재 대부분의 국어학 관련 문서들(HTML, PDF, HWP)은 이 폰트에 하드코딩된 코드를 이용하는 것만을 보았습니다. 첫가끝에 미련이 많은 저로서는 코드변환테이블을 만드는 막노동(언제 끝날지 알 수 없는 일이겠지만요)을 감수하고서라도, 이 방식을 누군가 구현해야되지 않는가 생각하고 있습니다. 아무튼 DHHangul은 은바탕 자모의 LVT 방식으로 발전할 것인지 아니면 MS-LVT(obatang, ogulim)를 이용할 것인지 그도 아니면 한양 글꼴의 옛한글(이것도 사실은 정말 버리기 아깝습니다)을 어떻게든 이용하는 방식으로 갈 것인지 궁금합니다. 이 셋을 모두 만족시키는 방법이 있을라나요? --Karnes
위에 적으신 것 가운데 답이 없는데요
옛한글 처리는 엉성하게 만들어둔 것입니다. 아직 제대로 옛한글을 지원하는 공개글꼴이 없기 때문이죠. .png ":-)") 위에 적으신 어느 방식을 써도 PDF에서 한글 자모 검색이 안 되는 문제를 해결할 수 없으니까요. 중간 단계로 여러 가지를 쓸 수 있겠지만, 최종적으로 opentype GSUB/GPOS를 (PUA가 아닌) 써야 할 것입니다. 그런데, 아직 Omega/Lambda 및 관련 도구에서 그것이 가능하지 않으므로 별 진전이 없는 것이지요. 제가 작년 봄에 KTUG 게시판에 올린 글에서 한가지 가능성을 제시하기는 했습니다. 어쨌든, 이 문제는 남아시아와 동남 아시아의 여러 표기 체계 처리를 위해서도 꼭 해결해야할 문제이므로, 우리가 나서지 않아도 - 물론, 우리가 해서 남아시아 및 동남 아시아 표기 체계 문제까지 한꺼번에 해결할 수 있다면 좋겠지요- 조만간 뭔가 답이 나오리라고 봅니다. -- 신정식
opentype 지원은 1970년대 문자 개혁 이전 그리스어 표기 (Polytonic Greek), 중세 유럽 문헌, 여러 아프리카 언어 표기(라틴 알파벳 사용), 모음 표시가 붙은 히브리와 아랍 글자로 적힌 문헌(성서와 코란이 대표적인 보기) 등을 위해서도 필수적이므로 진전이 있으리라고 봅니다. --- 신정식
 그러나 글꼴만 적당한 것이 주어진다면 mslvt방식을 차용하여 지원할 생각입니다. 기술적인 면에서는 이미 결론이 나 있는 것으로 보입니다. ![[http]](/wiki/imgs/http.png) UnBatangOdal과 같이 폰트가 만들어질 것입니다. 이 폰트를 지원하는 otp는 mslvtc를 약간 고치고 mslvta와 mslvtb는 그대로 도용하여 만들 수 있습니다. 문제는 만족스런 품위를 갖는 폰트를 언제 누가 만들 것인가하는 문제입니다...(한숨) 그리고 hybatang의 PUA 옛한글은 저로서는 지원할 생각이 없습니다. 알고리즘을 찾기가 어려워서 아마 한 글자씩 눈으로 확인하면서 방대한 테이블을 만들어주어야 할 것입니다. 신정식님이 예전에 이 테이블을 만든다고 하셨는데 어떻게 되었는지 모르겠네요. --DohyunKim
저도 신정식 님의 그 작업이 궁금했습니다. 아무튼 mslvt 방식이 바람직한 방향인 것은 틀림없는 듯합니다. 우선 ogulim이나 UnBatangOdal에 대해서 OTP를 만들어서 올려주시면 어떨까요? 이 문제가 해결되면 한글 TeX 사용에는 중대한 진전이 있는 것이라고 저는 생각합니다.
.png ";)") --Karnes
오랫만입니다. 그 작업은 그리 힘든 것은 아닙니다. (시간은 많이 걸립니다.) 그냥 Ngulim 글꼴 표를 하나 프린트한 다음에 6000자 정도를 입력하고, 그 입력 파일에 대해서 필터를 걸어 표를 자동 생성하면 됩니다. 하지만, 글꼴 라이선스 문제 때문에 Windows가 아닌 플랫폼에서 쓸 수 없어서 - 한양 시스템과 MS Korea에 모두 연락을 해 보았지만, 긍정적인 답을 얻지 못 했습니다. - 그 뒤에 작업을 진행하지 않습니다. 그래서, 모질라에서도 Ogulim/Ngulim 대신 Unbatang-odal을 쓰도록 바꾼 패치를 넣었고요. 그 과정에서 Unbatang-odal을 위한 변환 테이블도 만들었습니다. (mslvt에 해당하는). 자세한 것은
http://bugzilla.mozilla.org/show_bug.cgi?id=176315를 보십시오. 현재 모질라의 한글 자모 처리 능력은 MS IE보다 더 뛰어납니다. MS IE는 Uniscribe를 이상하게 만들어 놓은 MS 때문에 제한이 많습니다. -- 신정식
|
이러한 논의가 있은 지 거의 10여개월만에 마침내 한양PUA 테이블이 만들어졌습니다. DHHangul은 이 논의 과정에서는 한양PUA를 지원할 생각이 없다고 하였으나 결과적으로 DHHangul 덕분에 한양PUA 글자를 사용할 수 있게 되었습니다. --Karnes 2004-09-23
[편집]
5 해결 안 된, 해결되어야 할 문제들 ¶
- CJK패키지에 mslvt와 유사한 방식으로 첫가끝 처리 루틴을 만드는 것은 어떨까 하는 것이 신정식 님과의 대화 중에 제가 말씀드렸던 것입니다.
- 은글꼴(바탕)에 포함된 고어 자소 부분이 좀더 발전하였으면 합니다. 신정식 님께서는 PUA 영역을 이용하여 oGulim과 같은 방식의 고어 자소 처리 방식을 제안하셨고 박원규 님께서는 GSUB 이용방법을 발견하였다고 하시므로, 이 부분에 큰 발전이 있을 것으로 기대합니다.
- 은글꼴(바탕)의 한자 문제가 조금이라도 개선되기를 기대합니다. 중세문헌 처리에서 정말 심각한 것이 한자 문제더군요.
- 첫가끝으로 입력된 문자가 행끝에 오면 Lambda가 죽어버리는 현상을 발견했습니다. 아마도 첫가끝의 코드들을 또 행끝에서 나누려고 시도하는 모양입니다. 이 부분을 처리하는 루틴이 추가되어야 할 듯합니다.
- u8hangul(HLambda)는 시험판이고 그래서 기능상의 제약이 좀 많습니다. 실용적으로 사용하려면 이 UniCode용 HLaTeX이 조금 더 발전해야 하리라고 생각합니다.
- 중세문헌의 라이브러리가 만들어졌으면 좋겠습니다. 현재까지 제가 만든 것은 훈민정음언해와 용비어천가뿐인데, 제가 아는 한 중세문헌을 첫가끝으로 처리한 텍스트 라이브러리 자체가 희귀한 상황이라고 생각됩니다.
2004-09-12 중세 문헌의 라이브러리는21세기 세종계획에서 말뭉치 자료를 만들고 있다고 합니다.(이기황 님께서 알려주심. 3798) 한양PUA 영역을 이용하여 중세문자를 입력한 것이 문제이지만 변환 루틴이 완성되면 그것도 큰 문제가 되지 않을 것입니다. --Karnes
2004-09-1221세기 세종계획의 국어특수자료 구축 분과 역사자료 말뭉치 개발 과제의 2003년도 연구보고서에 있는 내용입니다.
- 개화기신소설: 아세아출판사에서 영인한 『신소설 飜案(譯)小說』을 저본으로 26개의 신소설 입력
- 자전: 1915년 조선광문회에서 간행한 『신자전(新字典)』 계통의 옥편 1권 입력
- 15세기 문헌: 『월인석보』 20 입력
- 소설류: 『을병연행록』 입력. 총 8책의 필사본으로 홍대용이 1765년(영조 41년)에 서장관으로 임면된 숙부 홍억의 군관으로 수행하여 이듬해 4월에 돌아올 때까지의 기록.
- 신문류: 독립신문 1899년의 7월 이후 부분 중점 입력 이 자료들은 시디롬으로 만들어져 보급될 것입니다. 국립국어연구원에 연락하시면 입수가 가능할 것입니다. --MadToad
- 굵은 글꼴 문제는 심각합니다. 현재 중세국어 조판에 사용되는 nGulim, oGulim, nBatang, oBatang이 모두 굵은 글꼴이 없지요.
- ChoF 님의 mslvt2.sty는 첫가끝 코드 중에서 현대 한글에 해당하는 글자는 nBatang(nGulim)의 글자로 치환하여 식자되도록 설정되어 있습니다. 그렇다면 첫가끝코드로 입력된 글자 중에서 현대 한글로 바꿀 수 있는 글자는 바꾸는 스크립트를 작성할 수 있다면 좋겠다는 생각이 듭니다. ChoF 님께서는 첫가끝 조합된 글자를 nBatang/nGulim에 있는 고어 문자로 치환하는 스크립트도 생각하셨던 것 같은데, 이것은 도저히 불가능한 일처럼 보입니다.(시간이나 비용 면에서....)
이 부분은 신정식님께서 작업중이셨던 것으로 알고 있습니다. --WkPark2004-09-12 오랜 시간이 지나서 불현듯, 갑자기 이 계획이 현실로 옮겨졌습니다. 6000여자의 한양PUA 완성형 옛한글 글리프를 한글 자모조합 코드로 바꾸는 변환 테이블이 작성되고 있습니다. HanyangPuaTableProject. --Karnes
.png ":)")
일본의 미운 
