Ответ 1

Консоль Windows ограничена базовой многоязычной плоскостью

Ваша ссылка на Функция WriteConsole ничего не говорит о полезных символах консоли:

• lpBuffer [in] Указатель на буфер, содержащий символы, которые должны быть записаны в буфер экрана консоли.

Но что это за буфер? Простой поиск Google для структуры writeconsole lpbuffer дает (косвенную) ссылку на структуру CHAR_INFO:

Синтаксис (С++)

typedef struct _CHAR_INFO {
  union {
    WCHAR UnicodeChar;
    CHAR  AsciiChar;
  } Char;
  WORD  Attributes;
} CHAR_INFO, *PCHAR_INFO;

Но что такое WCHAR UnicodeChar? Опять же, простой поиск Google для Windows wchar дает ссылку на Типы данных Windows:

• WCHAR Символ Unicode 16-разрядный. Для получения дополнительной информации см. Наборы символов, используемые шрифтами. Этот тип объявляется в WinNT.h следующим образом: typedef wchar_t WCHAR;

И наконец, выше Ссылка на символы, используемые шрифтами, дает следующий конечный результат: Консоль Windows ограничена базовой многоязычной плоскостью, то есть 16-разрядное подмножество Unicode:

Набор символов Unicode

... Чтобы решить проблему множественных схем кодирования, Unicode был разработан стандарт представления данных. A 16-разрядный символ схема кодирования, Unicode может представлять 65 536 (2 ^ 16) символов, что достаточно для включения всех языков в компьютерную коммерцию сегодня, а также как знаки препинания, математические символы и место для расширения. Unicode устанавливает уникальный код для каждого символа, чтобы гарантировать, что перевод символов всегда точен.

Ответ 2

Я написал частичный ответ в ответе на другой вопрос; здесь есть хорошее место для полного раскрытия. Мой опыт: я поддерживаю то, что, по всей вероятности, самый обширный шрифт консоли, который полностью поддерживает Windows (это очень глубокая переработка Unifont с добавленными элементами DejaVu).

Я начинаю с ограничений, уже упомянутых в других ответах:

• Каждая ячейка содержит 16 бит символьных данных. Другими словами: показаны только кодовые точки UCS-2. (В частности, для символа из BMP вместо этого отображается его "декомпозиция в UCS-2", используя суррогатные символы.)

• поддерживается только простой текстовый рендеринг. Даже если вы используете шрифты TTF, никакие расширенные "функции" шрифта не рассматриваются консолью. Ни предварительная типография (лигатуры и т.д.), Ни даже составление глифов для составления персонажей или скриптов справа налево¹⁾ (в среде LtR) работали бы так, как ожидалось.

  ¹⁾ Это приложение, которое должно изменить символы для правильного биди-рендеринга.

Фильтрация шрифтов

Другие ограничения связаны с фильтрацией шрифтов с помощью консоли. Шрифт должен быть довольно особенным, чтобы его можно было принять консолью (отображается в диалоговом окне выбора шрифта, и этот выбор "работает" ¹⁾).

¹⁾ Я не помню, может ли отображаться шрифт, но не будет выбран (я имею смутное воспоминание об этом, но не могу доверять этой памяти).

• Шрифт должен быть помечен как моноширинный. Из-за ожиданий приложений, такие шрифты должны иметь все глифы одинаковой ширины.

  Последнее условие имеет значение только в том случае, если вы хотите использовать шрифт вне консоли. В принципе, консоль не проверяет ширину глифов. Однако каждый глиф показан так, как если бы он имел "ширину по умолчанию". Во многих (всех?) Ситуациях будет отображаться только часть глифа внутри "рамки ограничения по умолчанию". Я не мог найти никакого трюка, чтобы обойти это ограничение.

• В не-восточных версиях Windows шрифт не может утверждать, что он поддерживает любую из 4 восточноазиатских кодовых страниц.

  ³⁾ Обратите внимание, что это только ограничение того, что утверждает заголовок шрифта, - это всего 4 бита, присутствующих в заголовке. У шрифта могут быть глифы для этих языков, и они будут хорошо отображаться - поскольку шрифт не требует поддержки. Кодировки, о которых идет речь (в разделе OS/2⫽Charsets заголовка), являются 932, 936, 949, 950 (JIS, упрощенный китайский, корейский Wansung, традиционный китайский).

Ошибки при визуализации шрифтов

• Хотя консоль Windows не поддерживает атрибут Underline (за исключением кодовых страниц DBCS), поле " Underline position " заголовка шрифта учитывается при вычислении размера экранного символьного bbox. Это может привести к неожиданному соотношению сторон шрифта и/или к прерываниям между глифами, которые, как ожидается, будут "объединяться".

• Консоль очень разборчива относительно замены глифа для "неподдерживаемых символов". Я не мог найти, как сделать такой глиф сосуществующим с наличием глифов для U+0000 и/или U+0001. (Если консоль находит один из последних двух символов в шрифте, он игнорирует глиф замены).

• (Это очень непонятная ошибка, это требует очень технического обсуждения.) Еще одна проблема с U+30FB замены - символ U+30FB · (ПОЧЕМУ?!). Если этот символ присутствует в шрифте, глиф для этого символа используется в качестве замены глифа - но только для отсутствующих символов в PUA!

По сути, вот оно! Я не нашел другого ограничения.