Как определяется, какой символ шрифта отображается при использовании определенной кодировки символов?

Я пытаюсь понять всю историю появления текста на экранах. Для простоты я остаюсь с однобайтовыми кодировками (без Unicode).

На моем диске есть последовательность байтов, каждый со значением от 0 до 255. Затем я могу сообщить своим компьютерным программам, какую кодировку символов они должны использовать для отображения этих байтов. Я мог бы использовать ISO-8859-1, где, например, байт со значением 0xA4 - это круг с точками (¤). Или я мог бы переключиться на ISO-8859-15, тогда мой байт со значением 0xA4 определяется как символ евро (€).

Это все еще просто понять. Но параллельно с изменением кодировки символов я также могу изменить шрифт, чтобы определить точную форму символа. Теперь шрифт предназначен для работы со всеми кодировками символов. Итак, шрифт должен иметь оба символа: ¤ и €.

Итак, шаги, чтобы получить текст на моем экране, очевидно:

  1. Читать последовательность байтов последовательно
  2. Используйте числовое значение текущего байта для поиска в таблице кодировки символов
  3. Используйте [что-то] для поиска в файле шрифта, чтобы получить точную форму символа, найденного на шаге 2
  4. Нарисуйте символ как определено в файле шрифта

На шаге 3, что это за "что-то", которое используется для сопоставления кодировки символов со шрифтом? Зависят ли файлы шрифтов от кодировки символов? Итак, есть ли у шрифта какой-то встроенный механизм "двойного переключения", который работает как (псевдокод)

get_symbol(code, encoding) {
  switch code{
    case 0xA4: switch(encoding) {
      case 'ISO-8859-1' : return '¤';
      case 'ISO-8859-15': return '€';
    }
  }
}

?

Каковы подробности, как получить из заданной последовательности байтов и заданной кодировки символов фактический символ из шрифта? Как это отображается, чтобы всегда давать правильный символ?

Источник

2 ответа

Решение

Файлы шрифтов предназначены для отображения определенной кодировки. Программа, использующая данный шрифт, должна предполагать, что значение n в заданной кодировке отображается путем рендеринга соответствующего номера глифа n,

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

Из приведенного примера OP, вероятно, использует систему X Window. Используется более одного формата файла с соответствующими способами доступа к ним. Основными из них являются XLFD (более старый) и fontconfig (более новый). В других системах (Microsoft Windows) используются другие API (LOGFONT структура является хорошей отправной точкой). Другой пример - OSX со своим собственным API ( CoreText).

Те, конечно, для графических интерфейсов. Шрифты более широко применяются, чем это. Например, Linux и BSD позволяют указывать разные консольные шрифты, которые помимо кодирования сталкиваются с ограничениями на количество используемых глифов. Вот несколько полезных ссылок для тех:

Источник

Приложение для рисования текста указывает шрифт в используемых API-интерфейсах для рисования текста или, если оно не указывает, используется системный шрифт по умолчанию.

Системы рисования текста на основе Unicode часто имеют алгоритм замены шрифта, чтобы найти шрифт, который содержит определенный глиф, если указанный шрифт не имеет запрошенного глифа. Но системы, предшествующие Unicode, обычно просто не в состоянии нарисовать глиф или нарисовать глиф "недостающего глифа". Даже основанные на Unicode системы иногда рисуют символ "недостающего символа".

Источник
Другие вопросы по тегам