Дробный кегль рукописного шрифта: как проверить промежуточные размеры

Рукописный шрифт в адаптивном макете часто получает не только целые 12 или 16 px: CSS может вычислить промежуточное значение, например 15,6 px. Проверка лишь на нескольких круглых размерах не показывает, как между ними меняются просветы, соединения и ритм. Сверьте фактические размеры из макета, сравните их на одинаковом тексте и фиксируйте конкретный повторяемый дефект.

Когда размер задают гибкой формулой, он меняется вместе с шириной окна. Например, clamp() выбирает значение между нижней и верхней границей, а предпочтительную часть можно рассчитать через ширину viewport. На одном экране заголовок может получить 15,6 CSS px, на другом — 17,1. Если проверить шрифт только на ближайших целых кеглях, изменения формы между контрольными точками останутся незамеченными.

Само дробное значение не означает дефект шрифта и не гарантирует видимую проблему. Векторный контур масштабируется, после чего браузер растеризует его для текущих условий вывода. На вид влияют форма конкретной буквы, масштаб, плотность пикселей, сглаживание и соседние символы. Поэтому нельзя заранее объявить, что «15,5 px всегда хуже 16 px»: нужно проверить реальные места, где текст используется.

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

Если размер задаётся статически, запишите значение из правила стиля. Если оно адаптивное, проверьте макет в браузере и посмотрите применённый font-size в инструментах разработчика. Важно записывать результат для тех ширин контейнера, на которых действительно появляется текст, а не только для произвольных ширин окна.

Например, у карточки товара название может плавно расти от минимального размера на узком экране до максимального на широком. Проверьте ширину телефона, промежуточную ширину планшета, узкое окно настольного браузера и точку, где формула достигает верхнего ограничения. Если используете clamp(), отдельно отметьте обе границы и хотя бы одну точку внутри диапазона. Это покажет и поведение на краях, и переход между ними.

Один из вариантов адаптивного правила:

При ширине viewport 480 px предпочтительная часть равна 15,6 px: 13,2 + 0,5 × 4,8. Фактическое применённое значение зависит от всех ограничений правила и контекста страницы. Числа в примере служат для расчёта тестовых точек, а не как рекомендация минимального или оптимального размера.

clamp() описывает минимум, предпочтительное значение и максимум; подробности синтаксиса и примеры есть в документации MDN: https://developer.mozilla.org/en-US/docs/Web/CSS/Reference/Values/clamp. Значение font-size может быть задано разными единицами и зависеть от родительского текста, поэтому фиксируйте именно применённый результат вместе с шириной viewport и условиями просмотра.

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

Порядок работы такой:

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

Сравнивайте не только один и тот же текст на разных размерах, но и реальные варианты контента. Длинное название может переноситься в строку иначе, чем короткое; в заголовке с цифрой или тире визуальный вес меняется. Если контент может быть пользовательским, добавьте самый длинный правдоподобный пример и строку с плотными сочетаниями букв.

Представим, что рукописный шрифт используется только для названий небольших изделий. На ширине 360 px формула выдаёт 14,8 px, на 480 px — 15,6 px, а на 768 px уже достигает ограничения 20 px. Не надо ограничиваться сравнением 14,8 и 20: наибольший риск может возникнуть около середины, когда ещё меняется ширина букв, а карточка уже становится длиннее.

Возьмите название «Щёлковый чехол № 28» и сравните его при трёх ширинах карточки. Сначала смотрите, не сливаются ли «щ» и «ё», остаётся ли виден кружок над «ё», не похож ли знак номера на случайную отметку. Затем проверьте перенос: если средний вариант распадается на две строки, не оставляет ли он короткую частицу в конце строки и не сталкивается ли с ценой. Наконец, проверьте тот же компонент с длинным названием, например «Чехол ручной работы из плотной хлопковой ткани».

Если проблема появляется только при 15,6 px, не исправляйте автоматически размер на всей шкале. Сначала проверьте, не меняется ли одновременно ширина карточки, начертание, межбуквенный интервал или системный масштаб страницы. После этого решите, какой уровень чинить: контент и перенос, CSS-правило конкретного компонента или контур отдельной буквы. Так вы не замаскируете дефект случайным увеличением текста.

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

Не путайте CSS-пиксели с физическими пикселями дисплея. window.devicePixelRatio отражает отношение физических пикселей к CSS-пикселям и может меняться из-за характеристик экрана и масштаба браузера. Это влияет на растеризацию, но само по себе не определяет читабельность. Если заметили разницу между устройствами, запишите не только font-size, но и устройство, браузер, масштаб страницы и плотность пикселей. Справка MDN: https://developer.mozilla.org/en-US/docs/Web/API/Window/devicePixelRatio.

Различайте изменение размера текста и увеличение всей страницы. Проверьте компонент в обычном масштабе, с пользовательским увеличением браузера и при увеличении текста средствами интерфейса, если такие настройки поддерживаются. Это отдельные сценарии доступности и поведения макета. Для гибкого CSS-размера важно также не блокировать пользовательское увеличение: рекомендации по проверке текста при масштабировании приведены в WCAG 1.4.4: https://www.w3.org/WAI/WCAG22/Understanding/resize-text.html.

Скриншот удобен для попарного сравнения, но он не полностью заменяет просмотр на целевом устройстве. Снимок может быть уменьшен редактором, показан в другом масштабе или пережат мессенджером. Для решения о тонких штрихах смотрите оригинал в масштабе 100% и реальный макет на устройстве; сравнение скриншотов используйте как журнал наблюдений.

Удобно описывать проблему через наблюдаемое место и диапазон: «в 15,6 px соединение “л” и “и” теряет светлый зазор, а в 16,2 px зазор виден» — полезнее, чем «шрифт мелкий». Такая запись позволяет повторить тест и понять, где возникает переход. Дополните её шириной viewport и настройками отображения.

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

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

Перед выпуском компонента пройдите короткую проверку:

Проверять только круглые целые значения. Реальный адаптивный макет может выдавать дробный результат. Добавьте фактически применяемые значения, а не только 14, 16 и 20 px.

Принимать каждое различие в пикселях за дефект контура. Оттенок сглаживания на экране может отличаться без реального ухудшения чтения. Ищите повторяемый дефект формы или ритма в контексте.

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

Делать вывод по одному слову. Необычное сочетание может быть единственной причиной тёмного узла. Сверьте несколько контрольных фраз и реальные названия.

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

Считать снимок экрана окончательным доказательством. Он помогает сравнить версии, но масштаб показа и обработка могут исказить впечатление. Для финального решения вернитесь к оригинальному макету и устройству.

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

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

Да. Создайте временные варианты компонента с нужными значениями размера и одинаковым текстом, затем сравните их рядом. После визуальной пробы проверьте реальные ширины контейнера и соседние элементы в рабочем макете, потому что искусственный образец не показывает переносы и контекст.

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

Устройства отличаются плотностью физических пикселей, а браузер может использовать другой масштаб и сглаживание. Сначала сравните применённый CSS-размер и условия просмотра. Затем смотрите, влияет ли разница на узнавание слов, просветы и ритм, а не только на оттенок краёв штриха.

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

Дробный кегль — не особый класс ошибок, а значение, которое легко пропустить, если проверять шрифт только по круглым контрольным точкам. Зафиксируйте фактические размеры макета, сравните их на одном и том же тексте и связывайте правку с конкретным повторяемым дефектом. Если создаёте собственный рукописный шрифт, соберите контрольные слова и проверьте результат в Fontgenerator, а затем вернитесь к тем же точкам в рабочем интерфейсе.