오늘날 운영체제의 표준 글꼴 포맷으로 널리 쓰이고 있는 TTF 내지 OTF는 내부적으로 쓰는 각종 구조체들이 기술하는 글립의 영역 크기가 16비트로 제한되어 있다.
이것은 TTF 파일이 제정되던 초창시에는 아주 넉넉하고 인심 쓴 공간이었다. 겨우 8비트 크기의 코드 페이지에 맞춰진 글꼴밖에 없던 서양에서, 그나마 “수천 자의 2바이트 한자를 써야 하는 동아시아 문자권”까지 국제화 차원에서 고려한답시고 크기를 넓힌 게 16비트였다. 무슨 포스트스크립트 글꼴은 그것마저 지원 안 돼서 한글 글꼴은 여러 파일로 나눠서 표현해야 하지 않았던가. 쓸데없이 비트 수가 크면, 쓰는 영역에 비해 불필요한 0만 뒤에 잔뜩 달라붙고 글꼴 래스터라이저를 더욱 ‘무겁게’ 만들게 된다.
하지만 지금은 시대가 달라졌다. 아무리 작은 임베디드 기기라도, 일단 사람과 직접적인 의사 소통을 하는 기계의 CPU는 일단 최하 32비트는 기본으로 먹고 들어간다. 실용적으로 가장 적합하면서도 가상 메모리라든가 현대적인 운영체제 기본 개념을 제대로 구현할 수 있는 최소한의 CPU 규모가 32비트가 아닌가 한다.
메모리 자원은 넉넉해지고 국제화의 중요성은 엄청 커졌다. 그래서 한컴바탕이라든가 Arial Unicode MS처럼, 모든 유니코드 영역 글꼴을 모두 담고 있는 글꼴의 필요성이 대두되고 있다.
아직 모든 문자가 16비트 안의 BMP에 있던 유니코드 2~3.0 시절까지는 그럭저럭 별 문제 없었고 6만 5천여 개라는 글립 개수 제한은 현실적으로 별 영향이 없었다. 하지만 이제 유니코드가 surrogate 영역까지 쓰고 집합 크기가 16비트 크기를 넘어서면서, 이제 단일 글꼴에다 유니코드 전영역 문자를 담을 수가 없어져 버렸다.
더구나 이 16비트라는 크기는 글자 코드 단위가 아니라, 글립이라는 그림 단위이다. 한 코드 페이지에 해당하는 글자가 여러 글립을 차지할 수가 있다. 조합형 한글 글꼴처럼 한 글자를 여러 글립의 묶음으로 표현하는 글꼴이 있다면, 그렇게 부품 글립이 들어가는 자리를 글립 인덱스 상으로 제외해 줘야 한다. 아랍어처럼 한 글자가 상황에 따라 여러 글립 중 하나로 달리 표현되는 문자가 있다면, 그런 것까지 고려해야 하기 때문에 실질적으로 표현 가능한 문자 개수는 더욱 줄어든다.
지금 컴퓨터의 두뇌가 32비트와 64비트 사이에서 달랑달랑 거리는 것처럼, 글꼴 쪽은 16비트 크기라는 글립 개수 한계를 어떻게 초월해야 할지 고민 중이다. 당연히 TTF 규격상으로 각종 구조체의 필드를 확장하고 새 버전 식별자만 부여하면 문제는 해결된다. 하지만 온갖 테이블들의 내부에서 바꿔야 하는 게 너무 많고 이 새로운 TTF는 이전의 어떤 운영체제/응용 프로그램에서도 인식 못 하는 듣보잡 포맷이 되고 말 것이다. 결국 문제는 호환성이다. =_=;;
Posted by 사무엘
