EM, REM или PX – почему нельзя использовать «только пиксели»


Содержание материала:

Fornit Some Fornus

Предисловие

Идея о том, чтобы сделать статью про размерности, используемые в веб-дизайне, появилась давно и на неё возлагалось несколько задач: во-первых, привести в порядок свои собственные мысли, во-вторых, иметь место, куда «вместо тысячи слов» можно легко сослаться, а в-третьих, по порядку, но не по важности, помочь коллегам и другим любопытствующим поставить некоторые свои точки над i.

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

DPI и PPI

Статье в Ководстве про разрешение картинок уже исполнилось 14 лет, но путаница присутствует до сих пор. Экранную графику наделяют печатными характеристиками качества и уповают на значение в 300 dpi, хотя ситуация выглядит простой и понятной, если придерживаться трёх правил.

Правило №1: Видеосистема ничего не знает о дюймах, сантиметрах и процентах, а оперирует только пикселями. Любой графический объект (картинка или текст) выводится на экран монитора последовательно, пиксель за пикселем. Картинке без разницы какое разрешение у нее в свойствах: 72, 96 или 300, она отображается на экране объектом с заданной в пикселях длиной и шириной. В качестве опыта нарисуйте в Фотошопе прямоугольник 150×100 пикселей, сохраните его в 3 -х JPEG-файлах с разными значениями dpi, а потом откройте в браузере — разницы вы не увидите. Значение dpi можно изменить как при сохранении файлов через редактор, так и вручную в просмотрщиках. Некоторые растровые графические файлы, например PNG (через «save as. ») или GIF, сохраняются вообще без указания dpi.

Браузер игнорирует выставленные в настройках JPEG значения dpi

Указанное в свойствах картинки разрешение dpi учитывается только при печати изображения. Причем, если печатать напрямую из браузера, а не через редактор, то графика будет напечатана с разрешением 96 dpi в Windows или 72 dpi в Mac, поскольку ради сохранения пропорций на отпечатанной странице, браузер переводит условные дюймы pp(i) шрифтов в dpi отпечатка, но об этом ниже.

Правило №2: Термины dpi и ppi служат разным целям и их не следует путать. У растровой картинки нет разрешения, а есть размеры в пикселях по длине и ширине или в (гига)мегапикселях площади. Разрешение или разрешающая способность применима только для устройств ввода-вывода. Её выражают в количестве различимых единиц на дюйм длины: для печатающих устройств — это точки-на-дюйм (dots-per-inches, dpi), а для экранов используется термин пиксели-на-дюйм (pixels-per-inches, ppi)

http://dpi.lv/
Здесь можно помериться своим ppi, хотя авторы сайта некорректно называют его dpi.

У ранних мониторов CGA и EGA пиксели имели прямоугольную форму (PAR, pixel aspect ratio — 1:1.2, 1:2.4), сегодня пиксели квадратные, ppi по горизонтали и по вертикали совпадают и для упрощения расчетов разрешение указывается на квадратный дюйм. Устоявшиеся словосочетания вроде «разрешение 800×600» (калька с английского resolution) некорректны, поскольку одинаковые размеры матрицы при разной диагонали экрана дают разный ppi (в случае с 800×600 — 125 ppi при 8 -и дюймовом, 71 ppi при 14 -ти дюймовом экране), правильнее называть их «режимами монитора» (display modes).

Величина ppi отражает плотность пикселей экрана

Чем выше значение ppi, тем меньше размеры экранного пикселя и тем меньше «пикселизация» изображения. Минимальной различимой единицей экрана считается dot pitch (зерно экрана) — расстояние между субпикселями одного цвета, или, по-другому, размер триады пикселей RGB. В вопросах погони за высокими значениями ppi полезно помнить о том, насколько объективно использование таких величин в контексте человеческого глаза.

Острота зрения измеряется в угловых минутах (1/60 градуса) и определяется в России при помощи таблицы Сивцева (самая популярная) или таблицы Головина. Штрихи букв в таблице Сивцева имеют одинаковую постоянную толщину, а очко литеры квадратной формы со стороной в 5 штрихов. Таким образом, достоверно различаемые штрихи букв на определенной строке таблицы отражают разрешающую способность глаза, указанную для данного кегля. Считается, что при нормальном зрении («единичка»), человеческий глаз способен различать расстояние между двумя точками в 1 угловую минуту (α = 1’). Весьма редко, но встречаются люди, зрительная возможность которых лежит в рамках 0.4 — 0.5 угловой минуты.

X = 2 × D × tg(α/2)
ppi = 25.4 мм / X
——————————
D X ppi
5000 мм (референс) 1.45 мм (толщина штриха) 17.5
2000 мм 0.58 мм 44
800 мм 0.232 мм 109
400 мм 0.116 мм 219
100 мм 0.029 мм 875

В офтальмологических кабинетах зрение проверяется на расстоянии в 5 метров, это референсный показатель для нормального зрения, при котором различаются штрихи букв десятой строки таблицы (V = 1,0). Для комфортного просмотра ТВ (значение D в 2 метра) достаточно LED или LCD панели с разрешением в 50 ppi, поэтому FullHD на диагонали 45-50 см выглядит весьма привлекательно и не требует улучшения. При работе за компьютером (расстояние от монитора около 80 см) экран с характеристиками свыше 120 ppi может пригодится лишь в случае профессиональных или специфических нужд.

С комфортным чтением печатной продукции на расстоянии в 30-40 см вполне управляется существующее полиграфическое качество в 300 dpi. Минимальное расстояние, на котором способен фокусироваться глаз взрослого человека — 10 см, в этом случае максимальная разрешающая способность человеческого глаза заканчивается на величине в 875 ppi, что по сути является пределом, но на таком расстоянии никто не читает и не пользуется телефонами.

Таким образом, отображение картинки зависит только от характеристик самого монитора, выражаемых значением ppi. Почему же Фотошоп все равно услужливо предлагает нам сохранить JPEG-файлы в разрешении 72 dpi для Web? Делает он это, помятуя о «преданиях старины глубокой».

9’’ монохром
512 × 342 пикселя
72 ppi

В списке достоинств Apple Mac образца 1984 года был широкий ассортимент гарнитур шрифтов, растеризированных с печатных глифов, что по сравнению с существовавшими тогда моноширинными знакоместами MS-DOS (80×25 штук) выглядело действительно круто. Это стало возможно благодаря механизму перевода типографских пунктов в пиксели экрана. Дюймов на экране монитора нет, это объект реального мира (на бумаге), на мониторе есть только пиксели. Чтобы перевести размерность типографских пунктов шрифтов из дюймов в экранные пиксели (технический термин процесса — ppem, pixels-per-em) был использован «условный дюйм», выраженный в количестве экранных пикселей, которые мы фиктивно представляем как 72 пункта или как один дюйм — pp(i).

Правило №3. Экранный ppi как мера пиксельной плотности и условный pp(i) как шкала перевода пунктов в пиксели не совпадают. Первоначальное значение условного дюйма в 72 pp(i) для ранних макинтошей было оправданным: размеры матрицы монитора делали его близким к физическому дюйму, а эппловский ImageWriter принтер имел ровно вдвое бо́льшую разрешающую способность в 144 dpi. Таким образом, 1 пиксель на экране составлял (примерно) один типографский пункт, 72 пикселя условного дюйма легко переводились в 1 дюйм физический на принтере, а текст, набранный 12-ю пикселями на экране Macintosh давал ци́церо при печати. Но при этом имелись недостатки:

  • 10 -и пунктовый шрифт стандартной офисной печатной машинки смотрелся плохо на экране в 10 -и пиксельном исполнении, особенно в кегле строчных букв (x-height, 5 пикселей);
  • Расстояние, необходимое для чтения с экрана на 33% больше расстояния для чтения с бумаги, что усугубляло некомфортное отображение шрифтов;

Товарищи из лагеря Windows пошли «другим путем», чтобы исправить недочеты конкурентов и приняли в качестве условного дюйма для своего программного обеспечения 96 пикселей, что на ту самую треть превышало pp(i) у Mac. На многие годы это решение внесло сумятицу в стан пользователей. С одной стороны пикселей на каждый пункт бралось больше и аналогичные шрифты на одном и том же мониторе выглядели в Windows крупнее, чем у Mac и улучшали читаемость. Но при этом уменьшилось количество доступных пикселей для графики и остальных объектов. Кроме того, было нарушено близкое к 1:1 соответствие экранного (пикселей на экране) и печатного (точек на бумаге) пунктов, что на корню сгубило WYSIWYG-идеологию (к которой, кстати, так больше и не вернулись).

Соотношение пикселей, пунктов и дюймов для шрифтов Mac и PC

72 и 96 сохранились на платформах в качестве параметров по умолчанию, поэтому картинки на странице отображаются своими реальными размерами в пикселях, а текст в зависимости от pp(i) системы, на которой мы работаем. На разных мониторах шрифты выглядят по-разному и эта разница становится все более и более существенной. И Microsoft и Apple предлагают собственные решения, чтобы улучшить отображение экранной графики и шрифтов.

Так, после появления видеоадаптеров IBM 8514 в Windows ввели дополнительный режим 120 pp(i), который был доступен при выборе опции «Large Font 125%» — при этом увеличиваются шрифты и UI-элементы интерфейса (иконки, кнопки, поля ввода). На современных системах pp(i) можно изменить в разделе «Персонализация»: четыре автоматических режима (100%, 125%, 150% и 200% — 96 pp(i), 120 pp(i), 144 pp(i) и 192 pp(i) соответственно) плюс можно использовать линейку для ручной настройки. При этом Microsoft отмечает, что работает со сторонними разработчиками и не гарантирует качество отображения в не-«dpi-aware» (термин спецификации) приложениях при изменении pp(i) в настройках системы.

Настройка pp(i) в Windows и соотношения пикселей картинки и экрана в OS X (источник)

Кроме того, страницы можно масштабировать непосредственно в браузере: фиктивно изменяем ppi экрана, либо pp(i) если выставлена опция «только для текста». При этом векторные изображения также масштабируются, а растр претерпевает бикубическую интерполяцию. Здесь вендорные характеристики браузера накладывают отпечаток на качество и соответствие масштабированной страницы и окон.

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

PHP, изменяющий цвета пикселей изображения, также изменяет соседние пиксели

Я работаю над проектом в PHP, где я манипулирую пикселями изображения. Я могу сделать это хорошо, однако я не пытаюсь изменить каждый пиксель. Я только собираюсь изменить примерно половину пикселей, и только немного (+ — 10 или меньше красного цвета в цвете RGB). У меня проблема в том, что после того, как изображение было обработано и экспортировано в файл .jpg, я заметил, что изменения цвета смешиваются вместе. То есть, когда я меняю цвет пикселя, он также слегка меняет цвет соседних пикселей.

Это не поведение, которое я хочу, так как половина пикселей не должна видеть какого-либо изменения цвета. Есть ли способ обойти это?

Я манипулирую изображениями в формате JPEG.

Я использую imagecolorallocate () и imagesetpixel (), чтобы изменить каждый отдельный пиксель на соответствующее количество. Я замечаю, что если я проверю каждый пиксель ресурса изображения ДО экспорта изображения в файл, все будет именно так, как и должно быть. Только пиксели, которые я собираюсь изменить, имеют значение, отличное от предыдущего, и «смешивание» пикселей отсутствует.

Однако после того, как я вызову imagejpeg () для измененного ресурса изображения, происходит «смешивание» цветов. Это то, чего я очень хотел бы избежать, так как это сводит на нет всю мою цель — регулировать цвет одних пикселей, а не других.

Как я меняю каждый пиксель

И вот как я экспортирую его в файл:

Чтобы повторить мою проблему. Мой проект требует, чтобы только некоторые пиксели в изображении были изменены в цвете, и только очень немного. Все остальные пиксели не должны видеть никаких изменений в цвете. Однако, когда я изменяю цвет пикселя, происходит «смешивание», которое меняет цвет соседних пикселей. Это непреднамеренно приводит к изменению некоторых пикселей, которые должны оставаться на 100% того же цвета.

Решение

Прежде всего, вы используете неправильный параметр «качество» при сохранении изображений в формате JPEG.

Ты используешь imagejpeg($newImage,»images/encryptedimage.jpg»,150) с качеством 150, но это значение определяется только от 0 до 100 с 75 по умолчанию.

Топ-пост этого месяца:  Как в wordpress подключить все JS скрипты в футере

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

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

Установите правильное значение качества. Тогда попробуйте еще раз. Помните, что «качество = 100» идентично получению огромных изображений — вероятно, не желательно. Вы также можете переключать форматы изображений: PNG сможет сохранить 24-битный цвет и изменения в один пиксель, но объем данных также увеличится.

Атрибут height HTML тега img

Атрибут height определяет высоту изображения в пикселях.

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

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

В HTML 4.01 допустимо в качестве значения атрибута height использовать как пиксели, так и проценты от родительского элемента. В HTML5 разрешено использовать только пиксели.

Значения атрибута

Значение Описание
pixels Высота изображения в пикселях (например, height=»100″).

Пример использования атрибута

Изображение шириной и высотой в 42 пикселя:

Ширина/высота изображения в качестве атрибута или в CSS?

Что такое «правильный» семантический способ указать высоту и ширину изображения? в CSS.

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

(Да, я понимаю с технической точки зрения конечного пользователя, это действительно не так вопрос.)

12 ответов

Он должен быть определен inline. Если вы используете тег img, это изображение должно иметь семантическое значение для содержимого, поэтому для проверки требуется атрибут alt.

Если изображение должно быть частью макета или шаблона, вы должны использовать тег, отличный от тега img, и назначить изображение в качестве фона CSS элементу. В этом случае изображение не имеет семантического значения и поэтому не требует атрибута alt. Я уверен, что большинство читателей экране даже не знал бы, что изображение CSS существует.

Я думаю, что зависит от того, как вы используете атрибут. Если вы стайлинг несколько изображений в списке или таблице, чтобы они лежали правильно, а затем поместите ширину / высоту в свой в CSS чтобы избежать необходимости добавлять другой набор тегов к каждому изображению в списке. Используйте что-то вроде

С другой стороны, если вы вставляете изображение в некоторых контент и он должен быть определенного размера, чтобы сделать поток документов правильно, затем поместите его в HTML-код. Таким образом, вам не нужно искажать таблицу стилей для каждого другого изображения в html. И таким образом, если вы измените содержимое на другое изображение, удалите изображение все вместе, у вас нет остатков кода, разбросанных в вашем CSS, чтобы не забыть удалить.

высота и ширина должны быть включены в HTML. Причина в том, что он создает отступы на странице. Если по какой-либо причине img не загружается (и Вы были хорошим мальчиком и включили alt..браузер покажет этот кадр (используя предоставленные w и h) с alt внутри.

основной полезной причиной является предотвращение эффекта» поп». Когда браузер загружает страницу, иногда большие аспекты, такие как img, загружаются дольше, и если вы не указали w и h в HTML-браузере временно свернет эту область, думая, что ее там нет. Затем, когда он наконец загружается, все встает на свое место.

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

Я бы сказал CSS.

HTML-это контент,
CSS-это внешний вид.

Если вы посмотрите на спецификацию HTML5, указывающую высоту и ширину, это не является требованием. Таким образом, код действителен с этими атрибутами или без них.

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

ли указать в html или css лучше всего судить по отдельным обстоятельствам. Большое количество изображений одинакового размера, вероятно, лучше всего обслуживать с помощью css, одно изображение с html. Тем не менее, если вы указываете другие стили для изображения (цвет границы, стиль или радиус, float и т. д.), имеет смысл добавить ширину и высоту в css.

Если вы укажете в html, вы можете использовать только пиксели. Если вы хотите указать в скажем, вам придется использовать css.

с другой стороны, нам рекомендуется использовать ems&%, а не px, чтобы избежать проблем, когда пользователи меняют настройки браузера и т. д., Но изображения всегда упоминаются в пикселях. Очевидно, что существуют практические причины для использования px для изображений. Однако сохранение изображений в px, похоже, отрицает аргумент о том, что они не используются.

Я бы сказал HTML.

атрибуты width и height используются для остановки загрузки и роста страницы в несвязанном порядке.

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

улов Firefox не использует атрибуты width и height для резервирования пространства изображений, однако я удивлен, что они его не обновили.

на статья в MDN, атрибуты HTML указывают на внутренние размеры изображения, т. е. его реальные размеры. Вот почему, в то время как HTML 4 также допускает процентные значения, HTML5 разрешает только значения px. (общая ловушка: «px» не должен быть написан)

Если вы хотите отобразить изображение с этими размерами, работа выполнена. В противном случае вам также нужно добавить CSS, чтобы указать дисплей размер.

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

Если это часть вашего шаблона сайта, я бы поместил его в файл CSS.

Если он находится только на одной странице, он должен быть встроенным (или определен в блоке CSS для конкретной страницы вверху).

Я считаю,что это часть контента, как вы упомянули, так же, как и атрибут src.

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

Я могу ошибаться, и если я, пожалуйста, кто-нибудь поправьте меня. но я думаю, что Google и некоторые другие поисковые системы индексируют содержимое тегов alt.

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

Если у кого-то есть лучшее решение, я хотел бы услышать его.

между тем, tho, учитывая необходимость того, что я описал, мне казалось бы разумным голосовать за встроенные параметры высоты/ширины HTML вместе с текстовыми описаниями alt, Как вопрос стандартной практики. Это, на самом деле, содержание, а не просто дизайн в таких случаях — и такие случаи действительно не должны быть исключениями из правило до тех пор, пока CSS и поисковые системы не придумают лучшее решение.

как почтовые клиенты имеют дело с ограничениями img В качестве атрибутов против встроенного Стайлз?

так, ограничения размера img не должны устанавливаться со встроенными стилями, прежде всего потому, что Outlook 2007/2010/2013 не соблюдает их.

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

tldr: используйте img атрибуты для HTML электронной почты.

Я бы пошел с рекомендацией W3C (d).

то есть, определение ширины и высоты в качестве атрибута, как это:

EM, REM или PX – почему нельзя использовать «только пиксели»

Стандартный размер пикселей заменяется на относительные пиксели в том случае, если

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

Заметил что на моем фотошопе, размер шрифта указывается в pt (пунктах). Выбираю 12 шрифт он показывается как — pt 12 а мне нужно что бы было в пикселях — 12 px.

Перевести пункты в Пиксели. Новый расчет. пункт. поменять. пиксель. Перевести.

Задавать размер шрифта в пикселях или пунктах нельзя лишь потому, что в этом случае старые версии IE (вплоть до шестёрки)

Изменить размер текста в браузере можно с помощью относительных и абсолютных единиц измерения

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

Размер шрифта, когда клиент изменяет размер текста в браузере.

Em равна текущему размеру шрифта, например, если fontsize документа равен 12pt, то 1em равен 12pt.

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

Перевел его в 72 pixel/centimeter с сохранением размеров, и теперь более менее похоже, если я буду верстать в pt. Но хотелось бы понять эту разницу и

Во-первых, текущий fontsize равен 100% (т. е. 12pt = 100%). При использовании «%», ваш текст становится полностью масштабируемым для мобильных устройств и удобства пользователя (accessibility). Как показала практика, использование em или % удобнее чем пункты и пиксели.

EM, REM или PX – почему нельзя использовать «только пиксели»

берите за основу размер читаемого текста в 1 em, заголовки — 1.8 — 2.3 ем, мелкий текст — 0.65 — 0.8 ем.

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

9.01.2020 / 19:46 #447729
Dinisimys
9.01.2020 / 20:11 #447730
ВитаминКО

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

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

иногда не значит всегда. в эпоху резиновой верстки нужен резиновый (в плане масштабируемости) текст.

в любом случае советую попробовать, хуже не станет

9.01.2020 / 20:53 #447736
Dinisimys
9.01.2020 / 21:12 #447741
Dinisimys
9.01.2020 / 23:00 #447862
Ксакеп
10.01.2020 / 00:58 #447909
ВитаминКО

Ага, такой опасный, что все популярные ресурсы перешли на адаптивный дизайн. Суровые ребята, чо.

А сколько еще новых сайтов создается..

Дэн, если честно, ты в учебнике по css какого года застрял? Что там наоборот ЗА повсеместное использование рх?

И про какие нагрузки ты говоришь? Сейчас смартфоны мощнее моего ноутбука, какие-то тормоза заметны на совсем уж старом железе. И то, когда используется жс (аякс).
Почитай хоть про то, как в браузере странички рендерятся.

Говоришь как те чуваки, которые вместо border-radius и -webkit-linear-gradient ставят картинку на фон со скругленными углами и, картинку градиента соответственно, чтобы «сохранить монолитность и совместимость» с IE 6

10.01.2020 / 02:42 #447927
HoldFast
10.01.2020 / 10:21 #447955
Dinisimys
10.01.2020 / 11:18 #447958
Ксакеп

Dinisimys, к хорошему лучше привыкать сразу (переучиваться дороже), поэтому по отношению к Беку всё было сделано правильно.

Responsive frameworks практически бесплатно дают возможность пользоваться сайтом как на десктоп, так и на мобильных девайсах, то есть не нужно создавать две версии сайта, следовательно возникает экономия ресурсов разработчиков. Чтобы можно было применить идеи адаптивного дизайна, используют подход mobile-first. Даже если убрать устройства с малыми размерами экрана, то есть планшеты, с которыми тоже нужно работать (браузерные игры, привет).

Что касается пикселей, я снова повторюсь — это уже старая технология. Появились новые HiDPI экраны, с повышенным количеством пикселей на точку (привет, ретина). И 16px там — это как 4px на стандартном экране. Касательно em — типографы спокойно используют такое обозначение, так что и ты сможешь.

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

EM, REM или PX – почему нельзя использовать «только пиксели»

Наверняка сказали что фото нужно разрешением 300 dpi (а не размером).
Разрешение — это плотность пикселей (элементарных «атомов-точек» изображения) на единицу длины изображения. Исторически принято мерять штук/на дюйм.
300 dpi — для полиграфии типичное разрешение. Понять, подойдет ваша фотка или нет можно так:

В любом просмотровщике растровой графики откройте этот файл фотки (например в ACDSee),
где-то сбоку экрана он показывает абсолютный размер в пикселях и цветовую модель.
Например: (1600х1200х24b)
Это означает, что изображение полноцветное (скорее всего RGB (24 bit))

Эту фотку (при идеальном качестве результата) можно напечатать размером не более (1600/300dpi) х (1200/300dpi) дюймов, т.е. 5,3 х 4 дюйма. (т.е. 13*10 см)
Удовлетворительного качества фотка получится при печати размером не более (1600/150dpi) х (1200/150dpi) дюймов => 26*20 см.

Почему Firefox не чтит CSS размера шрифта для кода тегов, завернутых в предварительно?

Я нашел несоответствие между браузерами в обращении размера шрифта (на Mac OS X 10.11.4). Я хотел бы знать, если это ошибка в Firefox, или ошибка в CSS, или я не понимая, что-то о CSS?

Это JSFiddle показывает детали. В разделе , как это:

стиль code < font-family: Courier; >изменяет размер шрифта , проявленную Safari и Chrome, но не в Firefox. Тем не менее в других разделах, то code увеличивается размер элемента от 13px до 16px во всех браузерах.

Почему размер шрифта увеличение от 13px до 16px после настройки значения font-family во всех браузерах?

Возможно , Firefox является изменяя , font-family но не font-size . Тем не менее , он делает изменение размера шрифта в других местах, как в code внутри p элемента или внутри списка.

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

Хотя проблема переносимости между браузером это накладывает не кажется, что тривиальный мне. В последний раз я хотел разметки HTML, так что моноширинные части показали то же самое как в Mozilla и M $ IE мне пришлось прибегнуть к абсолютным размерам шрифта, который должен быть, конечно, избегал из-за проблемы доступности, которые они налагают.

И да, есть простое решение — изменение настроек. Но большинство пользователей будет использовать значения по умолчанию. 🙁

Эта проблема не нова; это было известно в течение многих лет , что обработка браузера MONOSPACE шрифтов невероятно поддатая и непоследовательная в разных браузерах. Ряд обходных доступны , которые не требуют , чтобы переопределить предпочтение моноширинный шрифт , установленный пользователем, наиболее озадачивает из которых указать

Правильно: две monospace ключевые слова в конце стека шрифта. Никто не знает , почему это работает; он просто делает.

Для чего это стоит, UA стили Firefox содержат ссылки на -moz-fixed ключевое слово , которое относится к предпочтению, которое устанавливается пользователем, который включает в себя как семью и размера , несмотря на его значение для font-family свойства. Firefox поставляется с предпочтением , установленное на 13px в зависимости от того , шрифт моноширинных систем по умолчанию является. Казалось бы , что monospace, monospace заставляет браузер вычислять размер шрифта элемента в соответствии со спецификацией, сохраняя предпочтительную моноширинную семью, по крайней мере. Но это только предположение.

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

Почему размер шрифта увеличение от 13px до 16px после установки семейства шрифтов во всех браузерах?

вероятно, потому, что по умолчанию стилей браузера имеет следующие параметры.

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

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

Так как я задал вопрос и получил пару добросовестных ответов, которые, однако, на самом деле не отвечая на мой вопрос: Я буду стараться доказать, что это действительно проблема с существующими браузерами. Смотрите мой комментарий в конце о том, почему это может или не вопрос.

3 проблемы с размером шрифта в CSS / HTML в FireFox, Chrome и Safari на Mac OS X 10.11.4:

Задача 1. Изменение шрифт семья не должна изменять размер шрифта, но иногда он делает.

Я не знаю , что «агент пользователя таблицы стилей» есть. Там может быть все виды настроек на нем. Но независимо от этих настроек, изменения font-family не должны изменяться вычислен font-size . (Некоторые шрифты могут отображаться больше того же размера шрифта по сравнению с другими шрифтами на тот же размер шрифта, так что визуально они могут выглядеть больше или меньше, но вычисленный номер размер шрифта не должен меняться).

Обозначения: в следующем

p(code) means roughly

В ситуации по умолчанию, страница без каких-либо стилей, я вижу это во всех 3-х браузерах:

Возможно, агент пользователя таблицы стилей что-то вроде этого:

Агент пользователя не может быть с использованием относительных размеров для code , потому что он выглядит как 13px внутри обоих pre и p элементов. Так что может быть это:

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

Но тогда как объяснить это:

После установки code < font-family: Courier >(или семейство шрифтов, кроме monospace ) , мы получим:

Независимо от того , что таблица стилей, то font-size не должно измениться после того, как только меняя font-family .

Задача 2. Относительный font-size должны быть основаны на родительском элементе вычисляется font-size . Но иногда это не так .

При отсутствии стилей мы имеем:

После установки code < font-size: 100%; >мы должны иметь

Вместо этого мы до сих пор:

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

Кроме того , после установки code < font-size: 120%; >мы должны иметь

Вместо этого мы имеем:

Это показывает , что родительский элемент игнорируется, и что некоторое фантомное значение 13px используется для расчета относительных font-size .

Задача 3. Стандартный совет использовать , html < font-size: 62.5% >а затем использовать em или rem для шрифтов проклейки не работает правильно

(Примечание: FireFox с rem действительно кажется правильным)

(Примечание: с помощью также рекомендуется , body < font-size: 62.5% >казалось , чтобы произвести некоторые сумасшедшие результаты, как удвоение размера шрифта, так что я не учитывая , что здесь.)

Все это должно быть 16px = 1,6 * 10px

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

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

Из моего чтения, там была попытка сделать веб-страницы более чутко реагировать на родные настройки на каждом устройстве: адаптироваться к различным оборудования с большим или меньшим количеством пикселей на дюйм (PPI); чтобы позволить пользователям с ослабленным зрением, чтобы запросить больший размер текста таким образом, они могут читать более легко; и т.п.

Существуют различные рекомендации и немного споров о том , как лучше это сделать: указать размер шрифта с html и использовать em или rem везде , кажется, общественное мнение. В последнем время только с помощью старого доброго , px чтобы указать размер шрифта возвращается в стиле , с идеей , что px не определяют фактические пиксели экрана, а идеализированные 96 точек на дюйм для зрителя (который может переводить с различным числом пикселей) и позволяя браузер управления масштаба обрабатывать пользовательские необходимые изменения в размере шрифта.

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

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

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

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

Ответ OP перешел от вопроса к ответу:

Ответ от BoltClock был супер полезным. На странице он / она ссылается о Fixed MONOSPACE Калибровке Эрик Мейер имеет тщательный анализ и некоторые решения. Это объясняет некоторые из браузера механики , связанной с тем, когда используется настройки шрифтов пользователя, который объясняет некоторые из загадочного поведения я видел (например , почему же code элемент кажущимся унаследовать размер 13px , когда он был ребенком из p элемента с размером из 16px: причина в том , что на самом деле наследуется размер , medium который заставляет браузер использовать настройки по умолчанию обозревателя / пользователей).

Для моей ситуации я нахожу , что я могу удалить html < font-size: 16px; >стиль и вместо того, чтобы добавить следующее:

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

Я думаю, что в конечном итоге проблема в том, что браузеры имеют разных размер шрифта DEFAULTS / предпочтения для моноширинного шрифта, чем для других шрифтов. Основная идея «доступной адаптивный дизайн» в отношении размера шрифта является, чтобы позволить пользователю контроль над размером шрифта. Но когда у нас есть несколько параметров для размера шрифта (засечками, без засечек, моноширинный), то, что слишком много возможностей для пользователя, чтобы установить. Пользователь просто хочет большего размера текста, что они могут читать. Но для автора: они просто хотят, относительные размеры шрифтов, чтобы быть правильным в любой заданный размер.

В случае , если это полезно для кого — то еще, вот некоторые примеры (в пятно Eric Meyer стиль ) , показывающий , что monospace, monospace устраняет некоторые из проблем , которые я писал в моем собственном ответе ниже.

Это потому, что еще в темные века один Netscape DEV решил заставить его личные предпочтения на всех остальных в настройках браузера (большинство кодеров молодые люди, которые думают, что это умно, чтобы уничтожить их глаза, устанавливая размер текста один или два размера меньше, чем все остальные , они думают, что «моноширинный» к ним принадлежат и «без засечек» для нормальных людей).

Таким образом, Firefox поставляется с по умолчанию, которые псевдоним «Monospace» до меньшего размера шрифта, чем «без засечек». Довольно много истребляют скоординированы наборы шрифтов (где моноширинный шрифт предназначен выглядеть так же, как с засечками или без засечек один).

Ширина/высота изображения как атрибут или CSS?

Какой «правильный» семантический способ указать высоту и ширину изображения? В CSS.

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

(Да, я понимаю с технической точки зрения, это не имеет значения.)

Он должен быть определен inline. Если вы используете тег img, это изображение должно иметь семантическое значение для содержимого, поэтому атрибут alt необходим для проверки.

Если изображение должно быть частью макета или шаблона, вы должны использовать тег, отличный от тега img, и назначить изображение как элемент CSS для элемента. В этом случае изображение не имеет семантического значения и поэтому не требует атрибута alt. Я вполне уверен, что большинство читателей экрана даже не знают, что изображение CSS существует.

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

С другой стороны,, если вы вставляете изображение в некоторый контент, и он должен быть определенного размера, чтобы обеспечить корректный поток документа, а затем поместите его в HTML. Таким образом, вам не нужно настраивать таблицу стилей для каждого изображения в html. И таким образом, если вы измените контент на другое изображение, удалите изображение вместе, у вас нет остатков кода, разбросанного в вашем CSS, чтобы не забыть удалить.

Высота и ширина должны быть включены в HTML. Причина в том, что он создает интервал на странице. Если по какой-либо причине img не загружается (и вы были хорошим мальчиком и включили alt. браузер отобразит этот фрейм (используя предоставленные w и h) с помощью внутри внутри.

Основная полезная причина — предотвращение эффекта «поп». Когда браузер загружает страницу, иногда более крупные аспекты, такие как img, занимают больше времени для загрузки, и если вы не указали w и h в HTML, браузер временно разрушит эту область, думая, что ее нет. Затем, когда он, наконец, загружает все, попадает в нужное место.

Это особенно раздражает, но все еще довольно раздражает на компьютере, потому что вы собираетесь щелкнуть ссылку, и вдруг страница сместилась вниз, и вы случайно нажали неверную ссылку.

Я бы сказал, CSS.

HTML о содержании,
CSS — это презентация.

Если вы посмотрите на спецификацию HTML5, определяющую высоту и ширину, это необязательный вариант. Поэтому код действителен с этими атрибутами или без них.

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

Следует ли указывать в html или css наилучшие оценки по индивидуальным обстоятельствам. Большое количество изображений такого же размера, вероятно, лучше всего будет использоваться с css, одним изображением с html. Тем не менее, если вы указываете другие стили для изображения (цвет рамки, стиль или радиус, float и т.д.), Было бы целесообразно добавить ширину и высоту к css.

Если вы укажете в html, вы можете использовать только пиксели. Если вы хотите указать в процентах от опроса, вам нужно будет использовать css.

На стороне примечания нам рекомендуется использовать ems и%, а не px, чтобы избежать проблем, когда пользователи меняют настройки браузера и т.д., но изображения всегда упоминаются в пикселях. Очевидно, есть практические причины использования px для изображений. Однако сохранение изображений в px казалось бы отрицательным аргументом для того, чтобы не использовать их.

Я бы сказал HTML.

Атрибуты width и height используются, чтобы остановить загрузку страницы и разрастаться разрозненным образом.

Если вы когда-либо читали блок текста на странице только для того, чтобы его оттолкнули вниз, благодаря позднему загрузочному изображению выше, вы знаете, как это расстраивает! Добавление идентификатора к каждому изображению только для указания его ширины и высоты было бы смехотворным и почти таким же грязным, как и добавление двух атрибутов width/height.

Ловушка — Firefox не использует атрибуты ширины и высоты для резервирования пространства изображений, однако, я удивлен, что они не обновили его на самом деле.

Fornit Some Fornus

Предисловие

Идея о том, чтобы сделать статью про размерности, используемые в веб-дизайне, появилась давно и на неё возлагалось несколько задач: во-первых, привести в порядок свои собственные мысли, во-вторых, иметь место, куда «вместо тысячи слов» можно легко сослаться, а в-третьих, по порядку, но не по важности, помочь коллегам и другим любопытствующим поставить некоторые свои точки над i.

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

DPI и PPI

Статье в Ководстве про разрешение картинок уже исполнилось 14 лет, но путаница присутствует до сих пор. Экранную графику наделяют печатными характеристиками качества и уповают на значение в 300 dpi, хотя ситуация выглядит простой и понятной, если придерживаться трёх правил.

Правило №1: Видеосистема ничего не знает о дюймах, сантиметрах и процентах, а оперирует только пикселями. Любой графический объект (картинка или текст) выводится на экран монитора последовательно, пиксель за пикселем. Картинке без разницы какое разрешение у нее в свойствах: 72, 96 или 300, она отображается на экране объектом с заданной в пикселях длиной и шириной. В качестве опыта нарисуйте в Фотошопе прямоугольник 150×100 пикселей, сохраните его в 3 -х JPEG-файлах с разными значениями dpi, а потом откройте в браузере — разницы вы не увидите. Значение dpi можно изменить как при сохранении файлов через редактор, так и вручную в просмотрщиках. Некоторые растровые графические файлы, например PNG (через «save as. ») или GIF, сохраняются вообще без указания dpi.

Браузер игнорирует выставленные в настройках JPEG значения dpi

Указанное в свойствах картинки разрешение dpi учитывается только при печати изображения. Причем, если печатать напрямую из браузера, а не через редактор, то графика будет напечатана с разрешением 96 dpi в Windows или 72 dpi в Mac, поскольку ради сохранения пропорций на отпечатанной странице, браузер переводит условные дюймы pp(i) шрифтов в dpi отпечатка, но об этом ниже.

Правило №2: Термины dpi и ppi служат разным целям и их не следует путать. У растровой картинки нет разрешения, а есть размеры в пикселях по длине и ширине или в (гига)мегапикселях площади. Разрешение или разрешающая способность применима только для устройств ввода-вывода. Её выражают в количестве различимых единиц на дюйм длины: для печатающих устройств — это точки-на-дюйм (dots-per-inches, dpi), а для экранов используется термин пиксели-на-дюйм (pixels-per-inches, ppi)

http://dpi.lv/
Здесь можно помериться своим ppi, хотя авторы сайта некорректно называют его dpi.

У ранних мониторов CGA и EGA пиксели имели прямоугольную форму (PAR, pixel aspect ratio — 1:1.2, 1:2.4), сегодня пиксели квадратные, ppi по горизонтали и по вертикали совпадают и для упрощения расчетов разрешение указывается на квадратный дюйм. Устоявшиеся словосочетания вроде «разрешение 800×600» (калька с английского resolution) некорректны, поскольку одинаковые размеры матрицы при разной диагонали экрана дают разный ppi (в случае с 800×600 — 125 ppi при 8 -и дюймовом, 71 ppi при 14 -ти дюймовом экране), правильнее называть их «режимами монитора» (display modes).

Величина ppi отражает плотность пикселей экрана

Чем выше значение ppi, тем меньше размеры экранного пикселя и тем меньше «пикселизация» изображения. Минимальной различимой единицей экрана считается dot pitch (зерно экрана) — расстояние между субпикселями одного цвета, или, по-другому, размер триады пикселей RGB. В вопросах погони за высокими значениями ppi полезно помнить о том, насколько объективно использование таких величин в контексте человеческого глаза.

Острота зрения измеряется в угловых минутах (1/60 градуса) и определяется в России при помощи таблицы Сивцева (самая популярная) или таблицы Головина. Штрихи букв в таблице Сивцева имеют одинаковую постоянную толщину, а очко литеры квадратной формы со стороной в 5 штрихов. Таким образом, достоверно различаемые штрихи букв на определенной строке таблицы отражают разрешающую способность глаза, указанную для данного кегля. Считается, что при нормальном зрении («единичка»), человеческий глаз способен различать расстояние между двумя точками в 1 угловую минуту (α = 1’). Весьма редко, но встречаются люди, зрительная возможность которых лежит в рамках 0.4 — 0.5 угловой минуты.

X = 2 × D × tg(α/2)
ppi = 25.4 мм / X
——————————
D X ppi
5000 мм (референс) 1.45 мм (толщина штриха) 17.5
2000 мм 0.58 мм 44
800 мм 0.232 мм 109
400 мм 0.116 мм 219
100 мм 0.029 мм 875

В офтальмологических кабинетах зрение проверяется на расстоянии в 5 метров, это референсный показатель для нормального зрения, при котором различаются штрихи букв десятой строки таблицы (V = 1,0). Для комфортного просмотра ТВ (значение D в 2 метра) достаточно LED или LCD панели с разрешением в 50 ppi, поэтому FullHD на диагонали 45-50 см выглядит весьма привлекательно и не требует улучшения. При работе за компьютером (расстояние от монитора около 80 см) экран с характеристиками свыше 120 ppi может пригодится лишь в случае профессиональных или специфических нужд.

С комфортным чтением печатной продукции на расстоянии в 30-40 см вполне управляется существующее полиграфическое качество в 300 dpi. Минимальное расстояние, на котором способен фокусироваться глаз взрослого человека — 10 см, в этом случае максимальная разрешающая способность человеческого глаза заканчивается на величине в 875 ppi, что по сути является пределом, но на таком расстоянии никто не читает и не пользуется телефонами.

Таким образом, отображение картинки зависит только от характеристик самого монитора, выражаемых значением ppi. Почему же Фотошоп все равно услужливо предлагает нам сохранить JPEG-файлы в разрешении 72 dpi для Web? Делает он это, помятуя о «преданиях старины глубокой».

9’’ монохром
512 × 342 пикселя
72 ppi

В списке достоинств Apple Mac образца 1984 года был широкий ассортимент гарнитур шрифтов, растеризированных с печатных глифов, что по сравнению с существовавшими тогда моноширинными знакоместами MS-DOS (80×25 штук) выглядело действительно круто. Это стало возможно благодаря механизму перевода типографских пунктов в пиксели экрана. Дюймов на экране монитора нет, это объект реального мира (на бумаге), на мониторе есть только пиксели. Чтобы перевести размерность типографских пунктов шрифтов из дюймов в экранные пиксели (технический термин процесса — ppem, pixels-per-em) был использован «условный дюйм», выраженный в количестве экранных пикселей, которые мы фиктивно представляем как 72 пункта или как один дюйм — pp(i).

Правило №3. Экранный ppi как мера пиксельной плотности и условный pp(i) как шкала перевода пунктов в пиксели не совпадают. Первоначальное значение условного дюйма в 72 pp(i) для ранних макинтошей было оправданным: размеры матрицы монитора делали его близким к физическому дюйму, а эппловский ImageWriter принтер имел ровно вдвое бо́льшую разрешающую способность в 144 dpi. Таким образом, 1 пиксель на экране составлял (примерно) один типографский пункт, 72 пикселя условного дюйма легко переводились в 1 дюйм физический на принтере, а текст, набранный 12-ю пикселями на экране Macintosh давал ци́церо при печати. Но при этом имелись недостатки:

  • 10 -и пунктовый шрифт стандартной офисной печатной машинки смотрелся плохо на экране в 10 -и пиксельном исполнении, особенно в кегле строчных букв (x-height, 5 пикселей);
  • Расстояние, необходимое для чтения с экрана на 33% больше расстояния для чтения с бумаги, что усугубляло некомфортное отображение шрифтов;

Товарищи из лагеря Windows пошли «другим путем», чтобы исправить недочеты конкурентов и приняли в качестве условного дюйма для своего программного обеспечения 96 пикселей, что на ту самую треть превышало pp(i) у Mac. На многие годы это решение внесло сумятицу в стан пользователей. С одной стороны пикселей на каждый пункт бралось больше и аналогичные шрифты на одном и том же мониторе выглядели в Windows крупнее, чем у Mac и улучшали читаемость. Но при этом уменьшилось количество доступных пикселей для графики и остальных объектов. Кроме того, было нарушено близкое к 1:1 соответствие экранного (пикселей на экране) и печатного (точек на бумаге) пунктов, что на корню сгубило WYSIWYG-идеологию (к которой, кстати, так больше и не вернулись).

Соотношение пикселей, пунктов и дюймов для шрифтов Mac и PC

72 и 96 сохранились на платформах в качестве параметров по умолчанию, поэтому картинки на странице отображаются своими реальными размерами в пикселях, а текст в зависимости от pp(i) системы, на которой мы работаем. На разных мониторах шрифты выглядят по-разному и эта разница становится все более и более существенной. И Microsoft и Apple предлагают собственные решения, чтобы улучшить отображение экранной графики и шрифтов.

Так, после появления видеоадаптеров IBM 8514 в Windows ввели дополнительный режим 120 pp(i), который был доступен при выборе опции «Large Font 125%» — при этом увеличиваются шрифты и UI-элементы интерфейса (иконки, кнопки, поля ввода). На современных системах pp(i) можно изменить в разделе «Персонализация»: четыре автоматических режима (100%, 125%, 150% и 200% — 96 pp(i), 120 pp(i), 144 pp(i) и 192 pp(i) соответственно) плюс можно использовать линейку для ручной настройки. При этом Microsoft отмечает, что работает со сторонними разработчиками и не гарантирует качество отображения в не-«dpi-aware» (термин спецификации) приложениях при изменении pp(i) в настройках системы.

Настройка pp(i) в Windows и соотношения пикселей картинки и экрана в OS X (источник)

Кроме того, страницы можно масштабировать непосредственно в браузере: фиктивно изменяем ppi экрана, либо pp(i) если выставлена опция «только для текста». При этом векторные изображения также масштабируются, а растр претерпевает бикубическую интерполяцию. Здесь вендорные характеристики браузера накладывают отпечаток на качество и соответствие масштабированной страницы и окон.

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

Добавить комментарий