말로만 듣던 마소 오피스 플러스 팩의 옛한글 글꼴을 구했습니다.

익명 사용자의 이미지

(첨부한 그림을 보세요.)
오른쪽대로 입력하고 글꼴을 바탕 옛한글로 맞춰 주면 왼쪽처럼 보입니다.

한양 PUA에 있었던 완성형 5299자는 내부적으로 완성형 글리프를 담고 있고, 그걸로 치환해서 보여 주는 듯하군요.
또한 한양 PUA 완성형에 없는 ㅇ+ㅓ+ㅃ 같은 글자를 치면 한양 PUA에선 엉성하게 나오지만, 굴림/바탕/돋움/궁서 옛한글에선 그렇지 않습니다.

현 유니코드에 없는 종성 ㅃ 같은 건 종성 ㅂ+종성 ㅂ으로 쓰면 알아서 ㅃ으로 조합됩니다.

글꼴 버그:
1. 굴림 옛한글에선 로마자 소문자가 하나씩 앞으로 밀려 있습니다. (abcde가 bcdef로 보입니다.) 비트맵은 제대로 만들었지만, 실제로 인쇄해 보면 제대로 나오지 않습니다.
2. 굴림 옛한글에선 ㅣㅕㅣ를 쓰면 하나로 조합되지만, 바탕/돋움/궁서 옛한글에선 ㅣㅕ까지만 조합되고 그 뒤 ㅣ는 다음 글자로 분리되는 버그가 있습니다.
3. 바탕 옛한글에선 12pt(16픽셀) 비트맵에서 앞 중성이 뭐냐에 따라 종성 ᇵ이 ᇳ 또는 ㅍㅅ으로 보이는 버그가 있습니다. 이건 1과는 반대로 비트맵의 버그이기 때문에 인쇄하면 정상적으로 나옵니다.

File attachments: 
첨부파일 크기
Image icon Batang Old Hangul test.PNG30.21 KB
JN의 이미지

죄송합니다만 말씀하신 오피스 플러스 팩의 옛한글 글꼴과 박원규님의 글꼴 페이지에 있는 Ogulim.ttf [1] 가 같은 글꼴인지 확인 부탁드립니다.

박원규님 글꼴 페이지에 있는 글꼴은 현대한글과 옛한글로 조합 가능한 6x2x4 벌의 glyph 이 그려져 있습니다. 그런데 이 글꼴을 살펴보면 이 glyph을 사용하기 위한 어떤 정보(GSUB 같은)도 글꼴에 포함되어 있지 않았습니다. 제 생각에 이 글꼴을 사용해서 한글을 표현하기 위해서는 프로그램에서 이 글꼴 전용의 별도의 조합테이블을 가지고서 글꼴을 조합해야 할 거라고 생각합니다. 제가 워드 2003에서 이 글꼴을 테스트할 적에 제가 원하는 한글 풀어쓰기 코드(첫가끝 코드)에 대해서 제대로 동작하지 않는 거 같아서 실망한 적이 있습니다. 지금 올려주신 그림을 보면 그때 제가 뭔가 제대로 테스트하지 못했던 것 같습니다.

또, 올려주신 그림에서 테스트한 워드 문서와 txt문서도 올려주시면 감사하겠습니다. 옛한글 입력을 위해서 어떤 방법을 썼는지도 소개해 주시면 감사하겠습니다.

----
[1] Ogulim.ttf, http://chem.skku.ac.kr/~wkpark/project/font/Ogulim/orig/
글꼴 정보에 한양시스템이 저작권을 가진 걸로 나옴. 테스트용으로 올려져 있음.

에멜무지로의 이미지

Ogulim.ttf와는 다른 글꼴입니다. Ogulim.ttf는 '굴림 옛한글 자모' 글꼴로, 한자 영역에 한글 낱자만 그려져 있는 글꼴입니다. 제가 가진 '굴림 옛한글', '바탕 옛한글', '돋움 옛한글', '궁서 옛한글'은 xx 옛한글 자모 없이도 잘 동작하더군요.

저도 잘은 모르겠지만, 아마 오피스 2002 플러스 팩의 xx 옛한글 글꼴은 한양 PUA의 5299자만 내부에 들어 있고 6*2*4벌의 자모들은 들어 있지 않아서 그 5299자들만 GSUB 테이블에서 완성형으로 치환하고 그렇지 않은 글자들은 xx 옛한글 자모를 쓴 것 같습니다.
2003은 아예 xx 옛한글 자모를 xx 옛한글에 합쳐서 xx 옛한글 하나만으로 옛한글이 잘 표현되는 것 같고요.

http://ko.wikipedia.org/wiki/%EC%98%9B%ED%95%9C%EA%B8%80#.EC.98.9B.ED.95.9C.EA.B8.80_.EC.9E.90.EB.AA.A8_.EA.B3.84.EC.97.B4_.EA.B8.80.EA.BC.B4 글도 참고하세요.

JN의 이미지

답변 감사드립니다. 가지고 계신 ~옛한글 글꼴들을 이곳에 시한을 두고서 올려주시거나, 혹은 제 이메일(bsjeon at hanmail.net)로 보내주시면 감사하겠습니다. 어떤식으로 되어 있는 글꼴인지 살펴 보고 싶은데, 제가 오피스 2003 버전만 가지고 있어서 구하기가 쉽지가 않군요. 쑥쓰러운 부탁이네요...

오늘 이 글타래와 관련해서 이것 저것 찾아보던 중에, 제가 김도현님 홈페이지에서 썼던 답글 [1]이, 특정한 환경에서만 해당되는 지엽적인 사항이라는 것을 알게 되어습니다.

결론적으로 usp10.dll 이라는 Uniscribe 지원 라이브러리의 어떤 버전이 프로그램에서 불리워졌느냐에 따라서 달라질 수 있습니다. 제가 전에 테스트했던 환경이 Windows XP SP2 + Office 2003 SP3 이었습니다. 이 시스템에서 usp10.dll을 검색해 보면 두 군데에서 찾을 수 있었습니다.

c:\windows\system32\usp10.dll   ==> version 1.420.2600.2180
c:\Program Files\Common Files\Mircosoft Shared\Office11\usp10.dll  ==> version 1.471.4063.0
메모장 같은 프로그램에서는 system32 아래의 usp10.dll 이 사용되었으며, 워드 2003에서는 후자의 usp10.dll 이 사용되었습니다. 이게 워드와 메모장에서 같은 텍스트를 불러들이는데도 다르게 처리되는 가장 큰 이유였습니다. 에멜무지로 님께서 첨부하신 그림에서 워드와 메모장에서 다르게 보이는 이유도 이런 이유가 아닐까 짐작해 봅니다.

위키피디아의 Uniscribe 페이지 [2] 를 보면 ucp10.dll의 버전과 이 라이브러리가 포함된 프로그램이 나와 있습니다. 제가 VOLT 1.2 [3] 에 포함된 usp10.dll 로 제 Windows 머신에 있는 모든 usp10.dll 을 교체한 결과 워드 2003, 메모장, IE6 에서 모두 "거의" 같은 출력결과를 얻을 수 있었습니다. 테스트는 박원규님의 글꼴 페이지에 있는 UnBatangOdal 글꼴을 가지고 했습니다. 이글꼴 GSUB 정보가 상당히 잘 들어간 글꼴이더군요. glyph만 예쁘게 그려넣는다면 꽤 쓸만한 글꼴이 될 듯합니다.

더구나 VOLT 1.2에 포함된 usp10.dll 버전이 비교적 최근 버전(1.613.5291) 이었기 때문에, 제가 김도현님 홈페이지에서 적었던 문제들도 나타나지 않더군요. 옛한글은 물론 현대한글에 대한 첫가끝 풀어쓰기 코드의 경우에도 잘 표현됩니다.

참고1.
첨부한 그림 파일은 신정식님 홈페이지의 문서 [4] 를 이용해서 테스트했습니다. "어린 백성"의 "백"자가 워드에서와 메모장,IE6 에서 다르게 보입니다. 또 "나랏말"의 "말", "달아"의 "달" 자에서 굵게 겹쳐 보이는 낱자가 보이는데 왜 그런건지 조사해 볼 필요가 있습니다.

참고2.
XP에서 c:\windows\system32 의 usp10.dll 을 교체하는 것이 약간 까다롭습니다. 검색해 보면 "안전모드- 명령어 프롬프트"로 부팅해서 복사하면 된다고 하는데, 한글윈도우의 경우 cmd.exe에서 usp10.dll을 로드하는 것인지, 복사할 수 없었습니다. 제가 vmware로 윈도우를 사용하기 때문에 아래와 같이 디스트 이미지를 마운트 한 후 복사해 넣을 수 있었습니다.

# mount winxp-flat.vmdk ./001 -t vfat -o loop,offset=16384

첫번째 파티션의 오프셋은 fdisk winxp-flat.vmdk 후 u키를 눌러서 확인했습니다. "안전모드-명령 프롬프트"에서 usp10.dll을 복사할 수 없을 경우, 다른 컴퓨터에 하드디스크를 연결해서 복사하던지 하는 방법을 쓰셔야 할 겁니다. vmware를 쓰신다면 위에 적은 방법을 참고하시기 바랍니다.

----
추가:
위에서 참고1 에서 적었던 좀 이상하게 보이는 글자는 제가 사용한 usp10.dll에서는 하나의 글자로 모아주지 않기 때문에 나타나는 현상으로 보입니다. 그런 글자 주변에서 오른쪽, 왼쪽 커서 이동기로 이동해 보거나, 백스페이스 키로 글자를 지워 보면 글자를 어떤식으로 처리하고 있는지 볼 수 있습니다.
또한, 워드2003에서와 메모장, IE6에서 이런 글자들이 다르게 보이는 이유는, 제가 테스트한 UnBatangOdal 글꼴이 중성,종성 glyp의 width값을 0으로 하고 있는데, 이것의 처리법이 다르기 때문으로 보이는군요. 에멜무지로 님의 ~옛한글 글꼴도 width값을 0으로 하고 있는지 궁금하네요.

----
[1] http://nomos.tistory.com/41
[2] http://en.wikipedia.org/wiki/Uniscribe
[3] http://groups.msn.com/MicrosoftVOLTuserscommunity/homepage.msnw?pgmarket=en-us
[4] http://www.i18nl10n.com/korean/hunmin.html

댓글 첨부 파일: 
첨부파일 크기
Image icon usp10_test02.png115.36 KB
에멜무지로의 이미지

죄송하지만 글꼴 용량이 너무 커서 이메일로 보내기가 힘듭니다. (4개 모두 합쳐서 압축한 게 55.6MB)
사실 저도 아는 분에게 요청해서 받았습니다.

제가 첨부한 그림이 워드와 메모장에서 다르게 보이는 이유는, 워드에선 글꼴을 '바탕 옛한글'로 했지만 메모장에선 글꼴을 '바탕'으로 했기 때문에 그렇습니다. 따라서 그 둘이 다르게 보이는 건 자연스러운 현상입니다. 메모장에서도 글꼴을 '바탕 옛한글'로 하면 워드와 똑같은 출력물을 얻을 수 있습니다.

xx 옛한글 글꼴은 기본적으로 모든 첫가끝 낱자의 너비가 정사각형 너비입니다. 인접한 글자가 뭐냐에 따라 한 글자로 조합해서 네모꼴 모양으로 보여 주기 때문에 굳이 중성·종성 너비를 0으로 할 필요가 없기 때문이죠.

그리고 첨부한 그림에서 'ᄇᆡᆨ' 자가 다르게 보이는 이유는 ᆡ를 ᆡ로 쓰지 않고 ㆍㅣ(ᄇᆞᅵᆨ)로 썼기 때문일 것입니다. 이 경우, 워드, 메모장, IE 모두 제대로 보여 주지 못합니다. ᆡ는 ᆡ 하나로 쓰면 되지 구태여 ㆍㅣ로 쓸 필요가 없으니까요.
굵게 겹쳐 보이는 낱자도 마찬가지 이유입니다. '나랏말'이 아니라 '나랏말ᆺ', '달아'가 아니라 '달ᅡ아'로 입력이 돼 있습니다.

JN의 이미지

알겠습니다. 답변 감사드립니다.

말, 알, 백 같은 글자가 이상하게 보이는 이유는 말씀하신 이유가 맞습니다. 폭이 0인 glyph 때문에 제대로 처리된 걸로 혼동하는 경우가 있는데, 좌우 커서키, 백스페이스 키로 확인해 보니 이 글자들은 모든 프로그램에서 하나의 글자들로 처리하지 않더군요.
가지고 계신 ~옛한글 글꼴이 width를 0으로 놓은 방법을 쓰지 않는다고 하니 반가운 소식입니다. 굳이 중,종성에 폭을 0으로 해서 만들어야 할 필요가 없으니 UnBatangOdal 글꼴도 한 번 수정해서 테스트해보아야겠습니다.

이런 글자들을 신정식님께서 일부러 넣은 이유는 LLVT, LVVT, LVTT, LLVVTT 등과 같이 한글 자모 낱자가 연속으로 올 때, 이걸 한글 자모 겹자로 변환해서 보여주는지 테스트하기 위해서인거 같습니다. 원래 이런 과정이 UnBatangOdal에서 GSUB 테이블 안에 ccmp feature [1]로 들어가 있는데, 이 특성은 제가 사용한 usp10.dll에서는 사용하지 않는 거 같습니다. 한글 풀어쓰기는 LVT 형태로만 표현해야 할 듯 합니다.

----
[1] http://www.microsoft.com/typography/otfntdev/hangulot/features.htm

JN의 이미지

fontforge 로 UnBatangOdal에 연습삼아 GPOS 테이블을 넣은 것을 테스트해보고 있습니다. UnbatangOdal에 중,종성을 오른쪽으로 1000이동해서 width를 1000으로 하는 것만으로 한글이 모아지지는 않더군요. ~옛한글 글꼴의 정보를 몰라서 제가 임의로 UnBatangOdal에 GPOS 테이블을 넣어보았습니다. 테스트는 실패입니다. 한가지 의심가는 것이 script를 hang, language를 KOR, feature를 kern으로 했는데, 혹시 ~옛한글 글꼴이 GPOS 테이블을 포함하고 있다면 어떤식으로 되어 있는지 궁금합니다. 첨부된 그림을 참고해 주세요.

------------
추가.
이것 저것 여러가지로 개선시키면서 시도해 보았는데 잘 안되는군요. fontforge에서는 잘 되는걸 보면 이런 시도가 아예 틀리지는 않은 거 같은데 아쉽습니다. 프로그램에서 한글 처리를 위해서 이 정보를 사용하지 않는 것일수도 있겠습니다. 영문 글꼴에 대해서는 글꼴의 kerning 정보를 사용할 텐데, 정확히 어떤 메카니즘으로 동작하는지 아직 지식이 너무 부족하네요.

여차저차해서 ~옛한글 글꼴을 구할 수 있었습니다. 글꼴당 30MB 안팎의 커다란 글꼴들이더군요. 글꼴을 살펴본 결과, U+1100 영역은 한글 glyph은 폭이 1024이지만, 6x2x4벌의 조합 glyph들은 중,종성의 폭이 0 이었습니다. 지금 보면 당연한 방법인데 제가 너무 많이 나아갔었던 듯 합니다. 덕분에 kerning을 넣을 수 있는 방법을 약간이나마 공부할 수 있긴 했습니다. 이 ~옜한글 글꼴들은 ccmp, ljmo, vjmo, tjmo feature 를 포함하는 글꼴들입니다. 앞으로 은글꼴의 개선이나 다른 새로운 글꼴 개발을 위한 좋은 견본이 될 수 있을 걸로 보입니다.

댓글 첨부 파일: 
첨부파일 크기
Image icon GPOS_test02.png117.54 KB
wkpark의 이미지

좋은 시도들이 계속 있어서 좋네요~ ^^

fontforge를 이용해서 만들 수도 있나보군요~

일전에 저는 ttoasm을 사용해서 GSUB를 시도했고, 때마침 신정식님께서는 M$의 VOLT를 이용해서 Ogulim.ttf에 GSUB를 추가하신 것을 공개하였었으며, 이런 것을 바탕으로 해서 은글꼴 바탕체 + dal 비트맵윤곽선글꼴에 거의 그대로 적용한(ttoasm사용해서 GSUB역어셈블 + perl스크립트로 인덱스 수정) ttf를 공개했었습니다.

이미 언급하신것처럼 M$에서 모든 어플에 GSUB가 제대로 작동하지 않는 것은 uniscribe(usp10.dll)의 문제입니다.

이게 벌써 5년전 일이네요 ㅠㅜ..

http://www.ktug.or.kr/jsboard/read.php?table=ktugbd&no=1116&page=1

옛굴림체를 그대로 쓸 수는 없는 노릇이고, 공개된 옛한글을 자형별로 한벌씩, Ogulim.ttf형식 (6x2x4 고정벌 조합)으로 만든다면 신정식님의 GSUB를 그대로 바로 적용할 수 있습니다. (벌수가 틀려진다면 VOLT나 fontforge 혹은 ttoasm으로 GSUB를 다시 만들어야겠죠)
----
그리고 은글꼴을 제대로 관리하지 못하고 있는 점은 참 안타까운 일인데요..
몇가지 일을 구상하다가 시간만 가버렸군요..

은글꼴 소스는 현재 fontforge의 sfd소스 형태로 관리하고 있습니다만, cvs에 소스로 올리고 업뎃하기에는 그다지 좋은 방법이 아닌 것 같더군요.
1) 소스가 너무 큽니다. 전체용량이 수백MB나 되어서 한번 커밋하는데 시간이 너무 걸립니다..
2) 그런 이유로 글꼴 단위가 아닌 글자단위 소스관리툴이 필요하며,
3) 여기에 fontforge + 웹 보조 인터페이스가 추가로 있었으면 좋겠습니다. (java애플릿 혹은 간단한 sfd 인터프리터를 적용?)

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

JN의 이미지

테스트로 은바탕에 GSUB 테이블을 넣어보았습니다. 일단 GSUB 테이블을 넣는 방법을 공부하는 것을 목적으로 했기 때문에, 간단히 3x1x4벌로 조합자형을 구성하였습니다. 6x2x4벌 구성에서 종성이 없을 경우의 자형을 따로 그려 넣지 않은 조합방법입니다.

초성: 종성없음 ㅏ형, ㅗ형, ㅘ형 3벌 + 종성있음 ㅏ, ㅗ, ㅘ 3벌 = 6벌
중성: 종성없음 + 종성있음 = 2벌
종성: 중성 ㅏ, ㅓ, ㅐ, ㅗ 에 따라 좌우 shift = 4벌

글꼴을 열어보면, 조합자형을 배열하는 방법이 Ogulim.ttf와는 다른데, 이렇게 배열하는 방법이 벌수를 추가하는 것도 쉽고, GSUB 테이블에 데이터를 추가하는 것도 쉽습니다. GSUB테이블에 데이터를 추가할 때는 fontforge에서 추가할 데이터를 마우스로 드래그해서 선택한 다음에 "Set From Font"버튼을 누르시면 됩니다. 처음 생각에 추가할 데이터 양이 많기 때문에 별도의 스크립트를 작성해야 할 걸로 생각했는데, 굳이 그럴 필요까지는 없더군요. 첨부한 feature 파일을 얻기 위해서 김도현님 글을 참고해서 fontforge와 편집기 조작만을 이용하였습니다.

전에 ccmp feature는 윈도우의 usp10.dll에서 사용하지 않는 것 같다고 썼었는데, 테스트해보니 사용하더군요. 그런데 ㄱ+ㄱ=>ㄲ 같이 이미 코드값이 배정된 경우가 아니라, 이번에 unicode 5.1에 추가된 자형같이 코드값이 배정되지 않은 것들을 합성하는 데에 사용하더군요. 위의 그림을 보시면 쉽게 이해되실 겁니다. 아직 제가 테스트한 usp10.dll 에는 unicode 5.1에 대한 고려는 되어 있지 않은 걸 보실 수 있습니다.

솔직히 자형도 진짜 제대로 다듬고, 조합방법도 더 확장해서 제대로 된 글꼴을 내놓고 싶었는데, 짬짬히 손보고 있는 거라 언제 끝날지 모르기 때문에 현재 테스트한 결과만 올려봅니다.

댓글 첨부 파일: 
첨부파일 크기
Image icon gsub_test03.png46.91 KB
Plain text icon UnBatang.fea_.txt146.02 KB
Binary Data UnBatang.ttf_.gz670.76 KB
Binary Data UnBatang.sfd_.gz1.48 MB
Plain text icon 5.1 test.txt26바이트
Plain text icon hunmin_test.txt7.04 KB
에멜무지로의 이미지

3월 후반에 유니코드 5.1이 나오고 나서 만들어지는 유니스크라이브에서는 새 낱자들도 지원하겠죠.

wkpark의 이미지

사용하신 usp10.dll은 버전이 어떻게 되나요? (저는 1.453.3665.0)

fontlab으로 테스트해봤는데.. 저는 여전히 ccmp가 작동을 안하는 것 같고,

노트패드에서도 글자의 일부만 조합이 되고 나머지는 풀어져서 나옵니다. (위의 그림처럼 안나옵니다.)

Odal은바탕은 여전히 잘 되고요.

그리고 최근의 GSUB관련 이야기를 정리해봤습니다.

http://faq.ktug.or.kr/faq/%BF%BE%C7%D1%B1%DB%B1%DB%B2%C3#s-2.1

추가: usp10.dll 버전을 올리니 잘 됩니다 :>

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

김도현의 이미지

정말 고생하셨습니다. 그리고 감사드립니다.

그런데 feature 파일 중 한 군데가 이상하여 수정하다가 보니
어쩌다가 좀더 소략하게 만들게 되었습니다. 첨부합니다.

어쨌든 잘 작동하고 있습니다.
이제 사실상, 글리프 그리는 일만 남았다고 하겠습니다.

댓글 첨부 파일: 
첨부파일 크기
Binary Data UnBatang080227.fea66.49 KB
JN의 이미지

좋군요!!! 위에 올렸던 것보다 훨씬 간단하고 깔끔하네요.
위에 제가 올렸던 것은 너무 불필요한 데이터를 많이 포함하고 있었던 듯하네요. 또 제가 너무 초성-중성, 초성-중성-종성 의 틀에 얽매였던 싶습니다.

6x2x4 벌로 자형을 자리만 잡게 해서 새로 만든 것을 올립니다. 압축을 푸신 후, kldp.net에서 UnBatang.sfd 를 다운받아서 함께 놓은 후, make 하면 GSUB 테이블이 들어간 UnBatang.ttf 가 만들어 지도록 했습니다. 일단 자리만 잡도록 해 둔 것이기 때문에, 좋은 모양이 되기 위해서는 자형을 새로 그려주어야 합니다.

댓글 첨부 파일: 
첨부파일 크기
Binary Data unbatang_gsub.tar.gz653.24 KB
김도현의 이미지

멋집니다. ^^

다만 첨부파일은 글리프이름을
ljmo01.uni1100
이런 방식 대신에
uni1100.ljmo01
이렇게 고친 것 뿐입니다.

글리프이름에 관한 규약은
http://www.adobe.com/devnet/opentype/archives/glyph.html
여기를 참조하세요.

댓글 첨부 파일: 
첨부파일 크기
Binary Data unbatang_gsub-080227.tar.gz654.86 KB
JN의 이미지

감사합니다 :)

김도현의 이미지

Korean TeX Users Group에서는 수 년 전부터 TeX을 이용한 옛글 조판을 지원하기 위해 노력해 왔습니다. 따라서 가장 흔히 접할 수 있는 폰트인 ogulim, obatang (GSUB 없는 것)을 분석하는 작업이 필요했습니다. 이미 5년여 전에 조진환, 신정식, 박원규에 의하여 이들 폰트의 조합규칙이 규명되었으며, 제가 이것을 조금 수정하여 ko.TeX(최근에 개발된 한글텍 패키지 이름)에 적용하였습니다.

첨부 파일은 ko.TeX에서 사용하는 ogulim 등의 자소조합규칙을 유니코드 5.1에 맞게 수정·정리한 것입니다. 마찬가지로 6x2x4 방식을 사용하여 GSUB 폰트를 만든다면 이것을 참고할 수도 있지 않을까 해서 올려봅니다.

NLVT, NLV, NTV의 세 파일이 있습니다. 앞 둘은 중성에 따른 초성 변화를, 셋째 것은 중성에 따른 종성 변화를 정리한 것입니다. 각 파일에는 예를 들어
1 uni1161 ㅏ
이런 방식으로 기술된 행이 나열되어 있습니다. 맨 앞의 숫자는 변형 벌 수 중에서 몇 번째에 해당하는지를 나타냅니다. ogulim 폰트를 열어놓고 보시면 금방 느낌이 오실 겁니다.

폰트를 어떻게 디자인하느냐에 따라 얼마든지 달라질 수 있으므로 그냥 참고만 하십시오.

댓글 첨부 파일: 
첨부파일 크기
Binary Data jamo624gsub_rule.tar.gz1.15 KB
wkpark의 이미지

수고하셨습니다~ ^^

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