유니코드 5.1의 새 첫가끝 낱자가 추가된 '은 자모 바탕 확장'에 에멜무지로님이 올리신 폰트를 가지고 공부삼아 여기다 GSUB ccmp 정보를 집어넣어봤다.

우선 이런 식으로 feature 파일(ks x 1026-1이 규정한대로 U+11EC .. U+11EF의 이응을 옛이응으로 수정하였음)을 작성한 다음, fontforge 에서 [File]-[Import Feature Info] 메뉴를 이용하여 은바탕자모확장 폰트에 집어넣었다.

그 결과 만들어진 오픈타입  트루타입 폰트(윈도즈에서 설치거부되는 현상이 있어 트루타입으로 다시 만들었음. 윈도즈에서도 대체로 잘 작동함)는 의도대로 잘 작동하였다.

테스트:

Posted by nomos

댓글을 달아 주세요

  1. JN 2008.01.20 11:27  댓글주소  수정/삭제  댓글쓰기

    훌륭합니다. 박원규님 글꼴페이지에서 ttoasm을 이용해서 GSUB테이블을 만드는 방법을 보고 있었는데, 너무 참고자료도 부족하고 난해했었는데, 이 방법은 접근하기하 훨씬 좋을 거 같습니다.
    fontforge 홈페이지에서 "Merge Feature Info"메뉴항목을 찾으니 관련정보가 줄줄이 나오는군요 :) 좀더 공부해 보아야 하겠습니다만, 의외도 가까운 곳에 좋은 툴이 있었네요.

    위에서 작업하신 ccmp 특성을 쓰면 현대한글의 첫가끝 낱자 코드로 표현했을 경우에 이걸 모아서 현대한글 음절 영역에 있는 자형이 표시되도록 하는데 사용할 수 있을 거 같습니다. 좀더 연구하면 아예 은글꼴에 여러벌로 그려져 있는 한글 초,중,종성 조합 자형을 직접 이용하게 할 수도 있겠구요. 이게 ljmo,vjmo,tjmo 특성인거 같은데 공부해 보아야겠습니다.
    여기까지는 따로 자형을 새로 그려넣을 필요없이 현재 존재하는 은글꼴을 가지고도 진행할 수 있는 작업인거 같습니다. 여기까지는 과정에 노하우를 쌓은 후에 좋은 품질의 옛한글 글꼴에 대해서 진행한다면 좋지 않을까 생각해 봅니다.

    기쁜 마음에, 마음만 벌써 미래로 가버린듯합니다...
    좋은 정보 감사드립니다.

  2. nomos 2008.01.20 19:25 신고  댓글주소  수정/삭제  댓글쓰기

    합자가 불필요하게 된다니 옛한글 표현을 위해 ccmp 정보를 넣을 필요가 없어지겠군요. 하지만 현재로선 합자에 해당하는 기능을 완전히 지원하는 입력기가 없으므로(적어도 리눅스나 맥에서는 그렇습니다. 날개셋은 새로 들어가는 자모를 포함하여 완전히 지원하나요?) 당분간은 전혀 무의미하지는 않겠습니다. 어쨌든 공부삼아 만들어본 것 뿐입니다.

    윈도즈에서는 말씀하신대로 이 폰트를 받아들이지 않더군요. 그러나 폰트포지에서 otf가 아닌 ttf를 만들라고 하면 GSUB 정보가 포함돼 있으면서도 윈도즈가 거부하지 않는 폰트가 만들어집니다. 원인이 무언지는 모르겠습니다만, 어쩌면 ttf에서 쓰이는 2차원 곡선이 otf의 3차원 곡선으로 변환되지 않은 채 otf가 만들어지기 때문은 아닐까 하고 짐작만 해 봅니다.

    에멜무지로님께서는 애초 폰트를 만드실 때 kldp 은글꼴 저장소에서 받을 수 있는 글꼴 소스 파일(sfd 확장자를 가집니다)을 가지고 작업을 해 주시고 이를 공개해주시면 더욱 고맙겠습니다. 그곳의 sfd 파일은 본래 Type1 폰트에 기초한 것인지라 3차원 곡선을 담고 있습니다.

    그런데 윈도즈에서 이 폰트의 GSUB 정보를 테스트해 볼 수 있는 응용프로그램이 무엇이 있는지 아시는지요? XeTeX이야 플랫폼을 가리지 않으니 윈도에서도 당연히 되고 이미 잘 작동하는 걸 확인했습니다만, 그외 다른 것도 있을 법 한데 모르겠군요.

  3. JN 2008.01.20 22:46  댓글주소  수정/삭제  댓글쓰기

    MS Windows에 UnBatangOdal을 설치하고서, MS Office 2003에서 http://nomos.tistory.com/39 에서 테스한 텍스트를 열어 글꼴을 은바탕으로 해서 테스트해보았습니다.
    제대로 잘 보이지는 않지만 자세히 살펴보면, 현대한글은 초중성까지만 먹는것처럼 보이더군요. 또, "(아래아)한" 자를 보니까 이글자는 올려주신 그림과 동일하게 보이구요.
    확실하지는 않지만, 일단 GDUB이 아예 안먹는게 아니므로 Office에서 어떻게 하면 제대로 보일지 연구해 보면 될 듯합니다.
    ccmp, ljmo, vjmo, tjmo feature이 MS에서 문서로 명시해 놓은 것들이기 때문에 새로 feature를 정의해서는 안되고 이 feature들이 잘먹도록 해야, 제대로 쓰일 수 있는 글꼴이 될거라고 생각합니다.

  4. JN 2008.01.20 23:19  댓글주소  수정/삭제  댓글쓰기

    일단 글꼴을 GSUB가 들어있지 않은 원래 은 자모바탕으로 테스트해보니, 오피스에서 width가 0인 중성, 종성에 대해서 중성까지만 모아서 보여주고, 종성은 따로 보여줍니다. 이 현상이 GSUB가 들어있는 UnBatangOdal에서도 나타나는 게 아닌가 싶습니다.
    그런데 신기한거는 "(아래아)한"자의 종성을 바꾸면서 여러 글자를 테스트해보니 이것들 모두 초,중,종성을 잘 모아서 보여준다는 점입니다. 제가 옛한글을 입력하기가 어려워서 많은 옛한글 글자를 테스트해 보지는 않았지만, 아마 적어도 옛한글에 대해서는 UnBatangOdal이 잘 작동할 거 같습니다.
    ccmp feature로 첫가끝 낱자를 겹낫자로 바꾸는 것은 동작하지 않는군요.

    이상을 종합해 보면, LLVT LVTT LLVVTT 등의 형태는 안되고, 항상 LVT형대로 표현하되, 현대한글은 음절영역의 코드로 표현한다. 이런식의 결론이 나오는군요.
    이게 UnBatangOdal에 문제가 있어서 그런건지, 오피스에서 의도적으로 이렇게 처리하는지는 알아보아야 하겠습니다.

    • nomos 2008.01.21 06:23 신고  댓글주소  수정/삭제

      글쎄요. 테스트할 수 있는 입장이 아니라 자신은 없지만, 말씀을 들어보니, 오피스가 행하는 것은 자모 입력(U+1100 영역)이 들어오면 가능하다면 음절 영역(U+AC00 영역) 글자로 변환하여 보여주는 데 그치는 게 아닌가 추측합니다.

  5. JN 2008.01.20 23:27  댓글주소  수정/삭제  댓글쓰기

    위에 동작이 http://kldp.org/node/90127#comment-426183 에서 나온
    --------------
    1. 낱자 여러 개를 써서 겹낱자를 표현하면 안 됩니다.
    예: ㄱㄱ (1100 1100, 틀림) → ㄲ (1101, 맞음)
    3. 현대 한글은 반드시 완성형 한글 글자 마디로 표기해야 합니다.
    예: ㄱㅏ (1100 1161, 틀림) → 가 (AC00, 맞음)
    ---------------
    와 상당히 유사합니다. 우연일 수도 있겠지만, 만약에 UnBatangOdal의 문제가 아니라 위의 동작이 의도적인 거라면, 뭔가 비하인드 스토리가 있을 거 같은 냄새가 납니다.

  6. JN 2008.01.21 08:57  댓글주소  수정/삭제  댓글쓰기

    >> 오피스가 행하는 것은 자모 입력(U+1100 영역)이 들어오
    >> 면 가능하다면 음절 영역(U+AC00 영역) 글자로 변환하여
    >> 보여주는 데 그치는 게 아닌가 추측합니다.
    제가 글을 좀 엉성하게 썼는지 제 글이 제대로 전달되지 않은 듯 합니다.

    음절 영역 글자(U+AC00)로 표현 가능한 한글을 자모 영역 글자(U+1100)로 풀어썼을 경우에, 오피스는 이걸 제대로 처리하지 못합니다. 자체적으로 변환을 시도하는 것도 아니구요. 이건 글자 뒤에서부터 차례차례 백스페이스를 눌러가면서 어떻게 글자가 지워지는지 살펴보면 확인이 가능합니다. 하지만 이건 위에 새규격에서도 그렇구, 현대한글은 풀어쓰지 말고 음절영역의 코드로 표현하면 되니까 어떻게 보면 큰 문제가 되지는 않는다고 볼수도 있습니다. 저 개인적으로는 풀어쓴 현대한글도 제대로 보여주는 게 옳다고 보지만 뭔가 규격을 이렇게 한 데에는 속사정이 있지 않을 까 생각합니다.
    문제는 음절영역에 코드로 배정되지 않은 옛한글의 경우인데요. 옛한글을 표현하기 위해서는 유니코드 PUA영역에 완성된 자형을 배정해 입력하는(NGULIM.TTF 같은 경우) 방법도 있지만, 궁극적으로는 U+1100 영역의 코드를 써서 한글을 풀어쓰는 방법을 써야 한다고 생각합니다. 그런데 신기하게 UnBatangOdal 폰트를 썼을 때, 오피스에서 이게 동작한다는 점입니다.
    http://faq.ktug.or.kr/faq/HanyangPuaTableProject 페이지를 참고해서,
    ----
    perl hypua2jamo.pl -s < hunmin.uni > hunmin-jamo1.txt
    perl hypua2jamo.pl < hunmin.uni > hunmin-jamo2.txt
    ----
    이렇게 두 파일을 만들어 오피스에서 글꼴을 "은 바탕"(UnBatangOdal 로 설치한 은 바탕)으로 주어서 살펴보시면 둘 사이의 차이를 알 수 있을 겁니다. 백스페이스로 글자를 지워보면 오피스가 자모 입력 글자를 어떻게 처리하고 있는지 확인하실 수 있으실 겁니다.

    여기까지 글은 어디까지나 UnBatangJamo에 문제가 없다는 가정하에서 쓴 글입니다. TeX에서는 현대한글의 자모 입력형태도 제대로 표현하고, ccmp feature도 작동하는 걸 보면, 제 생각에는 폰트에는 큰 문제가 없을 거 같습니다. 어차피 ccmp, ljmo, vjmo, tjmo 니 하는 것들은 프로그램에서 이 정보를 어떻게 처리하느냐에 따라서 달라지는 문제라 제 생각에는 구현상의 차이가 아닌가 생각합니다.
    또한 새로 제한된 규격에서 금지하는 사항에 대해, 오피스가 어긋나지 않는 행동을 하고 있기 때문에 이 점도 뭔가 의미심장하게 보고 있습니다.

  7. JN 2008.01.21 09:10  댓글주소  수정/삭제  댓글쓰기

    ----
    LLVT LVTT LLVVTT 등의 형태는 안되고, 항상 LVT형대로 표현하되, 현대한글은 음절영역의 코드로 표현한다.
    ----
    이 문장의 주어는 "오피스"가 아닙니다. 오피스에서 제대로 처리될 수 있도록 한글코드를 입력하고자 한다면 이런식으로 해야 한다는 말입니다 :)

  8. JN 2008.01.21 09:55  댓글주소  수정/삭제  댓글쓰기

    흠... 전혀 기대하지도 않았던 메모장에서도 UnBatangOdal이 잘 동작하는구군요. 이 경우 "hypua2jamo.pl -s" 를 써서 현대한글까지 풀어쓰기 한 것도 제대로 보여줍니다. 그런데 메모장에서는 백스페이스나 왼쪽, 오른쪽 커서 이동키가 오피스와는 다르게 동작합니다. 사실 이런 것은 글꼴과 무관하게 소프트웨어적인 문제이긴 합니다.

    제 생각에, 어느정도 간단히 GSUB 글꼴을 테스트할 수 있는 환경은 갖추어진 듯 합니다.

  9. nomos 2008.01.21 12:14 신고  댓글주소  수정/삭제  댓글쓰기

    MS오피스 2007에서 말씀하신대로 해 봤습니다. 오,,, 정말 말씀하신대로군요. 정확히는 모르겠으나 이미 코드가 배정된 글자의 ccmp는 잘 안 되지만 ljmo 따위는 정상적으로 작동하고 있구요. 결국 오피스는 폰트가 제공하는 정보를 그대로 처리하는 게 아니라 무언가 자기 기준에 따라 걸러내고 있다고 보이네요. 어쨌든 GSUB이 작동은 하고 있습니다. 좋은 정보 감사드립니다. 메모장도 말씀하신 것대로 확인했습니다.

    게다가 인터넷익스플로러에서도 대체로 잘 작동합니다.
    http://i18nl10n.com/korean/humin.html
    여기를 방문해보세요. 다만 “백셩”의 백자가 이상하군요. IE7입니다. [ps] 음.. 살펴보니 이것도 말씀하신 것과 마찬가지 현상입니다. 아래아와 ㅣ 가 나누어 입력되었기 때문에 윈도즈가 이를 별개의 음절로 파악한 것입니다.

  10. JN 2008.01.21 12:58  댓글주소  수정/삭제  댓글쓰기

    감사합니다. 전에 그 사이트를 본적이 있어서 이번에 찾아보았는데, 못찾고 있었습니다. jshin.net으로 시작하는줄 알았는데 아니었나 보군요.

    지금까지 정보를 보아선 KS X 1026-1 이 허용하는 규칙대로 입력하는 것이 가장 무난한 선택으로 보입니다. 국가 표준을 정하는 것이 그냥 되는 것이 아니고 여러 전문가들이 이런저런 상황을 고려해서 정했을 것이기 때문에, 위에서 테스트한 결과와도 일치되는 상황이 나온 것이 아닌가 생각됩니다.

  11. JN 2008.01.27 15:19  댓글주소  수정/삭제  댓글쓰기

    제가 위에서 적었던 문제들은 로드된 usp10.dll 의 위치와 버전 문제였던 듯 싶습니다. 시스템에 존재하는 모든 usp10.dll을 최근 버전으로 교체하면 메모장, IE, 워드에서 동일하게 모습을 볼 수 있습니다. 관련글을 아래 링크에 적어 놓아습니다.
    http://kldp.org/node/90530

  12. nomos 2008.02.05 23:12 신고  댓글주소  수정/삭제  댓글쓰기

    앗, 언제부턴지는 몰라도 openoffice writer도 GSUB feature를 지원하고 있군요. 대단합니다. 장족의 발전이네요. 본문에 링크된 폰트를 리눅스 상에서 사용해 보았습니다.

  13. JN 2008.02.26 15:35  댓글주소  수정/삭제  댓글쓰기

    테스트로 3x1x4벌의 조합자형을 그려넣은 UnBatang 글꼴을 만들어 보았습니다. 오픈오피스에서도 잘 작동하는군요.

    ccmp feature는 김도현님의 파일을 그대로 사용하였고, ljmo, vjmo, tjmo feature 만 따로 조합자형에 맞게 집어넣었습니다. fontforge 기능이 쓸만해서 별도로 스크립트 같은 것을 만들지 않아도 되더군요. 몇몇 fontforge에서 입력하기 힘든 데이타는 몇개만 집어넣고 feature 파일을 편집해서 집어넣었습니다.

    ccmp의 경우 usp10.dll을 사용하는 상황에서는 코드값이 배정되지 않은 경우에만 합성을 하는 것 같습니다. 그래서 "ㄱ+ㄱ=>ㄲ"의 변환이 작동하지 않았었습니다.

    http://kldp.org/node/90530 에 글꼴을 올려두었습니다.

  14. Online logo designs 2012.04.21 19:42  댓글주소  수정/삭제  댓글쓰기

    I want to say that your post is fantastic. You have written it well. Keep on posting. I will come again to read new posts. Thanks.