가벼운 마음으로 중국 야후에 들러서 간체 몇 개를 복사해 찍어보았다. 결과는 허거덩~~



기껏 만들어 둔 폰트링크와 폴백은 다 건너뛰고 뜬금없이 등장한 네모박스라니...
코드를 따라가보니 굴림체에서 중국어 간체에 대해 ScriptShape 가 무조건 성공했다는 결과를 낸다.
글립에는 네모만 달랑 던져놓고 말이다.

꼽사리로 집어넣었던 베트남어 역시 굴림체에서 성공으로 리턴. 결과는 네모박스. 장난하냐???

ScriptShape 를 처리하기 전에 ScriptItemize 결과값에 대해 MLang으로 미리 체크해서 폰트변경이 필요하면 그만큼 ItemRun 을 나눠주기로 결정. Shape 루프에서 폰트 링크와 폴백을 처리하지 않고 Shape 전단계에서 폰트 링크를 처리하고 링크에 실패한 ItemRun 만 Shape 중간에 폴백을 시도한다.

이 경우 힌두어의 공백문자가 자체적인 넓적한 공백 대신 기본폰트의 공백으로 대체되는 문제가 생겨난다. 하지만 이건 나름 장점이 될 수 있겠다. 공백문자를 폰트별로 준비하지 않고 기준폰트의 글립만 사용하게 되므로 메모리를 절약할 수 있으니까.

또 한가지 문제는, 아랍어같은 RTL 문자열에서 중간에 들어간 공백이 ScriptShape를 거치면서 LTR로 속성이 바뀐다는 것이다. 이때문에 기껏 잡아줬던 아랍어의 레이아웃이 예전처럼 틀어져버린다. 고민하다가 Shape - Layout 의 순서를 Layout - Shape 로 뒤집어주니 해결된다. 혹시나싶어 catch22.net 의 강좌를 열어보니 거기도 Itemize - Layout - Shape 순서로 되어있군. 나 뭐한거지...

아무튼 구덩이 두 개 새로 파주니 이제야 제대로 동작하는 중국어와 베트남어.



어제까지 작업으로 대충 리서치는 마무리된 줄 알았는데... 앞으로 또 무슨 문제가 튀어나오려나...


한가지 팁. ScriptShape 사용중에 표준컨트롤을 참조하게되면 얼토당토않은 에러가 발생한다. 폰트 폴백 만들기가 귀찮아서 리치에디트 컨트롤을 써먹어보려고 잔머리 굴리다 Uniscribe가 이상하게 동작하는 바람에 실패를 했는데, 폴백폰트 목록을 리스트박스에 임시로 넣어두고 꺼내려고 하니 동일한 문제가 생긴다. 유니스크라이브 루프 내에서는 윈도컨트롤에 접근하지 말자.

ScriptLayout 이 원래 이 일을 해 주어야 하는데... 처음에 호출하는 ScriptItemize 의 인자값인 SCRIPT_CONTROL 과 SCRIPT_STATE 에 뭔가 비밀이 있을 것 같아 이리저리 뜯어맞춰봐도 제대로 된 표시를 얻을 수 없었다.

우연히 읽게 된 재미난 문서.
http://maxradi.us/documents/uniscribe/

MSDN에는 SCRIPT_CONTROL 값 대신 NULL을 넘겨도 관계없다고 되어있지만, 실제 이렇게 할 경우 RTL 정보를 제대로 얻을 수 없다는 언급이 있다. 응?? RTL?? 난 지금까지 catch22.net 의 강좌대로 클러스터의 요소가 배열증가에 따라 감소하는지 여부로 RTL을 판단했었는데??

아무튼 시키는대로 0으로 초기화한 구조체를 넘겨주니까, ScriptItemize로 얻은 ItemRun 의 ScriptAnalysis 정보에 fRTL 값이 제대로 설정된다. 그리고 그 옆에 fLayoutRTL 이라는 플래그도 눈에 띄네~~ 오오~~ 이거 혹시 이거 레이아웃에 쓰이는 RTL 정보 아냐??

ScriptLayout을 호출할 때 지금까지 썼던 ScriptAnalysis 의 uBidiLevel 대신 이 fLayoutRTL 을 넘겨줘 보았다. uBidiLevel은 ScriptItemize 호출시 SCRIPT_STATE에 지정한 값이 그대로 튀어나오길래 이상하다고 생각하고 있었거덩. 이렇게 하니 제대로 된 LogiclaToVisual 정보가 뽑힌다. 뒷발로 쥐밟은 격이지만 아무튼 만쉐~~!!