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정도만 하고 슬슬 글꼴을 구분하는 능력을 부여할 수 있습니다.  렌더링 모듈에서 어떤 기능이 있냐 없냐를 테스트하는 건 확실하지 않지만 안 될 것 같고..  글꼴 이름으로 구분해서 앞에서 말씀드린 과도기적 역할을 할 수는 있죠. 

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