블로그는 귀차니즘

1. Glyph Index사용에 주의

TTF 파일을 읽어 처리하는 라이브러리이니 만큼 일단 TTF 문서에 대해서 간략하게 알고 계셔야 문제에 대해서 무척 쉽게 대처할 수 있겠죠? 저도 저번에 시간이 났을 때 잠시 검색하여 읽어보았던 TTF, OTF 문서의 기억으로 많은 도움을 받았습니다.
  이 TTF 파일을 보자면 단 하나의 문자집합으로 이루어져 있지는 않습니다. 확장아스키를 저장하는 방법으로 WANSUNG, JOHAB, SJIS, BIG5등이 있으며, Unicode도 존재합니다. 물론 이 방법에 대해서 출력하는 것이 약간 고려해야 할 부분이 있습니다. 각각의 문자 코드에 대한 것을 다르게 처리 해주어야한 다는 점이죠.

2. Johab은 일단 먼서 선택을..

  제가 이상하게 테스트를 해봐서 그런 것일지는 모르겠습니다만 별도로 Vmware를 깔아 깨끗한 환경을 마련하고 개발을 진행했는데, Wansung, Unicode형 출력과는 다르게 Johab형의 출력은 CharMap을 미리 선택해야 하더군요.
  기본적으로 하나의 TTF 폰트 안에 여러개의 문자집합 형식이 있을 수 있으므로 그 중 하나를 선택하여 출력이 가능하지만 Unicode, Wansung형은 자동으로 0번 집합으로 선택이 되더군요. 내부 소스를 깊숙히 파악하지는 못해 원인은 모르겠지만 아마도 주류가 되는 인코딩은 미리 선택이 되는 것 같습니다.

3. Glyph Index 전달에 있어..

  일반적으로 Glyph의 Index를 얻어오거나, Index를 통해 Glyph를 얻어오는 함수의 전달인자는 FT_UInt 형입니다. 내부적으로 unsigned int 형으로 재정의 되어있습니다. 그런데 Windows의 Unicode및 확장 아스키형의 형태가 2바이트 크기이고 Unicode는 보통 wchar_t형으로 사용합니다. 그런데 Posix에서는 wchar_t가 4바이트 이므로 이를 유의해야 합니다. 자칫 잘못하면 데이터의 값이 변환되는 과정에 -값으로 되어 Glyph를 제대로 못 얻을 수 있습니다. 물론 이 것은 데이터 취급의 문제 이니만큼 신경을 쓴다면 해결할 수 있습니다.

4. Part I에서의 FT_Face속 FT_Glyph는..

  Part I에서 Load_Glyph인가 그 함수를 사용하여 FT_Face멤버로 데이터를 적용시키는 부분이 있습니다. 그런데 이 부분은 짐작하기에 쉬우시겠지만 만약 이 해당 멤버를 문자 유닛별로 보관하려는 것은 하시면 안더군요. 물론 제가 이리저리 테스트를 하는 도중에 나왔던 결과라 적은 것이지만 Render_Glyph를 사용하여 호출하니 해당 Bitmap의 정보가 계속하여 덮어씌여지더군요.
  개개별적으로 처리되는 정보가 아니라는 말이겠죠. 어찌보면 당연한 얘기겠지만 혹시나 하더군요.