2010-06-14 2 views
1

나는이 같은 윈도우 글꼴을 열거하고 있습니다 :FONTSIGNATURE가 lfCharSet을 반영하지 않는 이유는 무엇입니까?

LOGFONTW lf = {0}; 
lf.lfCharSet = DEFAULT_CHARSET; 
lf.lfFaceName[0] = L'\0'; 
lf.lfPitchAndFamily = 0; 
::EnumFontFamiliesEx(hdc, &lf, 
        reinterpret_cast<FONTENUMPROCW>(FontEnumCallback), 
        reinterpret_cast<LPARAM>(this), 0); 

내 콜백 함수는이 서명이 :

int CALLBACK FontEnumerator::FontEnumCallback(const ENUMLOGFONTEX *pelf, 
               const NEWTEXTMETRICEX *pMetrics, 
               DWORD font_type, 
               LPARAM context); 

트루 타입 글꼴, 나는 일반적으로 각면의 이름을 여러 번 얻을. 예를 들어 여러 번 호출 할 경우 pelf->elfFullNamepelf->elfLogFont.lfFaceName"Arial"으로 설정합니다. 다른 필드를 자세히 살펴보면 각 호출이 다른 스크립트를 사용하고 있음을 알 수 있습니다. 예를 들어, 첫 번째 호출에서 pelf->elfScript"Western"이고 pelf->elfLogFont.lfCharSetANSI_CHARSET의 숫자와 같습니다. 두 번째 호출에서 나는 "Hebrew"HEBREW_CHARSET을 얻습니다. 제 3의 전화는 "Arabic"ARABIC_CHARSET입니다. 등등. 여태까지는 그런대로 잘됐다.

그러나 Arial의 모든 버전에 대한 font signature (pMetrics->ntmFontSig) 필드는 동일합니다. 사실, 글꼴 서명은 Arial의 이러한 모든 버전이 Latin-1, Hebrew, Arabic 및 기타를 지원한다고 주장합니다.

나는 그리려는 문자열의 문자 집합을 알고 있으므로 글꼴 서명을 기반으로 적절한 글꼴을 인스턴스화하려고합니다. 글꼴 서명이 항상 일치하기 때문에 히브리어 또는 아랍어 텍스트를 표시 할 때도 항상 "서양"글꼴을 선택하게됩니다. 낮은 수준의 Uniscribe API를 사용하고 있으므로 Windows 글꼴 연결의 이점을 얻지 못하고 내 코드가 작동하는 것 같습니다.

lfCharSet은 실제로 어떤 의미를 지니거나 유산 아티팩트입니까? lfCharSetDEFAULT_CHARSET으로 설정하고 각 얼굴의 모든 스크립트 변형에 대해 걱정하지 않아야합니까?

제 목적으로는 트루 타입 글꼴과 오픈 타입 글꼴 만 신경 씁니다.

답변

1

답변을 찾은 것 같습니다. 여러 번 열거 된 글꼴은 "big" fonts입니다. 큰 글꼴은 여러 스크립트 또는 코드 페이지에 대한 글리프가 포함 된 단일 글꼴입니다.

FONTSIGNATURE (fsUsb)의 유니 코드 부분은 글꼴에서 처리 할 수있는 모든 유니 코드 하위 범주를 나타냅니다. 이는 문자 집합과 무관합니다. 와이드 문자 API를 사용하는 경우 글꼴을 만들 때 지정된 문자 집합에 관계없이 글꼴에 포함 된 모든 글리프를 사용할 수 있습니다.

FONTSIGNATURE (fsCsb)의 코드 페이지 부분은 글꼴에서 처리 할 수있는 코드 페이지를 나타냅니다. 글꼴이 "큰"글꼴이 아닌 경우에만 이것이 중요하다고 생각합니다. 이 경우 fsUsb 마스크는 모두 0이며, fsCsb은 적절한 문자 세트를 지정합니다. 이 경우 에서 lfCharSet을 올바르게 입력해야합니다.

"큰"글꼴을 인스턴스화하고 와이드 캐릭터 API를 사용하는 경우 사용자가 지정하는 lfCharSet은 분명히 중요하지 않습니다.

관련 문제