Font size бесполезен, давайте это исправим

Автор оригинала: Nikita Prokopov
  • Перевод
Что происходит, когда вы указываете в редакторе "font_size": 32? Я бы вам всё равно рассказал, но хорошо, что спросили.

Попробуем догадаться. Я пользуюсь Sublime Text 4 под macOS:


Если мы измерим сами буквы, то нигде не найдём числа 32:

32 — это не ширина и не высота буквы, и не высота заглавной буквы, и не рост строчных знаков, и не высота верхних или нижних выносных элементов. Что за дела?



Пункты


Во-первых, это размер не в пикселях, а в пунктах. Пункт — физическая единица измерения, равная 1⁄72 дюйма (0,353 мм), она берёт начало из типографики.

Смысл здесь в том, чтобы задавать размер шрифта непосредственно в физических единицах, опуская такие мелочи, как разрешение экрана. Если я хочу, чтобы буквы имели высоту 2 дюйма, то я задаю размер шрифта в 144 pt.

На практике никто этого не делает. Вместо этого для преобразования пунктов в пиксели macOS всегда использует 72 PPI (points per inch, пункты на дюйм). Если вывести macOS на 32-дюймовый и на 24-дюймовый мониторы с одинаковым разрешением 1080p, то мы получим одинаковый размер в пикселях, а не физический размер, что разрушает весь смысл исходной идеи.


Почему число 72? Оказывается, в первых Mac использовались дисплеи с разрешением изображения ровно 72 PPI. Если просматривать на них текст, то его физический размер на экране совпадёт с физическим размером при печати. Удобно! Разумеется, с тех пор разрешение PPI дисплеев Mac повысилось, но традиция сохранилась.

В духе истинного сотрудничества, Windows использует не 72, а 96 PPI. Почему не 72? Не потому, что у компьютеров были дисплеи получше (это не так), а потому, что 72 давали слишком мало пикселей для рендеринга читаемого текста. Поэтому проектировщики решили: почему бы не сделать всё на ⅓ крупнее?

Так они и поступили. Этот стандарт сохраняется и по сей день: текст размером 16 pt в Windows на ⅓ крупнее, чем текст 16 pt в macOS. Весело!


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

P.S. Похоже, VS Code берёт значение editor.fontSize напрямую в пикселях. Отличное начало!

Квадрат Em


То есть пользователь, запрашивающий шрифт 32 pt, на самом деле требует 32 пикселя (px) в macOS и 43 px в Windows. Но эти числа всё равно нигде не встречаются.

Так происходит, потому что font-size задаёт так называемый размер «em».

В традиционной печати металлическими литерами размер em — это высота литеры символа (её кегль).

Почему высота называется «размером em»? Потому что так совпало, что буква «m» имеет квадратные размеры, а ширина «m» == высоте литеры символа == размеру em. Всё просто!


Источник изображения

Однако в цифровой типографике «квадрат em» — это (цитата из Википедии):

сетка произвольного разрешения, используемая как пространство для дизайна цифрового шрифта.

То есть если я открою свой шрифт Fira Code и начерчу em square, то он не будет вообще ничему соответствовать:


Если вкратце, этот квадрат и есть то чем вы управляете при задании размера шрифта. Если задать размер шрифта 32 pt, то этот квадрат будет иметь ширину/высоту 32/43 px. К сожалению, он невидим и ему не соответствует ни один элемент шрифта.

Проблема


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

Это означает, что если задать разным шрифтам одинаковый размер, то внешне их размер может значительно различаться. Например, если сопоставить em square (то есть задать одинаковый размер шрифта) двух разных шрифтов, то мы получим очень разную высоту «m»:


Ещё один пример. Все эти шрифты имеют одинаковый размер — 22 pt:


Я считаю, что размер шрифта обладает следующими проблемами:

  • Непредсказуемость: невозможно угадать, что ты получишь. 16 pt — это сколько пикселей?
  • Непрактичность: невозможно получить то, чего хочешь. Хочешь, чтобы буквы были высотой 13 пикселей? Не получится.
  • Нестабильность. Переключаемся на другой шрифт, оставляем тот же размер, получаем более крупные/мелкие буквы.
  • Зависимость от ОС. Получаем разный рендеринг при открытии документа на разных ОС. Нельзя использовать одинаковые конфигурации редактора в macOS и Windows.

Решение


  • Указывать высоту прописных букв, а не размер em square.
  • Указывать её в пикселях.

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


Вот несколько шрифтов, для которых задан одинаковый размер шрифта:


А вот те же шрифты, но с размерами, подогнанными под высоту прописных букв:


На мой взгляд, последний вариант обеспечивает гораздо большую целостность. Например, взгляните на Cascadia и Consolas. Или Hack и IBM Plex Mono. Или Ubuntu Mono и Victor Mono (два последних шрифта).

С высотой строки тоже есть неразбериха


Если уж мы начали говорить об этом, то почему бы не исправить и высоту строки? Не волнуйтесь, это будет быстро.

Во-первых, очевидно, что отсутствует консенсус. Каждый делает что-то своё:


Почему? Проблема высоты строки в том, что она вычисляется по тем же абстрактным границам символа:


Такой стандарт был логичен для металлических литер. В конце концов, нельзя сделать строку меньшей высоты, чем тело литеры:


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

Некоторые шрифты добавляют пространства, другие выделяют ровно столько, чтобы хватало на верхние и нижние выносные элементы:


Но даже второй вариант нас не устраивает! Верхние и нижние выносные элементы не влияют на размер воспринимаемого визуально текстового блока. Строго говоря, разумеется, минимальная высота строки должна без пересечений включать оба вида элементов, но с точки зрения эстетики этот выбор далеко не идеален.

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

Предсказуемая высота строки


Что же нам делать? Разумно было бы задавать высоту строки непосредственно в пикселях, игнорируя все метрики шрифтов. Или же как процент от высоты прописных букв, но совершенно точно не через font-size или «автоматическую» высоту строки!

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


Вместо него нужно использовать расстояние между базовыми линиями:


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

Подведём итог: вот что есть сейчас — при изменении шрифта мы получаем случайную высоту строки:


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


Кажется безумием, что имея все эти компьютеры, мы по-прежнему столь привязаны к особенностям, возникшим в «металлический» век шрифтов.

Эндшпиль


То, чего я пытаюсь достичь всеми этими предложениями, легко показать на одном примере:

  1. Я один раз задаю в своём редакторе нужные мне размер шрифта и высоту строки.
  2. Я могу попробовать разные шрифты.
  3. Мне не нужно перенастраивать размер шрифта и высоту строки каждый раз, когда я меняю шрифт.

Примерно так (высота прописных букв и высота строки в точности совпадают):


Интерфейс моей мечты:


Второй пример использования тоже довольно прост: мне нужен предсказуемый и надёжный способ центрирования текста на кнопке.

Это всегда было проблемой для веба, но недавно эту болезнь подхватила и macOS:


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

Ссылки


Getting to the bottom of line height in Figma. Приключения Figma в поисках компромисса между тем, что нужно людям и что делает веб.

Deep dive CSS: font metrics, line-height and vertical-align. Превосходная статья, демонстрирующая, как конкретно работает алгоритм высоты линии шрифтов и CSS. Кроме того, обратите внимание, что я не единственный человек с ужасным цветом фона на веб-сайте.

Capsize. JS-библиотека, позволяющая делать уже сегодня именно то, что я описал в этой статье, учитывая ограничения веба.

Leading-Trim: The Future of Digital Typesetting. О том, как leading-trim (то есть примерно то же, что и высота прописных букв) может упростить жизнь каждого.



На правах рекламы


VDS для размещения сайтов — это про наши эпичные! Все серверы «из коробки» защищены от DDoS-атак, скорость интернет-канала 500 Мегабит, автоматическая установка удобной панели управления VestaCP для размещения сайтов. Лучше один раз попробовать ;)

VDSina.ru
Серверы в Москве и Амстердаме

Комментарии 53

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

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


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


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


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

        +7

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

          0

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

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

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

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

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

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

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

                            Выходит, что улучшение работает исключительно для пары языков просто, а в остальных случаях уже нужно задумываться.
                              0
                              Не очень понимаю, что вы имеете в виду под «существующая система предусматривает». Да, типографы оперируют этими терминами на словах, но вы откройте любой шрифтовой файл и посмотрите, какие из них на самом деле попадают в шрифт (спойлер: cap-height, x-height, baseline. Еще ascender/descender, но они определяют body height, как я и писал, достаточно условную величину, а не k-line/p-line).
                        0

                        А еще всяческие восточноазиатские языки.

                          0
                          а что восточноазиатские языки?
                            0

                            Самое простое: китайские и японские иероглифы обычно выше заглавных латинских букв.

                              0
                              и...?
                                +5

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

                                  0
                                  То есть для них ситуация не изменится. В чем проблема? Что я не решил проблемы всего мира сразу? Ну извините
                          +3

                          Теперь добавьте сюда вьетнамский — где порой диакритика в три уровня. За ним CJK-языки, которым надо чтобы и квадратики иероглифов читались, и встроенная туда латиница тоже. Потом заполируйте это эмоджи, которые хотелось бы вставлять в текст так, чтобы строки не разъезжались. И это мы ещё не касаемся арабской вязи или там деванагари, где высота символов очень скачет, и вообще нет заглавных. Чтобы было не скучно, можно ещё вспомнить, что монгольская письменность вообще вертикальная.


                          Автор хочет контроля над расстоянием между базовыми линиями — чтобы разные шрифты оставались на одних и тех же строках — и x-высотой шрифта для латиницы — чтобы разные шрифты в одной или соседних строках были похожи — но веб такого не очень умеет. Что, впрочем, не отменяет тезиса о бесполезности font-size — который фактически «какой-то размер». Если его сделать больше, что буквы станут больше — но как метрика этот параметр бессмысленнен.


                          Пост не о том, как измерять — а о том, что измерять.

                            0
                            Что, впрочем, не отменяет тезиса о бесполезности font-size — который фактически «какой-то размер». Если его сделать больше, что буквы станут больше — но как метрика этот параметр бессмысленнен.

                            Размер большой буквы тоже очень ограничено полезен. Это будет еще один стандарт. ЕМНИП в начале 20 века в Германии ввели единый размер кегля, в который нужно было поместить символ со всеми дополнительными элементами. Там были компромиссы, но решение было сразу для всех европейских языков. В целом это не новая проблема, типографы ищут разные решения, вроде совместимых шрифтов или просто разные шрифты для красоты в одном абзаце используя.
                          +4
                          Я уверен, что разрешение 72 ppi (или dpi) закрепилось не потому, что оно было у каких-то первых мониторов, а потому, что это удобная логичная связка между пикселями и дюймами при выводе на принтер. В одном дюйме 72 пункта. Соответственно если изображение имеет разрешение 72 ppi, при выводе на печать 1 пиксель будет равен 1 пункту.

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

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

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

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

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

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

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


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


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


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


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


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



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

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

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

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


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


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

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

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


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

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

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


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

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

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

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

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

                                  Только полноправные пользователи могут оставлять комментарии. Войдите, пожалуйста.

                                  Самое читаемое