Это НЕ TFontSignature, чёрт возьми!

Это перевод It isn't a FONTSIGNATURE, darn it! Автор: Майкл Каплан.

Я храню старые варианты Platform SDK.

Это занимает некоторое место, но также позволяет мне заглянуть назад во времени в документацию, так что я могу увидеть, откуда пошла та или иная ошибка. А также это замедляет меня от осуждения людей, которые ошибаются :-)

Если я посмотрю на вариант, который распространялся вместе с Visual Studio 6.0, то эта версия Platform SDK не упоминает LOCALE_FONTSIGNATURE.

Если я посмотрю на вариант от октября 2001-го, то увижу такой текст:

LOCALE_FONTSIGNATURE
Windows 95/98/Me, Windows NT 4.0 and later: битовая маска, используемая для определения отношения между покрытием символами, необходимом для поддержки локали и возможностями шрифта. Для дальнейшей информации см. FONTSIGNATURE.

У этого описания есть большая проблема: ведь функция возвращает вовсе не TFontSignature.

На самом деле возвращается весьма похожая запись: TLocaleSignature.

Я немного говорил про это (где вы также могли увидеть более новый вариант текста!), но я не объяснил, что делают эти две записи.

В общем, TFontSignature спроектирована как огромное битовое поле, которое предназначено для хранения всей информации о поддерживаемых шрифтом алфавитов. Вы можете получить эту информацию по шрифту, используя функцию GetTextCharsetInfo.

А TLocaleSignature (которая вроде как содержит TFontSignature) включает в себя алфавиты, которые должна адекватно поддерживать локаль в вопросе, плюс дополнительную информацию в виде битового поля кодовой страницы по умолчанию, которую нужно поддерживать шрифту.

Очевидно, комбинация шрифтов, описывающих, что они умеют делать, и локалей, описывающих, что им нужно, теоретически позволяет реализовать очень мощный механизм связывания/fallback/выбора шрифтов.

К сожалению, на практике это не работает - по многим причинам:

• В течение многих лет документация указывала неточную информацию со стороны локалей
• Так и не было сделано хороших примеров по использованию этой функциональности
• Качество данных, стоящих за TLocaleSignature не всегда было точным среди всех поддерживаемых локалей и всех версиях Windows
• Качество данных, стоящих за TFontFignature, предоставляемых шрифтами (как поставляемыми Microsoft, так и сторонними разработками), не всегда было 100% правдивым

Этот последний пункт не указывает на вину шрифтов или их создателей. Он скорее подчёркивает ограниченности всей структуры.

Потому что вполне законно создать шрифт, который (к примеру) поддерживает русский ИЛИ украинский ИЛИ белорусский ИЛИ боснийский, но не буквы, требующиеся для остальных трёх. И такой шрифт установит бит 9 (Cyrillic and Cyrillic supplementary) в битовых полях Unicode и соответствующие биты в полях кодовых страниц, даже хотя язык может поддерживать символы вне кирилических кодовых страниц. А в этом случае четыре разных шрифта для четырёх разных языков, каждый из которых имеет разные уровни поддержки кирилических символов, будут возвращать одну и ту же информацию!

В конечном итоге, цель TLocaleSignature/TFontSignature (быть описанием поддержки алфавитов и кодовых страниц) так никогда широко и не использовалась. Она иногда используется в редких случаях, но становится всё более редкой, так как другие более автоматические методы подбора шрифтов доказали своё более эффективное покрытие практических сценариев...

This post brought to you by "Җ" (U+0496, a.k.a. CYRILLIC CAPITAL LETTER ZHE WITH DESCENDER)