Комментарии 59
Мне например очень нравится виндовая настройка, позволяющая отображать в 125%.
Статья хорошая в ресерче, однако вредная в выводах.
Еще хуже то, что автор оперируя пикселями на самом деле оперирует такими же фиктивными единицами измерения, как и остальные пункты.
Современные системы умеют и в метрическую систему тоже.
А еще, размер шрифта в браузере по умолчанию привязан к размеру шрифта ОС. Который в свою очередь также настраивается (например, режим 125% в виндоус).
В общем, тема запутанная, а статья запутывает еще больше.
Разве режим 125% не ppi меняет? Вместо 96 становится 120.
Затем вы, собственно, можете менять это по каким-то условиям CSSом или жабаскриптом (тупо влепив style=«font-size: 20px» на тег html). То, что у вас было в ремах — увеличится/уменьшится, а то, что в пикселях (например, толщина рамок и подчёркивания 1px, расстояния между колонками 30px и т.д.) — останется в пикселях.
Рамка толщиной 1px должна оставаться рамкой толщиной 1px. независимо от размера шрифта, независимо от того, гейфон это или нищеоми (а шрифты там очень разные, и поддержку css на гейфонах делали чужие для хищников)
В общем, тема запутанная, а статья запутывает еще больше.
Ни капли не запутывает, а раскрывает проблему разных размеров шрифтов на устройствах. Решение в пикселях более подходит для одинаковых по параметрам устройств отображения, но и для веба тоже актуально.
Только вот прикладной софт развалится. Что там далеко ходить, даже дисплеи высокой четкости весьма паршиво поддерживаются под той же виндой — именно из-за этого. Тот же винамп на таком мониторе это боль.
Особенно обидно за «отдизайненный» софт, где люди действительно сидели и равняли конкретный шрифт попиксельно.
Скорее нужно учитывать вручную выставленный масштаб ОС. Но это уже есть и я не предлагаю от этого отказываться, конечно
Но это и сейчас может случиться. Ставишь line-height с запасом и вперед.
Т.е. нужно оперировать двумя параметрами, чтобы определить высоту, точнее, ее никак не определить, так как нужно просто расстояние держать в голове. Существующая система предусматривает это при размерах шрифтов (картинка с typolexikon.de):
Сверху вниз:
- Á-линия (ударение)
- k-линия (верхний край нижнего регистра в Renaissance antiquas)
- H-Linie (высота верхнего регистра)
- x-Linie (высота нижнего регистра)
- Grundlinie (базовая линия, линия шрифта)
- p-Linie (длина вниз)
Выходит, что улучшение работает исключительно для пары языков просто, а в остальных случаях уже нужно задумываться.
Не очень понимаю, что вы имеете в виду под «существующая система предусматривает». Да, типографы оперируют этими терминами на словах, но вы откройте любой шрифтовой файл и посмотрите, какие из них на самом деле попадают в шрифт (спойлер: cap-height, x-height, baseline. Еще ascender/descender, но они определяют body height, как я и писал, достаточно условную величину, а не k-line/p-line).
Место учитывается, которое оставить нужно. Когда шрифт определяется высотой большой буквы, то при применении какого-нибудь умляута, вроде Ü в слове Übersichtsschema может попортить довольно компактный фрагмент текста. В общем преимуществ я там не вижу. Вы попробуйте в Автокаде пописать, там именно такой подход — размер шрифта определяется высотой большой буквы.
Ну ставишь line-height: 1.2 и вперед, не? Мало? 1.4 тогда. Я же не предлагаю буквы вплотную на минимально возможное расстояние ставить. Да и никто не предлагает. Даже с сегодняшним подходом к определению метрик обычно еще нормально так leading добавляют.
Просто место, оставленное под буквы, которых сейчас нет, но которые _теоретически_ возможны, визуально странно выглядит
Ну ставишь line-height: 1.2 и вперед, не? Мало? 1.4 тогда. Я же не предлагаю буквы вплотную на минимально возможное расстояние ставить. Да и никто не предлагает. Даже с сегодняшним подходом к определению метрик обычно еще нормально так leading добавляют.
Мы так приходим к текущей ситуации.
Просто место, оставленное под буквы, которых сейчас нет, но которые _теоретически_ возможны, визуально странно выглядит
Так это то же самое «ставишь line-height: 1.2 и вперед, не? Мало? 1.4 тогда». Так гарантируется, что текст займет на чертеже четкий объем даже при его дальнейших изменениях.
А еще всяческие восточноазиатские языки.
Теперь добавьте сюда вьетнамский — где порой диакритика в три уровня. За ним CJK-языки, которым надо чтобы и квадратики иероглифов читались, и встроенная туда латиница тоже. Потом заполируйте это эмоджи, которые хотелось бы вставлять в текст так, чтобы строки не разъезжались. И это мы ещё не касаемся арабской вязи или там деванагари, где высота символов очень скачет, и вообще нет заглавных. Чтобы было не скучно, можно ещё вспомнить, что монгольская письменность вообще вертикальная.
Автор хочет контроля над расстоянием между базовыми линиями — чтобы разные шрифты оставались на одних и тех же строках — и x-высотой шрифта для латиницы — чтобы разные шрифты в одной или соседних строках были похожи — но веб такого не очень умеет. Что, впрочем, не отменяет тезиса о бесполезности font-size — который фактически «какой-то размер». Если его сделать больше, что буквы станут больше — но как метрика этот параметр бессмысленнен.
Пост не о том, как измерять — а о том, что измерять.
Что, впрочем, не отменяет тезиса о бесполезности font-size — который фактически «какой-то размер». Если его сделать больше, что буквы станут больше — но как метрика этот параметр бессмысленнен.
Размер большой буквы тоже очень ограничено полезен. Это будет еще один стандарт. ЕМНИП в начале 20 века в Германии ввели единый размер кегля, в который нужно было поместить символ со всеми дополнительными элементами. Там были компромиссы, но решение было сразу для всех европейских языков. В целом это не новая проблема, типографы ищут разные решения, вроде совместимых шрифтов или просто разные шрифты для красоты в одном абзаце используя.
Может производители первых маков действительно пытались сделать мониторы с таким разрешением (Джобс же изучал графический дизайн в колледже, такие простые красивые идеи могли греть ему душу), но технически это было не очень правильно. Однопунктовые пиксели — это слишком грубо даже для первых графических мониторов.
96 ppi — это такая же привязка пикселей к пунктам, но из более реалистичного (и менее красивого) расчёта. Какие-то мониторы в каких-то режимах могли иметь разрешения близкие к 96 ppt, но опять же, тут главное было — предсказуемый размер растровых изображений при распечатке на принтере, а не при отображении на мониторе (т.к. мониторы бывают разные, и даже один и тот же монитор может работать в разных режимах).
Не забываем, что до недавнего по геологическим меркам времени в области графики компьютеры воспринимались как временное промежуточное хранилище. Все изображения (да и тексты) подразумевались быть распечатанными на бумаге и употреблёнными в печатном виде. Обычай читать что-то с экрана, или рассматривать что-то на экране и ничего не печатать — это относительно новый обычай.
Что касается «мерять размеры шрифтов по высоте прописных букв» — идея мне кажется странной. В разных шрифтах разное соотношение высоты прописных и строчных букв. А т.к. большая часть читаемого текста состоит из строчных букв, то размеры прописных букв как раз не так важны. Главное — какой размер у строчных букв. Соответственно, если уж пытаться унифицировать размеры, то более перспективно мерять высоты строчных букв. Наверное единственный пример, где оказался важным именно размер прописных букв — это надпись на кнопке «ОК».
Про строчные vs прописные есть такой спор, да, и, кажется, правды там не доискаться. twitter.com/romanshamin/status/1376880720199741447
Как вариант, задавать высоту строчных, а центрировать по прописным
А какая, собственно, разница для дизайнера, какого физического размера будут буквы? Важны пропорции между разными стилями текста. Поэтому имеет смысл задавать всё в условных единицах, то есть rem.
Но тут в дело вступают картинки, поверх которых и рядом с которыми расположен текст в современном мире. Шрифты векторные, их мы легко масштабируем, а вот картинки дискретные, растровые, и их размеры приходится всё же задавать в пикселях.
И вот тут-то всё и ломается, размеры картинок в rem пересчитывать что-то никто не рвётся.
Но в целом все в своё время как-то пришли к тому, что для точного отображения дизайна с графикой есть PDF, а HTML/CSS отображают всё примерно. Поэтому может и не стоит "лечить веб", делая из него довольно неудобный PDF?
И ещё. Автор как-то не учёл что у рукописных шрифтов, например, вообще высоту померить сложно, да и у обычных рубленых шрифтов разница между размером прописных и строчных букв может быть очень существенной, то есть задавая размер шрифта мы в любом случае не задаём размер именно глифов, это невозможно.
То есть размер шрифта всё равно будет некоторой условностью, которая для другого шрифта означает совсем другое. И высота строки тоже.
Если к этому добавить, что метрики при создании шрифтов творческие люди прописывают по-разному, а у устройств есть физические DPI и логические PPI, то всё становится слишком сложно для достаточно редкой задачи — менять шрифты документа "на лету", сохраняя физическую высоту символов. А для точного отображения есть PDF.
Мое решение не универсально, но уметь задавать осмысленный размер хотя бы для части шрифтов (значительной, кстати) строго лучше, чем не уметь ни для каких.
Высоты букв относительно чего? Относительно картинок в этом тексте? Относительно физических размеров экрана пользователя?
Или абсолютный размер, в миллиметрах, постоянный вне зависимости от размеров экрана и плотности точек?
P.S. Частично работающие решения создают потом дикую головную боль для всех остальных. Вот как с размером литеры ))
У меня рядом два монитора, один 30", другой 15" у ноута.
Вопрос: шрифт высотой 30 у.е. должен отображаться одинаково, скажем, 30 мм?
Там проблема не только в картинках, а в любых визуальных элементах. С rem так или иначе получаются дробные метрики, которые плохо ведут себя на мониторах с низкой DPI и могут оставлять артефакты на месте стыковок элементов по причине различий в округлении по целочисленным пикселям. Чтобы понаблюдать, попробуйте в настройках Windows задать scale 125%. Тогда как размер в пикселях как правило имеет всегда целочисленный scale factor.
Проблема в том, что любая привязка к физическим единицам измерения длины практически никак не соотносится визуальным уголом обзора в современных устройствах. Восприятие "мелкого" или "крупного" текста — это именно угол, который занимает символ в поле визуального обзора глаза. И этот угол зависит от физического размера символа и расстояния до глаза человека. Все DPI в полиграфии рассчитывались из соображения, что текст читается на расстоянии порядка 25см, что более менее соответствует и мониторам (хотя как правило монитор стоит дальше, чем экран ноутбука), но не мобильным устройстам. Поэтому правильнее было бы ввести угловую единицу обзора, в которой бы указывался размер экрана устройства и все метрики отображаемых элементов, а разрешающая способность измерялась бы в точках на единицу угла, а не на дюйм.
Как будем решать проблему с тем что может быть более одного экрана. Разного размера.
Берем примером Z Fold2 — это и телефон с дисплеем 6.23" и планшет с дисплеем 7.6" и (как на всех топовых самсунгах) — поддерживается режим DeX где картинка на внешний монитор (который и 24" может быть но находится на типичном мониторном расстоянии). При этом экран приложения может быть переброшен между этими состояниями.
Или берем Apple — iPad приложение может быть на iPad Mini с дисплеем 8" или на Pro с дисплеем под 12" или на макбуке/макмини с M1 (и дисплеем ноута или внешним).
Или любой ноут со внешним дисплеем.
Это точно мне коментарий? У меня ноутбук 14" с Windows и подключен к внешнему монитору 21". Разрешение у мониторов однинаковые (Full HD), однако, как несложно догадаться, разный DPI. Поэтому в настройках скейлинга для экрана ноута ставим 150%, а для внешнего 125%. В итоге буквы и все элементы приложений одинаковый размер на обоих мониторах. При перетаскивании окна с одного монитора на другой меняется метрика приложения, и оно адаптируется под новый scale. Решено на Windows, Маках, Linux/Wayland, и возможно еще куче девайсов.
Мой коментарий заключается в том, что у девайсов должна быть еще одна метрика — угловой размер, на основании которого графическая подсистема сама выбирает параметры скейлинга. В итоге один и тот же шрифт (и все визуальные элементы) имеет одинаковый визуальный размер и на мобильнике, и на ноуте, и на мониторе, и на плазме 52", стоящей в двух метрах, и на экране проектора в зале заседаний.
Ну хорошо, я указал в настройках редактора высоту заглавной буквы. Но так как соотношение высот заглавной и строчных букв в разных шрифтах разное, то теперь у меня при смене шрифта будет разный размер строчных. И какую проблемы мы решили?
А вот если размер шрифта это размер "очка" (типографический термин, извините), то как раз больше шансов, что разные шрифты в одном размере будут примерно одинаковы по разборчивости, потому что дизайнер разрабатывает шрифт исходя из размера "очка", а не заглавной буквы. Высота последней — это просто одна из метрик.
Font size бесполезен, давайте это исправим