Разбираемся, почему это плохо и что делать верстальщику, когда в макете утвержден «небезопасный» шрифт
Нестандартные шрифты в верстке
Сибирикс

Нестандартные шрифты в верстке

Почему shit happens?
В сети есть множество инструкций для начинающих дизайнеров — о том, чего нельзя делать в макете. Например, посмотрите эту статью на Хабре.

Однако даже при соблюдении всех написанных гайдов, может возникнуть сложная ситуация — например, в случае, когда заказчик настаивает на использовании конкретного нестандартного шрифта.

Под давлением руководитель проекта «пропускает» указанный шрифт, дизайнер применяет его, заказчик утверждает. А веселее всех придется верстальщику.

Сначала немного теории

Небольшая иллюстрация:
Загадка: будут ли шестерни вращаться на конструкции номер 4?
Пусть вот эта эволюция шестеренок показывает то, как создается интернет-проект. А иконки человечков выше — будут специалистами, отвечающими за каждый этап работ.

Значит ли это, что первый работник более свободен в «производстве»? Что, к примеру, он может выточить шестеренку не с восемью зубцами, а с двенадцатью и повернуть ее на угол в 37,5 градусов? Значит ли это, что замыкающий производство работник должен больше всех париться: чтобы его шестеренка подошла по диаметру, положению, углу поворота?

Два раза нет. Чтобы производство происходило без сбоев и задержек, каждый из работников должен учитывать специфику работы на следующих этапах. Отгружать качественный продукт и не создавать лишней работы ни другим, ни себе в будущем.

Все стараются следовать указанной заповеди, но, как мы уже увидели, это не всегда получается. Иногда по неосторожности дизайнера, иногда по необдуманности решения PM’а, иногда из-за упертости заказчика.

Что делать верстальщику, когда в макете утвержден «небезопасный» шрифт?

Ну, все, кто знаком с версткой, знают про таблицы безопасных шрифтов:
С этими проблем не возникает: верстальщик задает в CSS шрифты в последовательности приоритетов — шрифты отображаются корректно под любыми браузерами.

Но если шрифт «небезопасный»?

Нам не подходит вариант с картинками вместо текста — это вообще ни в какие стандарты качества не лезет.

Вариант 1. Google Web Fonts

Гугл создал свою базу шрифтов, которыми можно свободно пользоваться при создании дизайна и не задумываться о последствиях. Когда верстальщик получит макет, он просто укажет путь к нужному шрифту на сервере Гугла.
Корпорация Добра подарила миру целую кучу полезных вещей и не останавливается на этом.

Однако вариант с Google Web Fonts не всегда оказывается пригодным. Например, если дизайнер использовал шрифт, которого нет в базе (а там не так уж много кириллических шрифтов). Что делать? Менять на другой нельзя, потому что макет утвержден.

Вариант 2. Значение @face-font для CSS

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

Далее задача верстальщика сводится к прописыванию в CSS полученного кода и — сайт преображается в то, что себе представлял дизайнер.

Причем подо всеми браузерами. К примеру, старый IE 6 «ест» только шрифты в формате EOT, и благодаря @face-font вы получите корректное отображение шрифта на сайте и под IE (он будет ссылаться на файл в формате EOT, другие браузеры будут «тянуть» привычные им форматы TTF, OTF, SVG или даже WOFF).

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

Вариант 3. Cufon для JavaScript

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

Итак, загружаем шрифт, тот преобразуется в некий промежуточный формат. Верстальщик выбирает элементы для прорисовки (да, именно для прорисовки — здесь шрифты будут «вырастать» на странице сайта в реальном времени путем рендеринга).

Получаем результат, который более-менее адекватно выглядит под разными браузерами.

Но!

У Cufon’а есть свои недостатки. Например:

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

История одного проекта, или «Буква О какая-то советская»

У нас был один заказчик, которому очень понравился шрифт Myriad Pro, коим дизайнер оформил все заголовки. Клиент прямо-таки влюбился в шрифт.

Макет утвердили, всех все устраивало, руководитель проекта с чувством выполненного долга передал дизайн на верстку.

И началось.

Естественно, что в «шрифтах для веба» от Гугла его не нашлось.

Сначала попробовали стандартные способы с заменой на похожие DIN Pro и PT Sans (тогда мы еще не знали о влюбленности клиента). Ожидаемо, что получили несгибаемый отказ. Аргументация как раз была из разряда: «в этих ваших шрифтах буква О выглядит слишком по-советски».

Попробовали конвертировать c помощью той же «Белки» в шрифт, пригодный для веба. Но Myriad Pro — шрифт коммерческий. Под разными браузерами получалось не айс.

Вот так отображается шрифт под разными браузерами:
А в ТЗ четко написано о том, что сайт должен корректно отображаться подо всеми перечисленными.

Владимир Завертайлов
CEO&Founder
— Еще на заре сайтостроительства был вариант с flash (делать специальную чистую flash-ку, в которую импортировался шрифт). Работало только на заголовках. А вот ситуация, когда утвердили макет с одним шрифтом, а потом технологически его нельзя поменять — крайне неприятная. Даже если есть платный купленный шрифт на руках. Может начаться стандартное нытье «ну вы же профессионалы, должны были предусмотреть заранее, так что теперь делайте, как хотите и неебет». Насколько я знаю, конфликт между дизайнерским решением и техническими возможностями по реализации — это вообще не из веба пришло. В любой промышленности то же самое. Хоть в автомобильной (дизайнерские финтифлюшки приходится отрывать ради аэродинамики), хоть в производстве iPhone. Обычно заканчивается тем, что ищется альтернативный вариант, который всех устраивает, или даже вариант лучший, чем тот, что предлагали изначально. На это может уйти масса незапланированного времени и свести прибыль студии с проекта к убыткам. Риски — не прогнозируемы. Отчасти поэтому студии тиражируют какое-то обкатанное решение. Пожалуй, одной из менеджерских находок, которой мы научились, работая с нестандартными шрифтами — это сослаться на авторитетный источник, в котором описано, что проблему в общем случае решить не получится. Это действует на адекватных клиентов, позволяет настроить на поиск и выбор из альтернативных вариантов, за что им спасибо.
В результате так и получилось: сменили Myriad Pro на альтернативный шрифт (в верхнем меню это PT Sans Bold):
Как вывод: современные веб-технологии, конечно, стремятся к тому, чтобы избавить разработчиков от разного рода ограничений. Возможно, когда-то даже самые смелые идеи и дизайнерские решения можно будет с легкостью воплощать в готовом продукте. Но пока на достойную реализацию таких «смелых идей» уходит довольно много времени и сил верстальщиков. Неоправданно много.

Избавьте себя и разработчиков от дополнительных заморочек, используйте безопасные и конвертируемые шрифты.