KTUG마당은 KTUG를 방문하는 모든 이용자가 대화를 나누고 소식을 전하는 곳입니다.
- 로그인 없이 자유롭게 글을 읽고 쓸 수 있는 철학은 처음과 같이 계속됩니다.
- Team Blog의 글을 이곳 게시판의 "정보글"로 모았습니다. Team blog는 기고자가 올린 글에 질문을 받는 부담을 줄이기 위하여 댓글을 허용하지 않았습니다. 그러나 이곳 게시판으로 모으면서 댓글을 달 수 있습니다. 게시물을 작성하실 때 댓글을 원하지 않으시면 댓글을 허용하시지 않으시기를 바랍니다. 또한 불필요한 소모성 댓글을 달지 않도록 주의하여 주시기를 바랍니다.
- TeX과 관련된 질문이나 답변은 QnA 마당을 이용하십시오. TeX과 관련된 질문은 지웁니다
- MathJax를 이용한 수식조판을 사용하실 수 있습니다. 여기를 참조하세요.
- 스팸 글을 막기 위하여 짧은 시간 내에 다시 글이 등록되는 IP를 막거나, 광고 글을 막기 위하여 금지어로 .com, .net 등을 설정하고 있습니다. 다소간의 불편함이 있으시더라도 양해 바랍니다.
- 금지어에서 stackexchange, stackoverflow, ctan, overleaf, , github, google.com, gmail.com, .org, .io, sil.org, wiki.com, tistory.com등은 해제하였습니다.
- 사용하는 편집기는 CKeditor입니다. 편집기에서 [enter]를 누르면 <p> 태그가 들어가고, 문단으로 생각하고 한줄을 비웁니다. 글줄만 바꾸려면 shift-enter 를 누르시면 <BR>가 들어가므로 용도에 맞게 나누어 쓸 수 있습니다.
자유글 한글의 분해와 조립
2015.06.14 20:12
아래 글 http://www.ktug.org/xe/index.php?document_srl=207243&mid=KTUG_open_board 의 과제를 해결하려면, 한글 문자를 초/중/종성으로 분리해야 합니다.
잘 알려진 대로 한글 완성형 음절문자 영역의 11172자는 한글이 사전순으로 배치되어 있기 때문에, 다음 공식으로 초/중/종성 분리가 가능합니다. 나눗셈은 정수 나눗셈입니다.
basecode = 문자코드 - 44032
초성코드 = basecode / 588
중성코드 = (basecode - 588*초성코드) / 28
종성코드 = (basecode - 588*초성코드 - 28*중성코드)
expl3로 다음과 같이 구할 수 있습니다.
\cs_new:Npn \get_lvt_code:n #1
{
\int_set:Nn \g_cho_int { \int_div_truncate:nn { #1 } { 588 } }
\int_set:Nn \g_jung_int { \int_div_truncate:nn { #1 - 588 * \g_cho_int } { 28 } }
\int_set:Nn \g_jong_int { #1 - \g_cho_int * 588 - \g_jung_int * 28 }
}
====
이번에는 자모조합 코드(첫가끝)로 입력된 한글을 완성형 음절문자로 대응시키는 방법입니다.
우선 자모문자의 코드를 각각 얻어서 이로부터 다음 연산을 합니다.
초성코드 = 초성자모문자코드 - 4352
중성코드 = 중성자모문자코드 - 4449
종성코드 = 종성자모문자코드 - 4519
음절문자코드 = (초성코드 * 21 + 중성코드) * 28 + 종성코드 + 44032
====
첨부파일을 참고하십시오. hangultest.tex
메르스가 창궐하는 이 때, 오프라인 스터디 모임은 (아마도) 무기연기되는 것 같습니다.
그래서 지면으로 토론을 대신합니다.
댓글 17
-
DohyunKim
2015.06.15 02:14
-
nanim
2015.06.15 05:53
-
세벌
2015.06.15 06:10
고맙습니다.
-
그로몹
2015.06.15 10:39
첫가끝이라는 것으로 입력하면 코드가 달라지나요?
왜 이런 이야기가 유니코드에도 나오는 것인가요?
-
두텁
2015.06.15 10:46
그로몹 선생님, 유니코드에 한글이 두 영역에 들어 있습니다. 한 영역은 음절 영역으로 11172자의 완성된 음절이
가나다사전순으로 나열되어 있습니다. 말씀하신 '첫가끝'은 자모 영역에 해당합니다. 애초에 자모 영역만 있었다면 위의 일은 불필요하죠. 그래서 이런게 왜 필요한가 의문을 가지게 되시는 겁니다. 그런데 OS X를 제외한 다른 운영체제에서는 주로 음절 영역을 사용합니다. 그래서 자모 분해를 하려면 이 글에서 소개하는 작동이 필요합니다. 물론 다른 언어들에서는 대개 이보다 더 고수준의 변환 방법을 제공합니다. -
nanim
2015.06.15 11:00
유니코드의 한글 관련 부분은 모두 세 부분(크게 보아서)입니다.
1. 한글호환자모: 주로 한글 자모 낱자를 표현하는 데 사용합니다. 우리가 한글로 사용하는 음절 문자를 나타내는 것이 아니므로 논외로 합니다.
2. 한글음절문자: 이게 우리가 흔히 '한글'이라고 부르는 것이고 가에서 힣까지 11172자가 차례로 들어 있습니다.
3. 한글 자모: 이것은 조합가능한 자모를 정의하고 있습니다.
그 결과, 유니코드로 한글을 표현하는 두 가지 방법이 생겨나게 됩니다. 예컨대 '가'를 \uAC00으로 표현하는 방법과, \u1100\u1161로 표현하는 방법이 그것입니다. 음절문자 코드를 사용하면 2바이트면 모든 현대한글을 다 표현할 수 있지만 자모조합으로 한글을 표현하면 초성에 2+바이트, 중성에 2+바이트, 종성에 2+바이트, 최소 4~6바이트가 필요하고요, 인코딩 방법에 따라서(예를 들어 UTF-8이면) 유니코드 2바이트가 3바이트로 인코딩되니까 크기가 꽤 늘어납니다. 한 글자를 표현하는 데도요.
어쨌든 이렇게 한글 자모 문자로 한글을 표현하는 방법을 통칭 "첫가끝"(공식 표현은 아닌 것으로 알고 있습니다)이나 LVT라고 부르는데, 옛한글과 같이 음절 문자에 정의되지 않은 한글을 표현하는 데는 이 방법밖에 없습니다. 초/중/종성 각각 하나의 코드가 필요하여 세벌이라고도 할 수 있을지 모르겠습니다.
현대 한글 음절 문자는 초성 19자, 중성 21자, 종성 28자를 가지고 만들 수 있는 모든 글자를 포함합니다.
조합용 자모에는 이보다 훨씬 많은 초/중/종성을 정의하고 있어서 지금은 사라진 옛한글도 자유롭게 표현할 수 있습니다. 조합 가능한 글자도 수백만자에 이르지요.
왜 이런 이야기가 유니코드에 나오는가 하면, 둘 다 표준이기 때문입니다.
-
두텁
2015.06.15 10:51
좋은 예제 감사합니다. expl3가 함수형 언어로부터 영향을 많이 받았음이 절실히 드러나네요. 함수가 없고 모두 프로시져라 전역 변수를 잘 이용해야 하는군요.
-
DohyunKim
2015.06.15 12:20
흠. \clist_pop:NN 은 리스트의 맨 앞 것을 꺼내는군요. 일반적으론 pop이 맨 뒤 거를 꺼낸다는 의미지만서도.
expl3 개발자들이 왜 이름을 이렇게 붙여야만 했는지 의문입니다. \clist_shift:NN 이 낫지 않았을까나.
-
nanim
2015.06.15 12:31
clist 자료형에 데이터를 추가하는 데는 \clist_put_right:Nn \clist_put_left:Nn이 있습니다. 이것은 그냥 일반적인 리스트로 clist를 사용하는 것입니다.
그런데 clist를 스택처럼 사용할 때는 \clist_push:Nn과 \clist_pop:NN이 쓰입니다.
이 스택의 top이 leftmost인 거죠.
seq 자료형은 좌우 양쪽을 top으로 쓸 수 있어서 스택뿐 아니라 큐로도 사용할 수 있게 되어 있습니다.
즉, \seq_pop_left:NN과 \seq_pop_right:NN이 있습니다.
그리고 \seq_push:Nn과 \seq_pop:NN도 정의되어 있는데 이것은 leftmost를 top으로 사용하는 스택입니다.
tl 자료형은 원래 스택이나 큐로 사용할 목적으로 만들어진 것이 아닌 듯합니다. 그래서 \tl_head:n과 \tl_tail:n밖에 없습니다. pop/push 명령이 없네요.
-
JangNa
2015.06.15 12:47
Comma lists(clist)를 스택으로 사용할 때는 성능상의 이유로 왼쪽을 top으로 사용하다고 하네요.
Comma lists can be used as stacks, where data is pushed to and popped from the top of the comma list. (The left of a comma list is the top, for performance reasons.)
그러니까 성능상이 됐든 뭐가 됐든, 그건 난 모르겠고, (개콘의 경비아저씨 -_-;)
왼쪽을 탑으로 사용할꺼면 pop/push 연산의 이름을 shift/unshift로 해야하지 않느냐?
꼭 그런 것은 아니지만, 왼쪽이 탑일 때는 shift/unshift, 오른쪽이 탑일때는 pop/push라는 이름을
통상적으로 사용하니까.
-
yihoze
2015.06.15 13:07
크누스 선생 스스로가 인정했듯이 glue보다는 spring이 더 적절한 말인데, 이미 굳어버려서 그냥 glue로 가는 걸로 ...
-
DohyunKim
2015.06.15 13:36
@yihoze 그게 정답인 거 같네요. 텍니션다운 비유시구요.
각설하고... xelatex으로 이 문서를 조판하면 첫가끝으로 입력된 한글 부분이 디폴트 나눔명조 글꼴로도 잘 표시됩니다. 루아텍은 안 될 겁니다.[1]
이는 xetex이 내부적으로 유니코드 정규화(노말라이제이션)을 수행하고 있다는 말이겠죠. 이렇게 우리가 모르는 사이에 우리 배후에선 분해/조립(이걸 전문용어로는 정규화라 한다고 알고 있슴다.) 알고리듬이 상시적으로 작동하고 있다고 하겠습니다.
[1] 결국 루아텍도 지텍처럼 harfbuzz 등 기존에 인정받은 라이브러리들을 받아들여야 할 텐데, 아직은 기약할 수 없는 상황입니다. 루아도 알고 C도 아는 누군가가 나서서 마음먹고 개발하면 금세 될 거 같긴 한데... 이 상황을 타개하지 않으면 지텍을 버리고 루아텍으로 옮겨가는 것은 “아직 아니요”라고 말할 수밖에 없을 거예요. 참고: https://goo.gl/nTHMkt 여기에 최근 harfbuzz도 들어가긴 했어요.
-
nanim
2015.06.15 13:51
한글 처리와 관련하여, 말씀하신 그런 일에 DohyunKim께서 적지않은 기여를 해오신 것으로 알고 있습니다.
감사와 존경의 말씀을 드립니다.
-
두텁
2015.06.15 14:44
기술적으로 필요한 건 harfbuzz의 lua 바인딩인가요?
-
DohyunKim
2015.06.15 17:43
lua 바인딩은 당근 가능합니다. 다만 라이브러리 컴파일할 때 루아텍의 루아 버전에다 링크시켜야지 그렇지 않으면 두 버전의 루아끼리 충돌이 일어난다고 알고 있습니다. 그래서 만든 게 swiglib 프로젝트고요.
기술적 문제보단 정책의 문제가 더 큽니다. 우선 루아텍 개발팀 (특히 한스 하겐이 그렇죠. 루이기는 관대한 듯)이 외부 라이브러리에 대해 달갑지 않게 생각하고 있습니다. 또 텍라이브 팀도 새로운 라이브러리를 컴파일해서 tex live에 넣는 데 부담을 가지는 거 같습니다. 아무 라이브러리나 다 넣게 되면 매년 한 차례긴 해도 관리해야 할 것들이 무한대로 폭주할 수 있겠죠. 특히 이들이 대개 라틴 스크립트 권의 사람들이란 걸 감안하면 이해가 가는 면도 없지 않습니다. 현재 한스 하겐의 오픈타입 처리 코드 (쌩 루아 코드임다)가 라틴 문자는 대개 문제 없이 처리하니까요.
하지만 애초의 오리엔탈 텍이란 이름에 걸맞지 않게 아랍, 인도, 동남아 등등 complex script 쪽으로 가면 문제가 달라지죠. 한글은 우리의 세종대왕 덕분에 그리 복잡하지 않게 구현이 가능하기 땜에 현재의 쌩 루아 코드로도 대체로 무난하게 처리가 됩니다.(tone mark 제외하면요. tone mark 처리는 현재 luatexko가 하고 있습니다.) 다만 한글 처리 관련해서 심각한 문제가 발견되면 한스 하겐에게 사적으로 메일 보내서 버그를 잡고는 있습니다만, 이것도 나름 힘든 일이라 웬만하면 그냥 두기보기도 합니다. 여하튼 제대로 잘 작동하지 않는 스크립트가 많고 해서 사람들이 이미 성능이 공인된 하프버즈를 자꾸 생각하게 되는 것이구요.
https://goo.gl/jfyMKL 이런 걸 만들어서 테스트해보는 사람도 있더군요. 또한 http://goo.gl/0KkMfb 및 관련 글타래도 관심있으면 봐 보세요. 부정적인 기류가 완연하죠. 그래서 안 되겠다 싶어 최근에 한스 하겐에게 몇 건 버그 보고해서 버그잡이도 했어요. tex live에 아직 반영은 안 되고 있지만요. 음. 쓰다보니 게시판의 성격에 맞지 않게 너무 깊은 데까지 와 버렸네요. 하지만 케이턱엔 고수분들이 많으니까 뭐...
-
그로몹
2015.06.15 14:01
한글 사용과 처리에 대해서는 여기 계신 모든 분의 생각이 반영되고 있다고 느낍니다.
몇 분의 놀라운 능력이 이 모든 생각을 현실로 바꾸고 있다고 보입니다.
감탄스럽습니다.
-
likesam
2015.06.15 17:39
항상 감사드리면서 사용하고 있습니다.초기 LaTeX에서 한글이 식자되게 하기 위한 몇몇 분들의 노력에도 감사하였지만, 지금은 그 때와 비교하면 너무도 자연스럽게 설치하고 사용할 수 있어, 감사함을 잊는 경우도 생겨나는 가 봅니다.
| 번호 | 제목 | 글쓴이 | 날짜 | 조회 수 |
|---|---|---|---|---|
| » |
한글의 분해와 조립
[17]  | nanim | 2015.06.14 | 4993 |
| 613 | 왜 우리는 tikz 따위에 더 이상 열광하지 않는가? [5] | yihoze | 2015.06.15 | 3597 |
| 612 | TeXLive 2015 배포되었다고는 하네요. [12] | 하늘연 | 2015.06.12 | 3864 |
| 611 | 명령 스무 개만 알면 [9] | nanim | 2015.06.14 | 3635 |
| 610 |
게임 트리 그리기 1-1
[14] | ischo | 2015.06.10 | 7821 |
| 609 | lshort Support for Korean KTUG 궁금증... [22] | 세벌 | 2015.06.09 | 3786 |
| 608 | 김 군 [9] | yihoze | 2015.06.12 | 3586 |
| 607 |
게임 트리 그리기 1
[10] | ischo | 2015.06.09 | 4372 |
| 606 | 코딩의 즐거움: 제1차 라텍 스터디 과제 [19] | nanim | 2015.06.09 | 3785 |
| 605 | 김군이 바라본 memoir와 oblivoir [1] | yihoze | 2015.06.12 | 3337 |
| 604 | KTUG mystery [3] | 세벌 | 2015.06.12 | 3479 |
| 603 | karnes 님 어디 계셔요? [5] | 세벌 | 2015.05.21 | 3137 |
| 602 | KTUG 사이트의 베스트 게시물은 어떤 것인가요? [6] | Karnes | 2009.12.30 | 32403 |
| 601 | Introduction to LaTeX:라텍 입문 [6] | JangNa | 2015.06.11 | 12788 |
| 600 | 2015 한국텍학회 정기총회 및 KTUG 컨퍼런스 [1] | 관리자 | 2015.01.15 | 7795 |
| 599 | 예의에 대해서 [16] | 멀리본다 | 2015.06.08 | 3407 |
| 598 | Thank you, Hermann Zapf [8] | 에드 | 2015.06.06 | 3355 |
| 597 | 편집하지 않으면 표절 [1] | yihoze | 2015.06.09 | 3204 |
| 596 |
ichingforyou 확장판
[3] | nanim | 2014.07.25 | 21988 |
| 595 | 주변에서 LyX에 대한 반응 [12] | 하늘연 | 2015.06.09 | 3889 |
유니코드 조합자모 규정: http://goo.gl/WqydC4
예제코드도 있어요. 자바라고 하네요: http://goo.gl/ob42IW