Calibri поставляется с таблицей EBLC и EBDT, которая сообщает текстовым механизмам, что для определенных размеров точек им не следует пробовать "свои собственные алгоритмы масштабирования", а просто использовать растровые изображения. вместо этого хранятся непосредственно в шрифте.
Каждый размер шрифта может поставляться со своим собственным списком «следующие глифы должны быть растровыми изображениями этого размера», называемыми «зачеркиваниями», поэтому один глиф может иметь несколько растровых изображений для разных размеров (но могут быть пробелы, и когда это происходит, растровые изображения необходимо масштабировать, и все может пойти катастрофически неправильно).
Например, у Calibri есть страйки для размеров точек 12, 13, 15, 16, 17 и 19, а пример растрового изображения для A:
<ebdt_bitmap_format_1 name="A">
<SmallGlyphMetrics>
<height value="8"/>
<width value="7"/>
<BearingX value="0"/>
<BearingY value="8"/>
<Advance value="7"/>
</SmallGlyphMetrics>
<rawimagedata>
10102828 447c8282
</rawimagedata>
</ebdt_bitmap_format_1>
На это растровое изображение указывает размер шрифта 12, и оно закодировано как растровое изображение размером 7x8 пикселей. Поскольку 12 — это наименьшее значение, мы сталкиваемся с проблемами, когда используем размер шрифта меньше 12: внезапно нам приходится масштабировать растровое изображение. Это может пойти только ужасно неправильно.
Если вы посмотрите на что-то вроде WordPad, вы увидите, что механизм Microsoft Uniscribe (используемый с GDI+; современным эквивалентом является Direct2D с DirectWrite в качестве текстового движка) может довольно хорошо масштабировать эти растровые изображения (показано размеры от 5 до 20), но даже собственная технология Microsoft имеет явные ограничения. Мы видим, что при размерах шрифта 5, 6 и 7 пикселей растровые изображения довольно ужасны, и даже 8, 10 и 11 выглядят довольно шатко:
Масштабируется до:
Все становится еще интереснее, потому что не каждый глиф представлен в каждом штрихе, поэтому, хотя «А» имеет растровое изображение с размером точки 12, существуют глифы, для которых наименьший размер точки с явным растровым изображением может быть 13, 15 или 16. или 17, или даже 19.
Это означает, что у вас есть три проблемы:
- Шрифт может «требовать», чтобы текстовый движок использовал его растровые изображения вместо того, чтобы пытаться растеризовать векторные контуры в соответствии с алгоритмами текстового движка, и
- Не существует волшебного размера шрифта, выше которого все символы отображаются «хорошо», а ниже — «плохо». Шрифт может иметь любое количество «штрихов», содержащих любое подмножество закодированных глифов шрифта, что фактически означает, что каждый символ может иметь свои собственные правила относительно того, когда текстовый движок должен переключаться с растеризованного вектора на встроенное растровое изображение, и
- Текстовые движки могут полностью игнорировать «требования» шрифта и в любом случае заниматься своими делами, и выяснить, какой движок что делает, практически невозможно, несмотря на то, что в нашем распоряжении есть Интернет. Это одна из тех вещей, которые, кажется, никто не документирует.
Самый простой способ узнать, какие шрифты будут это делать, — просто проверить шрифт для таблицы EBDT — если она есть, этот шрифт заставит движки использовать растровые изображения для очень маленьких (а иногда и очень больших) размеров шрифта. Если вам нужны подробности, вы можете запустить шрифт через TTX, а затем найти начало таблицы <EBDT>, чтобы увидеть что происходит на самом деле.
Однако приготовьтесь к тому, что вас переполнят. Например, только в Calibri растровые изображения указаны для более чем тысячи глифов.
person
Mike 'Pomax' Kamermans
schedule
01.05.2015
