Pull to refresh

Comments 59

Таки если указывать высоту, то как потом масштабировать?
Мне например очень нравится виндовая настройка, позволяющая отображать в 125%.
Умножением. Масштабирование остается
Ну так, судя по началу статьи — виндовс это делает, а мак — нет.
масштабирование работает в обоих ОС
Хм, тогда поведение мак выглядит ещё сложнее. Спасибо за пояснения =)

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


Современные системы умеют и в метрическую систему тоже.


А еще, размер шрифта в браузере по умолчанию привязан к размеру шрифта ОС. Который в свою очередь также настраивается (например, режим 125% в виндоус).


В общем, тема запутанная, а статья запутывает еще больше.

Разве режим 125% не ppi меняет? Вместо 96 становится 120.

Хм… а вы чертовски правы!

Поэтому веб уже лет 5-10 как переехал на ремы — 1 rem это высота стандартного шрифта в ОС. Соответственно, все расстояния, размеры и отступы задаются в этих единицах.
А сверху какой-нибудь нормалайз с вечными body { font-size: 16px;}
… причем это какой-то говноплагин для не пойми чего, приехавший непонятно с чем, но который тащит с собой свой скомпиленный бутстрап 3. Ну, чтобы не скучно было.
О, может вы мне объясните? В чем прикол писать именно 1rem, а не 16px? Вот я читаю, пишут, что rem во всех браузерах 1rem=16px. Один фиг 16px это 16 логических пикселей, а не физических. Если хочешь покрупнее, то можно зум аж в двух местах подкрутить: в ОС и в браузере. Зачем rem-ы?
Нет, rem это не 16px, rem это 1em элемента :root, т.е. <html>
Затем вы, собственно, можете менять это по каким-то условиям CSSом или жабаскриптом (тупо влепив style=«font-size: 20px» на тег html). То, что у вас было в ремах — увеличится/уменьшится, а то, что в пикселях (например, толщина рамок и подчёркивания 1px, расстояния между колонками 30px и т.д.) — останется в пикселях.
И в чем профит? Если мне где-то нужно 20px, в чем профит писать 1.25rem вместо 16px?
Ну профит в том, что вы меняете одно значение в одном месте. И всё, что завязано на размер шрифта — сразу автоматом меняется. А что не завязано — не меняется.
Рамка толщиной 1px должна оставаться рамкой толщиной 1px. независимо от размера шрифта, независимо от того, гейфон это или нищеоми (а шрифты там очень разные, и поддержку css на гейфонах делали чужие для хищников)
Такой себе профит. Очень редко когда что-то где-то не плывёт. Даже если вёрстка была пуленепробиваемой, то кнопки с 1px рамкой и шрифтов после всех преобразований предположим в 50 физических пикселей будет смотреться просто неказисто. В Windows например шрифты в старых приложениях увеличиваются только до 125%, а дальше проще оказалось растягивать готовый растр, нежели чем фиксить баги в расползавшихся приложениях. А веб это сотня миллионов таких приложений, написанных непонятно как.
И как вам там живётся, в 2007?
Ну т.е. эпл ещё пытается там по-мелочи гадить, но в целом всё давно работает.
Где и как работает? 99% сайтов не приспособлены к изменению размера базового шрифта, браузеры давно плюнули на попытку это пофиксить и увеличивают всё целиком.
Вот кстати с HiDPI прикольно. Я только что проверил, в FF рамка 1px остаётся 1, 2 превращается в 3, 3 в 4. Угадайте мой коэффициент масштабирования?
Ответ
150%, тут налицо явное умножение на 1,5 и взятие целого.

И я более чем уверен, что на мобильных нет нигде рамок в 1px.
Ну а приложения до сих пор мылятся, даже активно развиваемые.
скажем так, фиктивный пиксель (логический пиксель, device-independent pixel) единица гораздо более удобная, чем поинты. Которые на словах вроде как физическая единица, а на деле тоже в пикселях задаются. А удобнее потому, что все остальные размеры (картинок, экрана) в тех же самых логических пикселях, а не в поинтах или ремах.
В общем, тема запутанная, а статья запутывает еще больше.

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

Просто нужно разработчикам операционных систем перестать страдать фигней и использовать PPI монитора. То, что есть сейчас, со всеми этими 72/96 PPI, какие-то лютые кривые костыли.
Разработчики ОС может и хотели бы.
Только вот прикладной софт развалится. Что там далеко ходить, даже дисплеи высокой четкости весьма паршиво поддерживаются под той же виндой — именно из-за этого. Тот же винамп на таком мониторе это боль.
Особенно обидно за «отдизайненный» софт, где люди действительно сидели и равняли конкретный шрифт попиксельно.
Это же обычный вопрос сохранения обратной совместимости при внесении изменений. В один момент Microsoft ввели возможность установить DPI awareness для процесса. Почему бы при рассчете размера шрифта, заданного в пунктах, не начать учитывать DPI экрана в DPI aware приложениях?
Ну в этом немного смысла, потому что 4mm надпись на 30 см от экрана и на 100 см это две большие разницы. Плюс зрение у всех разное.

Скорее нужно учитывать вручную выставленный масштаб ОС. Но это уже есть и я не предлагаю от этого отказываться, конечно
Автор оригинала как-то упустил из рассмотрения бóльшую часть мира. В случае Й, Ё, Ї, Ä, Ö, Ü, Û, Ç, Ñ и прочих — как тут быть?
Выносные элементы потому и называются выносными, что на _восприятие_ границ текстового блока не влияют. Про это упоминается мельком.
Так выносные элементы — это не диактритика. При его решении может выйти, что выносной элемент из строки выше сольется с диакритикой нижнего ряда.
Может. Но это и сейчас может случиться. Ставишь line-height с запасом и вперед. Тут как раз нет проблемы, потому что нет такой задачи «выделить на строку ровно столько места сколько нужно чтобы диакритика не пересеклась с нижними выносными элементами и ни пикселем больше».
Но это и сейчас может случиться. Ставишь line-height с запасом и вперед.

Т.е. нужно оперировать двумя параметрами, чтобы определить высоту, точнее, ее никак не определить, так как нужно просто расстояние держать в голове. Существующая система предусматривает это при размерах шрифтов (картинка с typolexikon.de):
image
Сверху вниз:
  • Á-линия (ударение)
  • k-линия (верхний край нижнего регистра в Renaissance antiquas)
  • H-Linie (высота верхнего регистра)
  • x-Linie (высота нижнего регистра)
  • Grundlinie (базовая линия, линия шрифта)
  • p-Linie (длина вниз)

Выходит, что улучшение работает исключительно для пары языков просто, а в остальных случаях уже нужно задумываться.
Не очень понимаю, что вы имеете в виду под «существующая система предусматривает». Да, типографы оперируют этими терминами на словах, но вы откройте любой шрифтовой файл и посмотрите, какие из них на самом деле попадают в шрифт (спойлер: cap-height, x-height, baseline. Еще ascender/descender, но они определяют body height, как я и писал, достаточно условную величину, а не k-line/p-line).
Не очень понимаю, что вы имеете в виду под «существующая система предусматривает». Да, типографы оперируют этими терминами на словах, но вы откройте любой шрифтовой файл и посмотрите, какие из них на самом деле попадают в шрифт (спойлер: 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 века в Германии ввели единый размер кегля, в который нужно было поместить символ со всеми дополнительными элементами. Там были компромиссы, но решение было сразу для всех европейских языков. В целом это не новая проблема, типографы ищут разные решения, вроде совместимых шрифтов или просто разные шрифты для красоты в одном абзаце используя.
Я уверен, что разрешение 72 ppi (или dpi) закрепилось не потому, что оно было у каких-то первых мониторов, а потому, что это удобная логичная связка между пикселями и дюймами при выводе на принтер. В одном дюйме 72 пункта. Соответственно если изображение имеет разрешение 72 ppi, при выводе на печать 1 пиксель будет равен 1 пункту.

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

96 ppi — это такая же привязка пикселей к пунктам, но из более реалистичного (и менее красивого) расчёта. Какие-то мониторы в каких-то режимах могли иметь разрешения близкие к 96 ppt, но опять же, тут главное было — предсказуемый размер растровых изображений при распечатке на принтере, а не при отображении на мониторе (т.к. мониторы бывают разные, и даже один и тот же монитор может работать в разных режимах).

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

Что касается «мерять размеры шрифтов по высоте прописных букв» — идея мне кажется странной. В разных шрифтах разное соотношение высоты прописных и строчных букв. А т.к. большая часть читаемого текста состоит из строчных букв, то размеры прописных букв как раз не так важны. Главное — какой размер у строчных букв. Соответственно, если уж пытаться унифицировать размеры, то более перспективно мерять высоты строчных букв. Наверное единственный пример, где оказался важным именно размер прописных букв — это надпись на кнопке «ОК».
SVGA 800 x 600 on 14-inch monitors = 72 dpi ¯\_(ツ)_/¯

Про строчные vs прописные есть такой спор, да, и, кажется, правды там не доискаться. twitter.com/romanshamin/status/1376880720199741447

Как вариант, задавать высоту строчных, а центрировать по прописным
Это ещё про ф и Ф не упомянули. Строковая ф больше по высоте прописной Ф

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


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


И вот тут-то всё и ломается, размеры картинок в rem пересчитывать что-то никто не рвётся.


Но в целом все в своё время как-то пришли к тому, что для точного отображения дизайна с графикой есть PDF, а HTML/CSS отображают всё примерно. Поэтому может и не стоит "лечить веб", делая из него довольно неудобный PDF?


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


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



Если к этому добавить, что метрики при создании шрифтов творческие люди прописывают по-разному, а у устройств есть физические DPI и логические PPI, то всё становится слишком сложно для достаточно редкой задачи — менять шрифты документа "на лету", сохраняя физическую высоту символов. А для точного отображения есть PDF.

Обычно все-таки знаешь, какой шрифт у тебя будет. А вот то, что не знаешь, какой высоты будут в нем буквы, неудобно.

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

Высоты букв относительно чего? Относительно картинок в этом тексте? Относительно физических размеров экрана пользователя?


Или абсолютный размер, в миллиметрах, постоянный вне зависимости от размеров экрана и плотности точек?


P.S. Частично работающие решения создают потом дикую головную боль для всех остальных. Вот как с размером литеры ))

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

У меня рядом два монитора, один 30", другой 15" у ноута.


Вопрос: шрифт высотой 30 у.е. должен отображаться одинаково, скажем, 30 мм?

не очень понял вопрос. Что за у.е., кому должен?

Простите, я, видимо, перепрыгнул через мысль.


Вы хотите указывать высоту шрифта в пикселях? То есть все тексты будут то крупными, то мелкими на разных мониторах, иногда просто нечитаемыми и придётся их зумить? Что, собственно, и делает PDF таким неудобным форматом...

Как настроите так и будет, в ОС зум есть (еще со времен Windows 95!), и в браузере есть. Можете даже сделать, чтобы буквы на ноутбуке были крупнее, чем на мониторе

Там проблема не только в картинках, а в любых визуальных элементах. С rem так или иначе получаются дробные метрики, которые плохо ведут себя на мониторах с низкой DPI и могут оставлять артефакты на месте стыковок элементов по причине различий в округлении по целочисленным пикселям. Чтобы понаблюдать, попробуйте в настройках Windows задать scale 125%. Тогда как размер в пикселях как правило имеет всегда целочисленный scale factor.

Ура! Давайте создадим ещё один новый стандарт!image
Никакого нового стандарта есть, cap height уже давным-давно указывается во всех шрифтах

Проблема в том, что любая привязка к физическим единицам измерения длины практически никак не соотносится визуальным уголом обзора в современных устройствах. Восприятие "мелкого" или "крупного" текста — это именно угол, который занимает символ в поле визуального обзора глаза. И этот угол зависит от физического размера символа и расстояния до глаза человека. Все 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", стоящей в двух метрах, и на экране проектора в зале заседаний.

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

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

Only those users with full accounts are able to leave comments. Log in, please.