Pull to refresh

Comments 9

обязательно обсудите этот момент с разработчиком

Золотые слова.

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

Странно что Фигма по умолчанию не включает эту штуку.

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

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

Отсюда: https://alzari.ru/shrifty.html

Потому что поддержка у этого свойства в css только с 25 года только в новейших браузерах.

Мне кажется в фигме всё же в большинстве своём сайты лепят, а не что-то лишь бы жизнь испортить

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

Потому что поддержка у этого свойства в css только с 25 года только в новейших браузерах.

А что мешает сделать микросервис, который на вход жрёт шрифт, а на выходе дает всю нужную инфу о его размерах и прочих ТТХ? В конце концов это можно сделать на бекенде с кешированием. В общем, может я опять перегибаю оверинжиниринг, но для меня подобные проблемы выглядят как‑то диковато.

В WPF для десктопа 2008 года всё это было из коробки. Там только рендеринг шрифтов в самом начале был размытый из‑за игонра хинтинга, но это быстро починили. Почему эти сверхтехнологии инопланетных цивилизаций дошли до веба в 2025 году, большая загадка. И это при том, что сейчас на WebKit делают буквально почти всё.

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

Ну имхо это уже организационная проблема, а не техническая. Работали бы нормально паддинги, что‑нибудь другое бы дизайнер забыл бы сделать.

Обычное поведение текста в практически любом графическом приложении

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

Поэтому подход с ручной правкой паддингов, на мой взгляд, все таки надёжней.

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

Не совсем понимаю, как это влияет на выравнивание текста?

Sign up to leave a comment.

Articles