2015-03-24 7 views
5

Мне интересно знать, где резерв шрифта помещается в стек формирования/рендеринга шрифтов. Другими словами, в какой момент отсутствуют глифы и как они заменяются?Как веб-браузеры реализуют резерв шрифта?

Я вижу в документе this, что инструмент FontConfig делает откат шрифта «на основе прозрачности глифа прозрачным».

Так вопросы:

  1. Как именно этот алгоритм работает?
  2. Это стандартный алгоритм, используемый большинством браузеров - webkit, gecko (возможно, не IE)?
  3. Каким образом резервное копирование шрифта на основе отсутствующих глифов внутри существующего шрифта относится к исправлению шрифта CSS (который указывает, какие шрифты использовать по очереди, когда шрифт полностью отсутствует)?

Редактировать: Я нашел this документ, который объясняет «что» FontConfig, но не «как». Вопрос 1 касается «как».

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

ответ

7

шрифт запасной вариант в браузерах (в отличие, скажем, в ОС) базируется на двух вещах:

  1. спецификации CSS, которая дает шрифты, которые должны быть использованы для нейтрализации неисправности, и
  2. Текстовый движок, который выполняет форматирование текста.

Спецификация CSS довольно тривиальна в этом отношении, просто предоставляя список шрифтов, используя их системные имена, но несколько возможных «улавливать все» шрифты, которые никоим образом не гарантируются одинаковыми с компьютера на компьютер (нет оснований полагать, что serif относится к Times или Times New Roman, например).

Резервный алгоритм, используемый текстовыми движками, полностью зависит от движка, но обычно срабатывает во время шага поиска глифа: текстовый движок видит строку кодовых точек и пытается использовать шрифт для формирования этой строки. Для каждой точки в последовательности он проверяет, имеет ли шрифт соответствующий глиф (консультируясь с таблицей CMAT и субтитрами) или правило, сообщающее движку, что глиф может использоваться только в том случае, если последуют больше кодовых точек, через механизм GSUB (например, шрифт без символов для отдельных букв e, t и c, но глиф для & и правила GSUB что говорит последовательность e + t + c должно быть в тексте заменены на один глиф &), и когда он закончил накапливать этот «единицу точек», он формирует текст и возвращает его к тому, что его просило форматировать текст.

Если во время поиска глифа оказывается, что шрифт не содержит ничего, что позволяет двигателю формировать конкретную кодовую точку (т. Е. Пробегать данные CMAP, а также правила GSUB по-прежнему показывают «нет глифа»,), то текстовый движок может делать две вещи:

  1. Отказ. Нет глифа, вместо этого используйте контур .notdef, определенный как идентификатор глифа 0, и, как правило, вы получаете текст с прекрасными пустыми ячейками (с любовью называемыми «tofu» шрифтами) или вопросительными знаками.
  2. Покушение шрифта запасного вариант, где он будет попробовать другой шрифт, чтобы найти глиф для неподдерживаемой кодовой точки в

При использовании запасного варианта, двигатель не может пойти вниз список альтернативных шрифтов, пока либо:. (А) глиф, или (b) список исчерпан, и в этот момент двигатель имеет, чтобы отказаться, и будет использовать глиф .notdef. Независимо от того, захватит ли двигатель глиф .notdef от исходного шрифта или от последнего шрифта в списке, полностью зависит от движка (хотя обычно он будет работать с первым шрифтом, для разборчивости)

Нет никакого " стандартный "алгоритм для этого определяется где угодно; font backback - это в основном механизм удобства, предлагаемый авторами текстовых движков, например, как браузеры работают с менеджерами закладок (удобными, а не частью любой спецификации). Что касается OpenType, нет никаких требований относительно того, должен ли движок просто обслуживать .notdef, когда глиф не найден, или он должен обслуживать часть, которую он мог бы сформировать, затем найти отсутствующий глиф в другом месте и отобразить текст сюда. CSS подразумевает, что ваш текстовый движок должен иметь по крайней мере некоторую форму резервного копирования шрифта, но он не указывает, как он должен работать, или когда он должен начинать.

+0

Спасибо - это действительно информативно. Я хотел бы получить более подробную информацию о том, как на самом деле происходит откат шрифта в любом браузере, чтобы получить представление об этом процессе. Это кажется гораздо более критичным, чем «удобство» - от этого зависит много веб-контента. Я предполагаю, что резервное копирование относится не только к резервному списку шрифтов css (или он?). Я удалил тег css. Stackoverflow настаивает на том, чтобы сначала поставить это, придав ему вводящий в заблуждение акцент. Меня не интересует CSS как таковой, поскольку вы указываете, что спецификация тривиальна относительно отбрасывания шрифта. – bright

+0

Редактировать: Так что я ошибся выше. Я думал, что спецификация css касается только исправления шрифта в ситуации, когда шрифт полностью отсутствует. Но, читая спецификацию немного более внимательно, похоже, что это касается самого случая отсутствия глифов. Поэтому я отмечаю ваш ответ как принятый. – bright

+0

это не браузер так сильно, как «текстовый движок», поэтому Firefox и Chrome, например, используют [harfbuzz] (http://www.freedesktop.org/wiki/Software/HarfBuzz/), IE, я полагаю, полагается на [Uniscribe] (https://msdn.microsoft.com/en-us/library/windows/desktop/dd317713%28v=vs.85%29.aspx). И да, это определенно связано с CSS, шрифты используются на основе глифа (спасибо = D) –