Что случилось со шрифтом Arial Unicode MS?

Это перевод What happened to the Arial Unicode MS font? Автор: Реймонд Чен.

Клиент хотел узнать, что случилось со шрифтом Arial Unicode MS. Раньше он устанавливался вместе с Microsoft Office, но был удалён из Microsoft Office 2016. По этому поводу было придумано множество различных теорий заговоров.

Подводные камни вывода сглаженного текста с прозрачным фоном

Это перевод Pitfalls of transparent rendering of anti-aliased fonts. Автор: Реймонд Чен.

Windows предоставляет несколько технологий рендеринга монохромного текста на цветных экранах, пользуясь преимуществами характеристик экрана для предоставления гладкого результата. Эти техники включают в себя сглаживание (grayscale anti-aliasing), а также и более продвинутую технику - ClearType. Обе техники читают фоновые пиксели, чтобы определить, что рисовать. Это означает, что рендеринг текста требует дополнительного внимания.

Как [то, что вызывают] общие элементы управления, конвертирует строки между ANSI и Unicode?

Это перевод How do[es what] the common controls [call ]convert between ANSI and Unicode? Автор: Майкл Каплан.

Ранее Реймонд Чен писал о том, Как общие элементы управления конвертируют строки между ANSI и Unicode?, отвечая на вопрос в его suggestion box:

В контексте ansi (не unicode) приложения: как общие элементы управления (к примеру, listview) решают, какую использовать кодовую страницу для перевода многобайтовых строк в widestring?

Мне пришлось отлаживать ansi приложение, которое показывало испорченные строки на системе с традиционным китайским, потому что шрифт диалога привёл к тому, что listview использовал иную кодовую страницу, нежели системную ACP, при переводи multibyte в widechar.

Хотя я редко, если вообще когда-нибудь, не соглашусь с чем-то, что исходит из лагеря команды Оболочки, конкретно в этом случае я знаю два конкретных исключения из правила CP_ACP, которое вы обычно видите, хотя эти отличия могут иметь мало общего с кодом Shell / comctl32, так что Реймонд может быть прав в своей области :-)

Что это за волшебная настройка, которая синтезирует Unicode из не-Unicode?

Это перевод What is this magic setting that synthesizes Unicode from non-Unicode? Автор: Реймонд Чен.

Комментатор dan g. спросил как Windows может обращаться с не-Unicode приложениями как с Unicode приложениями через апплет Региональные и языковые настройки Панели управления (перевод поста), особенно в части, которая даёт вам выбрать язык для не-Unicode программ. "Я всегда считал, что единственным способом показывать, скажем, китайские символы будет компиляция программы в Unicode, но эта настройка, кажется, намного проще".

А я могу поместить свои символы в Unicode?

Это перевод Can I get my characters into Unicode? Автор: Майкл Каплан.

Когда-то Иван Петров указал:

...быть может НАИБОЛЬШАЯ проблема в отсутствии многих кирилических гласных букв с тупыми ударениями в Unicode и, соответственно, в кодовой странице ANSI 1251. В Unicode определены только 2+2=4 (CAPITAL и SMALL буквы с ударениями – #CYRILLIC CAPITAL LETTER IE WITH GRAVE, #CYRILLIC CAPITAL LETTER I WITH GRAVE, #CYRILLIC SMALL LETTER IE WITH GRAVE and #CYRILLIC SMALL LETTER I WITH GRAVE).

Полный список гласных в кирилице должен быть:

#CYRILLIC CAPITAL LETTER A WITH GRAVE
#CYRILLIC CAPITAL LETTER IE WITH GRAVE
#CYRILLIC CAPITAL LETTER I WITH GRAVE
#CYRILLIC CAPITAL LETTER O WITH GRAVE
#CYRILLIC CAPITAL LETTER U WITH GRAVE
#CYRILLIC CAPITAL LETTER HARD SIGN WITH GRAVE
#CYRILLIC CAPITAL LETTER YERU WITH GRAVE (только для русского языка)
#CYRILLIC CAPITAL LETTER E WITH GRAVE (только для русского языка)
#CYRILLIC CAPITAL LETTER YU WITH GRAVE
#CYRILLIC CAPITAL LETTER YA WITH GRAVE
#CYRILLIC SMALL LETTER A WITH GRAVE
#CYRILLIC SMALL LETTER IE WITH GRAVE
#CYRILLIC SMALL LETTER I WITH GRAVE
#CYRILLIC SMALL LETTER O WITH GRAVE
#CYRILLIC SMALL LETTER U WITH GRAVE
#CYRILLIC SMALL LETTER HARD SIGN WITH GRAVE
#CYRILLIC SMALL LETTER YERU WITH GRAVE (только для русского языка)
#CYRILLIC SMALL LETTER E WITH GRAVE (только для русского языка)
#CYRILLIC SMALL LETTER YU WITH GRAVE
#CYRILLIC SMALL LETTER YA WITH GRAVE

Так что мой третий вопрос:

“Что можно сделать с этой проблемой?”

См. для дальнейшей информации:
http://titus.uni-frankfurt.de/unicode/unicsel/unicself.htm#Cyrillic

Львы, тигры и медведиЛОСИ - о, боже!

Это перевод Lions and tigers and bearsELKs, Oh my! Автор: Майкл Каплан.

Осенью 2004 Cathy Wissink и я были в San Jose на встрече технического комитета Unicode (проводимой в Apple) вместе с 20+ моих коллег, работающих с интернационализацией, из различных компаний. В один вечер у нас была речь на встрече IMUG (International Multilingual User's Group), которая была расширенным вариантом выступления до этого на предыдущих конференциях по интернационализации, Unicode и конференции Microsoft по глобализации. Всё стало ближе к выпуску, так что больше можно было сказать, а поскольку нам выделили больше времени, нам определённо можно было рассказать больше.

Название выступления? "Windows для остального мира - модификация Windows для новых рынков". Этот пост будет содержать несколько слайдов с этого выступления :-)

Ещё один налог для отсутствия поддержки Unicode?

Это перевод Yet another cost to not supporting Unicode? Автор: Майкл Каплан.

Очень трудно печатать, когда у тебя растяжение плеча. Слава богу, есть Dragon Dictate! Это я просто так...

Alex спросил меня в Suggestion Box:

Привет, Майкл.

Я погуглил по твоему блогу, но не нашёл ответа на такой вопрос. Этот вопрос довольно популярен (по крайней мере, в России), и я был удивлён, что ты его ещё не покрыл. Так что, быть может, ты расскажешь историю за этим вопросом. Это вопрос про буфер обмена, текст и не Unicode приложения.

Возьми старое не Unicode приложение (вроде блокнота из Win9x) и запусти его на новых Windows (вроде XP), которая имеет два установленных языка (скажем, английский и русский). Предположим, что "Язык для не Unicode приложений" установлен в "Русский".

В Win9x ты мог без проблем скопировать текст через буфер обмена из любого приложения в любое другое. Конечно, старые приложения не заботились об установке CF_LOCALE вместе с CF_TEXT, но всё работало довольно прилично, поскольку приложениями использовалась одна и та же кодовая страница (ладно: почти всеми).

Теперь, возьми современную, "юникодную" ОС, вроде XP. Ты берёшь своё старое приложение, которое верой и правдой служило тебе много лет, копируешь текст в буфер и вставляешь в другое приложение (скажем, блокнот из Windows XP) и... ух ты: ты получаешь вопросительные знаки или белиберду. Что не так? Чёрт, ты забыл переключить клавиатуру на "Русский". Как только ты это сделаешь - всё начнёт работать нормально.

Верхний ряд: слева - блокнот из Win98, справа - блокнот из XP. Нижний ряд: слева - блокнот из XP, справа - из Win98. Текущий язык стоит в "English (United states)" (ну, т.е. мы не переключили на русский). Красные линии указывают операцию копирования текста через буфер обмена (я специально взял два приложения от Microsoft, чтобы указать, что это не баг в каком-то конректном стороннем приложении).

Проблема (как я её вижу) заключается в получении Unicode-текста из ANSI-текста. Почему Windows использует для этого метод ввода, а не "Язык для не Unicode приложений"?

Это ужасное нарушение в опыте использования. Большинство людей считают, что это баг. Я очень часто слышу эту жалобу (чёрт, да я слышу проклятия Microsoft почти всегда в таких случаях). Особенно тяжело объяснить, что это не баг в твоём приложении, написанном много лет назад - оно не виновато.

Не мог бы ты пролить немного света на эту проблему? Почему Microsoft решила (ладно, не сломать, но) усложнить жизнь базилионам существующих приложений? Если Microsoft так заботится об обратной совместимости, то почему было сделано такое решение?

Это звучит очень знакомо.

Что, чёрт возьми, не так с TranslateCharsetInfo?

Это перевод What the hell is wrong with TranslateCharsetInfo, anyway? Автор: Майкл Каплан.

Однажды у Колина появился клиент с вопросом о неожиданном поведении функции TranslateCharsetInfo:

У моего клиента есть проблемы с API TranslateCharsetInfo. Они указывают флаг TCI_SRCLOCALE для использования LCID как источника:

fResult := TranslateCharsetInfo(langid, csi, TCI_SRCLOCALE);

Они обнаружили, что результаты этого вызова не всегда соответствуют значениям, указанным в http://www.microsoft.com/globaldev/nlsweb/default.mspx

В частности:
LCID $0C04 – Chinese (Hong Kong S.A.R.) - возвращает кодовую страницу 936 вместо ожидаемой 950
LCID $0004 - Chinese (Simplified) – возвращает кодовую страницу 950 вместо ожидаемой 936

То, что я вижу - это ожидаемое поведение или нет? Если нет, то какой есть другой способ?

Мы также попробовали:

GetLocaleInfo(langid, LOCALE_IDEFAULTANSICODEPAGE, szLocaleData, SizeOf(szLocaleData)/SizeOf(Char));

Хотя этот способ возвращает 950 для LCID $0C04 (уже лучше), но LCID $0004 всё ещё возвращает 950 вместо 936.

Или я что-то упускаю?

Many thanks,
Colin

Результаты двух значений LCID на самом деле вызваны двумя совершенно различными причинами.

Нормализация и Microsoft - что у нас за история с ними?

Это перевод Normalization and Microsoft -- whats the story? Автор: Майкл Каплан.

Нормализация - это слово, которое явно перегружено смыслами. С тех пор, как я пришёл в Microsoft, к сегодняшнему дню я услышал, по меньшей мере, четыре отдельных случая:

• Оно используется командой SQL сервера, когда они говорят о сравнениях строк.
• Оно используется API сопоставления NLS по той же причине (флаги NORM_*), ссылаясь на потенциально игнорируемые различия в строках при сравнении.
• Robert A. Wlodarczyk использовал термин строковой нормализации, ссылаясь на более общий тип поиска, включающий в себя нечёткое сравнение строк.
• В Unicode есть технический отчёт, названный Unicode Normalization Forms (формы/виды нормализации Unicode), который определяет технику для "сворачивания" (folding out) различий в эквивалентных последовательностях.

А смотря на определения этого слова в dictionary.com:

• Сделать что-то нормальным, в смысле соответствия норме или стандарту
• Сделать (текст или язык) регулярным и согласующимся, особенно по отношению к стилю и орфографии
• Удалить штаммы и снизить грубую кристаллическую структуру (металл), особенно нагреванием и охлаждением
• Уменьшение до стандартного или нормального состояния

Я считаю, что только в случае с Unicode это слово используется правильно, хотя, быть может, случай "строковой нормализации" не так далёк от этого. Ну, команде SQL сервера не повезло (хотя у них есть преимущество, что это слово не наплюхано по их официальной документации и заголовочникам - только те из клиентов, кто связывается с ними, слышат это слово). И, конечно же, тем из нас, кто работает над NLS. Упс!

Но, отстраняя вопросы терминологии, поддерживает ли сопоставление/collation (как операция) концепции, описанные в нормализации Unicode? Другими словами, рассматривает ли функция CompareString символ U+00c5 (Å, LATIN CAPITAL LETTER A WITH RING ABOVE) как эквивалент U+0041 U+030a (Å, LATIN CAPITAL LETTER A + COMBINING RING ABOVE)?