FontTools: извлечение полезной информации UTF, предоставленной им

Question

FontTools производит некоторые XML со всеми видами деталей в этой структуре

  <cmap>
    <tableVersion version="0"/>
    <cmap_format_4 platformID="0" platEncID="3" language="0">
      <map code="0x20" name="space"/><!-- SPACE -->
         <!--many, many more characters-->
    </cmap_format_4>
    <cmap_format_0 platformID="1" platEncID="0" language="0">
      <map code="0x0" name=".notdef"/>
         <!--many, many more characters again-->
    </cmap_format_0>
    <cmap_format_4 platformID="0" platEncID="3" language="0"> <!--"cmap_format_4" again-->
      <map code="0x20" name="space"/><!-- SPACE -->
         <!--more "map" nodes-->
    </cmap_format_4>
 </cmap>

Я пытаюсь выяснить каждый символ, который поддерживает этот шрифт, поэтому они code Атрибуты - это то, что меня интересует. Я считаю, что правильно думать, что все code атрибуты являются значениями UTF-8: это правильно? Мне любопытно, почему есть два узла cmap_format_4 (они кажутся идентичными, но я не проверял это с полным количеством шрифтов, так что, если кто-то, знакомый с этим модулем, наверняка знает, это мой первый вопрос).

Чтобы быть уверенным, что я вижу все символы, содержащиеся в гарнитуре, мне нужно объединить все code значения атрибута, или только один или два. Будет ли FontTools всегда создавать эти три узла XML, или это переменная количества? Есть идеи почему? Документация немного расплывчата.

Answer 1

• количество узлов cmap_format_N ("подтаблиц cmap") является переменным, как и "N" (формат). Есть несколько форматов; наиболее распространенным является 4, но есть также формат 12, формат 0, формат 6 и некоторые другие.

• у шрифтов может быть несколько подтаблиц cmap, но это не обязательно. Причиной этому является история развития TrueType (которая превратилась в OpenType). Формат был изобретен до Unicode, в то время, когда каждая платформа имела свои собственные способы отображения символов. Различные форматы и возможность иметь несколько отображений были необходимы в то время, чтобы иметь один файл шрифта, который мог бы отображать все без нескольких файлов, дублирования и т. Д. В настоящее время большинство производимых шрифтов будет иметь только одну подтаблицу Unicode, но есть много плавающих вокруг, которые имеют несколько подтаблиц.

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

• Я думаю, что ваш шрифт может быть поврежден (или, возможно, произошла путаница копирования / вставки). Можно иметь несколько записей cmap_format_N в cmap, но каждая комбинация platformID/platformEncID/language должна быть уникальной. Также важно отметить, что не все подтаблицы cmap отображают Unicodes; некоторые выражают более старые кодировки до Unicode. В качестве крайней меры вы должны сначала взглянуть на таблицы, где platformID="3", затем platformID="0" и, наконец, platformID="2". Другие ID платформы не обязательно отображают значения Unicode.

Что касается обнаружения "всех Юникодов, отображаемых в шрифте": это может быть немного сложно, когда есть несколько подтаблиц Юникода, особенно если их содержимое отличается. Вы можете быть ближе, принимая союз всех code значения во всех подтаблицах, которые, как известно, являются картами Unicode, но важно понимать, что большинство платформ будет одновременно использовать только одну из карт. Обычно есть предпочтительный порядок комплектования, подобный тому, что я изложил выше; когда кто-то найден, это тот, который используется. Там нет стандартизированного порядка предпочтений, который применяется ко всем платформам (о которых я знаю), но большинство популярных из них следуют порядку, очень близкому к тому, что я перечислил.

Наконец, относительно Unicode против UTF-8: code значения - это кодовые точки Unicode; НЕ UTF-8 байтовых последовательностей. Если вы не уверены в разнице, потратьте некоторое время на чтение кодировки символов и сериализации байтов на Unicode.org.