ocarina.ruree.net
한글 인코딩에 관한 조합형 완성형 논쟁은 유니코드에서 완성형과 조합형 모두를 수용하는 방식으로 종결되었지만, 한글 글꼴 구현에는 조합형 완성형 논쟁의 잔재가 아직까지도 남아 있고 글꼴을 갖다 써야 하는 곳에 따라서 과거의 조합형 글꼴을 아직도 써야 하는 경우가 생길 수도 있다. 당장 일부 한글 글꼴이 완성형 2350자 이외의 글자에 대한 글리프가 없어서 해당 글자를 입력하면 깨지는 것도 이 시기의 잔재이다. 디스플레이 화소 수가 적고 메모리 공간이 KB 대에서 노는 임베디드 환경이라면 조합형 글꼴(조합형 인코딩이 아님!)로 한글을 표시하는 게 유리할 수 있다. 한글 낱자가 들어오면 그것들을 나눗셈과 나머지 연산으로 자소 단위로 분해하고 수백개의 글리프 중 최대 3개를 OR 조합해서 표시하는 게 2350/11172자 모두의 글리프를 들고 있다가 표시하는 것보다 데이터 양은 더 적게 필요하다. 그 동안 도스 시절의 한글 바이오스나 컴퓨터 역사 초기의 한글 구현을 분석하면서 알게 되었던 각종 조합형 글꼴 구성
상당히 많은 곳에서 쓰이고 있는 조합형 글꼴 구성 방식이다. 원리는 지금도 잘 알려져 있고 명세를 구하는 것도 어렵지 않다( 링크 ). 초성 8벌, 중성 4벌, 종성 4벌에 해당하는 글리프를 미리 만들어 두고 자모의 종류에 따라서 서로 다른 글리프를 사용한다. 8x4x4 조합형의 구현체는 많은 곳에서 찾을 수 있기 때문에 해당 조합 방식의 글꼴을 사용하는 곳과 추출하는 방법만을 여기에서 소개한다.
8x4x4 조합형에서 초성 글리프가 두 벌 더 들어간 형태이다. 중성과 종성 조합 규칙은 8x4x4와 동일하나 초성 조합 규칙은 살짝 다르다. 글꼴 통합 변환기의 hanlib/Table8x4x4.c 파일과 hanlib/Table10x4x4.c 파일을 비교하면서 보면 이해할 수 있다. 아래에 있는 두 종류의 10x4x4 조합형 글꼴은 높이 문제 때문에 그대로 통합 변환기에 전달할 수는 없으며 적절하게 높이를 조정해 줘야 한다.
ocarina.ruree.net