2006년 12월 16일 토요일

Pango 한글 렌더링

hangul-hackers 리스트와 수동 CC

-------------------

요즘 Pango 1.15.x 개발버전이 한창 진행되고 있고 해서, 한글 렌더링 모듈을 좀 손대려고 합니다..  발전적인 의견 있으면 주세요.

여담이지만 Pango의 한글 렌더링 모듈의 장기적인 발전 방향은, 아이러니하게도 글꼴이 다 알아서 하고 전용 모듈이 사라지는 것입니다.  현재까지는 (사실상 특수한 문서를 작성하지 않는한 사용하지 않는) 첫가끗이나 방점 등 렌더링 모듈이 일부러 신경을 써야 하는 기능들을 지원하는 글꼴은 소수입니다.  아마도 그런 글꼴이 널리 쓰이게 될때까지는 한글 모듈은 과도기적으로 그 글꼴을 구분하고 기능 조절을 하는 역할을 해야 할 것입니다.

어쨌든, 현재로선 거기까진 무리이고, 몇가지 최적화정도만 해야 겠네요:

1. 한글음절을 일부러 초/중/종으로 나눴다가 다시 합치는 동작 제거 - 일반화하기 위해 이렇게 했었지만, 일단 한글음절일 경우에 CPU 낭비인 데다가, 첫가끗으로 구성되어 있는 경우에도 나눠져 있는 걸 다시 합치면서 글꼴이 가진 능력을 활용하지 못하는 경우가 있습니다.

2. 동적 버퍼 제거 - L+V+T*M 이렇게 이론상 길이가 n인 1개 음절이 될 수 있기 때문에 realloc을 하는 버퍼를 두었는데 만들 때부터 신경쓰이는 부분이었습니다.  가능하면 버퍼없이 utf8 string에서 ucs4로 변환하지 않고 처리하도록 해 보지요.  :D

3. 그리고 안에 감춰져 있지만, pango_string_set_size()로 야금야금 크기를 늘려나가는 것도 내부적으로는 끊임없는 realloc()을 수행하게 해서 속도 저하 요인이 되는데요.  결과 글리프의 개수를 쉽게 알아낼 수 있을 것도 같은데, 이 부분은 좀 생각해 봐야 겠구요...

자, 여기까지 읽어보시고 "아! 내 그놈 데스크탑의 속도가 빨라지겠구나"라고 생각하신다면 그건 아니구요.  텍스트 렌더링의 대부분의 로드는 래스터라이징 자체와 래스터된 결과 데이터를 옮기는 데 있습니다. Pango 한글 모듈이 하는 일이라곤 유니코드 스트링을 보고 글꼴에서 어떤 글리프를 사용할까를 선택하는 정도이기 때문에 전체 텍스트 렌더링은 큰 향상을 기대하기 어려울 겁니다.  그냥 개발자의 결벽증인듯?

4. 2/3은 사실 그렇게 최적화 결벽증이고..  일단 1정도만 하고 슬슬 글꼴을 구분하는 능력을 부여할 수 있습니다.  렌더링 모듈에서 어떤 기능이 있냐 없냐를 테스트하는 건 확실하지 않지만 안 될 것 같고..  글꼴 이름으로 구분해서 앞에서 말씀드린 과도기적 역할을 할 수는 있죠. 

방점은 알아서 해 주는 글꼴을 본 적이 없고..  일단 첫가끗이 되냐 안되냐로 구분해서 음절을 자체적으로 합치려고 시도하느냐 아니냐를 결정할 수 있겠죠.  (그런데 한글음절로 표현할 수 있는데 일부러 첫가끗코드로 쓰는 그런 경우가 제가 테스트할 때 빼고 있는지 모르겠습니다.  :-)

댓글 3개:

  1. 와와와~~~~

    내 그놈 데스크탑의 속도가 빨라지겠구나~

    가 아니군요... oTL

    그래도 느려지진 않는거죠? ^^;

    답글삭제
  2. 예전에 iTunes 를 가지고 태그를 수정한 뒤 나중에 확인을 해봤더니 id3 태그가 첫가끝 코드로 들어가 있더군요. 그 외에도 매킨토시에서 한글이름을 가지는 파일을 rar 로 묶을 경우 파일 이름이 첫가끝 코드로 저장되는 걸 확인했습니다.

    답글삭제
  3. Mac OS X에서는 한글을 첫가끝으로 저장한다고 알고 있습니다.

    답글삭제

뜬금없이 문법 따위를 지적하거나, 오래된 글에 링크가 깨진 걸 지적하는 등의 의미 없는 댓글은 자제해 주시기 바랍니다. 그러한 경우 답 없이 삭제합니다. 또한 이해 당사자이신 경우 숨어서 옹호하지 마시고 당사자임을 밝히시길 바랍니다.

참고: 블로그의 회원만 댓글을 작성할 수 있습니다.