Как стать автором
Обновить

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

С Android такая проблема дейсвительно актуальна. Впервые сталкнулся с этим, когда адаптировал интерфейс iOS-приложения под Android и обнаружил, что никаких «аппаратных» пикселей нет, и что теперь я могу лишь гадать, как будет выглядеть интерфейс на том или ином Android-устройстве. Никакого Pixel-perfect. В iOS с этим проще.
А должно ли быть это Pixel-perfect в принципе? Меня всегда бесило, что размеры, например, окна приложения напрочь игнорируют то, какой у меня монитор (физические размеры), в каком разрешении он сейчас работает и какие настройки масштабирования выставлены в ОС. Решил разработчик что окно должно быть 700px в ширину и плевать ему работаю я за 24" монитором с разрешением 640x480 или за 14" с разрешением 1600x1200.
ну где-то в статьях про шрифты упоминали, что было бы хорошо в ОС задавать размеры в, например, сантиметрах. А тогда уже размеры окон зависили бы от утсановленного dpi. Ну и там же упоминалось, что задавать это в новых приложениях не проблема, но всё-равно остаётся куча мест, где ОС тупит и шрифт вылазит за окно, а еще есть старые приложения с пиксельными размерами.

Когда-нибудь таки примут стандарт dpi нехависимой величины размера, и сделают в новой ОС все размеры принудительно в этих едницах (почему нельзя использовать см — непонятно). Вот тогда и исчезнут такие проблемы
Афаик, такая возможность появилась начиная с Win95 (если не раньше, GDI и в Win3 был точно), но производители софта её массово игнорировали, указывая всё в аппаратных пикселях. А некоторые производители, например, WYSIWYG редакторов поступали ещё интереснее — для контента учитывали, а для интерфейсов — нет. Хотя, конечно, и производители ОС схалтурили вынеся такую важную для UI настройку куда-то вглубь системы, а не используя те же Ctrl+±, так что редкий пользователь знал где она и для чего нужна.

Использование абсолютных физических размеров (сантиметры, дюймы, пункты и т. п.) тоже не панацея — при одном и том же физическом DPI у экранов могут быть разные размеры и находиться они могут на разном расстоянии от глаз. Хотя это лучше чем использование физических пикселей, особенно если есть у пользователя возможность удобно масштабировать, а дефолтная настройка масштабирования производителя девайса учитывает наиболее распространенный юзкейс.
Ну можно задавать всё в телесных углах (стерадианы/квадратные секунды и т.п.), А если расстояние до глаз определить нельзя, то считать что расстояние до пользователя зависит от dpi. Но это просто очень непривычно и все запутаются.
Задавать все размеры для контента относительно дефолтного шрифта, который устанавливается производителем ОС/девайса и корректируется пользователем или (для расположения блоков) в %% от размеров экрана, при этом иметь возможность (для адаптивной вёрстки) получать размеры экрана в единицах пропорциональных дефолтному шрифту. По-моему достаточно привычно. Вот только что делать с существующей вёрсткой, заточенной под аппаратный пиксель.
Наверное это жутко удобно, в стерадианах считать
Нунемного довёл до абсурда. Можно взять какую-то единицу, которая зависит от стерадианов и обозвать «стандартный миллиметр» (телесный угол при котором виден один миллиметр на рассстоянии таком-то.).

А вобоще да, в процентах будет получше, т.к. телесный угол полной ширины экрана будет меняться при смене расстояния
Можно считать в градусах и угловых минутах. Угловая минута как раз совпадает с разрешающей способностью нормального глаза.
НЛО прилетело и опубликовало эту надпись здесь
Видимо решили стать ближе к «народу» — производителям браузеров, которые упорно не хотели считать угловые размеры хотя бы ориентировочно, пользуясь тем что всякие «very different» формально не определены.
Задача в том, чтобы выглядило отлично на любом экране/в любом браузере.

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

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

Мир в поисках решения.
Беда в том, что у разных людей разные представления об «отличном».
Огромное количество людей, делающих интерфейсы, искренне хочет, чтобы у всех выглядело ровно так, как у них — и плевать на различия в зрении, разрешении и размере.
Их большинство.
Что интересно, браузеры (десктопные) как-то умудряются относительно нормально учитывать DPI отличающиеся от типичных экранных на порядок — при печати, — но напрочь игнорируют DPI (как физическое, так и логическое) дисплеев, отличающееся от стандартного 96 на единицы и единицы десятков процентов (хотя некоторые честно пытались). Сдаётся мне, что w3c само отрыло себе эту яму, когда-то допустив привязку логического пикселя к аппаратному в одних ситуациях, но не допуская в других, причём без чёткого, математически однозначного разделения ситуаций, что демонстрирует нынешний «кризис» с экранными DPI, отличающимися от типичных не на проценты, но и не на порядки, а в разы.
Кризис начался тогда, когда начали со слов разработчиков браузеров стандарты записывать. И весь мусор начал оседать в спецификациях. Есть только одна часть спеки CSS3, которая действительно проработана и полезна — локализационные возможности текста. Остальное…
НЛО прилетело и опубликовало эту надпись здесь
ЭЛТ-шки без EDID ещё живы? Моя 2005-го умерла в прошлом году, но EDID имела. Ну и кроме того имел привычку указывать хотя бы «стандартный 15» монитор" (или как там было), если определился как просто «стандартный монитор» — некоторые приложения эту инфу использовали.
НЛО прилетело и опубликовало эту надпись здесь
Все же должен быть некоторый контроль над происходящим со стороны человека. Если в FullHD текст нормально читаем, то при уменьшении разрешения до 320х480 размер шрифта упадет до единиц пикселей. И наоборот, нормальный размер для мобильного, а на high-res экране текст будет просто огромным.

Думаю возможно научить браузер придерживаться некоторых ограничений, но часто мнение дизайнера расходится с мнением браузера. Для этого и нужна возможность вносить коррективы и ограничения.
Вопрос в том какого человека, пользователя или разработчика? Сейчас де-факто контроль у разработчика, пользовательские настройки ОС и браузера игнорируются. По идее разработчики должны задавать размеры только для какой-то стандартной ситуации (скажем FullHD экран 24" на расстоянии вытянутой руки среднего человека с нормальным зрением), а браузеры (вместе с ОС, как знающей о железе больше всех) конвертировать эти размеры сначала в стандартные варианты использования девайса (причём учитывать, что тот же планшет может быть штатно подключен к 40+ панели), а потом учитывать пользовательские настройки (например увеличенные шрифты для слабовидяших).
Но вот стандартных-то вариантов этих и нету. А ограничивать свободу браузеру должен разработчик. Пользователю пока что неплохо помогает зум, при условии что он не запрещен с помощью тех же media queries. О масштабировании текста можно почитать здесь habrahabr.ru/post/145535/
Что-то я вообще не могу сейчас представить себе pixel-perfect верстку при таком подходе.
Точнее, ее критерии.
Наверное, разумным будет ставить требования верстальщику в виде cписка значений dpr под которые надо иметь «референсный» pixel-perfect.
Так что ли?
НЛО прилетело и опубликовало эту надпись здесь
Наверное растровые картинки и являются основным источником нынешних проблем в веб-вёрстке и UI.
С картинками проблема тоже решаема, чему я тебя только учил)))
если картинка большая — проблем не возникает если верстать грамотно, причем не возникает даже в случае ее масштабирования, если маленькая — то либо настройки рендера выставляем для одноцветных иконок, либо выставляем ее точно по пикселю для полноцветных + иногда помогают настройки рендера и кеша.
А в новом Metro же этих проблем просто нет, я вообще замлю под него и не нарадуюсь

И кстати надо учитывать, что да, на одном и том же устройстве с различным DPI, WPF элементы будут выглядеть одинаково по размеру, но если взять например настольный моник 24" 1920*1024 и планшет в 8" с разрешухой 1280*800 — то на планшете элементы будут меньше, при любых настройках DPI на обоих устройствах, почему, додумай сам)
Незнаком с WPF. Почему?
На самом деле в двух словах не объяснить
Просто физическая плотность точек и установленное для нее аппаратное разрешение для каждого устройства свои, В Windows можно менять DPI — но на самом деле DPI не меняется я применяется программно масштабный коэффициент, те по умолчанию масштабный коэффициент = 1, но к сожалению не всегда эта единица совпадает с реальным дюймом (точнее почти никогда не совпадает) потому что есть такой фактор — разрешение экрана, и разрешение должно быть одним из стандартных, те по сути тут хитрое сочетание 2х масштабных коэффициентов, производитель просто подбирает оптимальные значения для своего устройства, но эти настойки редко точно дают физический размер устройства если считать программно их, и в итоге WPF может думать что устройство больше или меньше, хотя это не так.

Есть древняя статья на эту тему, где сравнивается ноут и настольный монитор при работе с WPF
www.wpflearningexperience.com/?p=41
я лишь хочу сказать что там все правильно, мои тесты на моих устройствах подтверждают это.

Собственно эта проблема ждет любую модель которая считает размеры элементов в физических единицах (сантиметры, дюймы...)
То есть, «если взять например настольный моник 24» 1920*1024 и планшет в 8" с разрешухой 1280*800" и выставить для них реальное DPI в этих разрешениях, то всё будет ОК и проблема собственно в том, что винда не ставит их автоматом, хотя обычно в современных реалиях знает это из EDID, а использует 96 DPI и как бы корректирует размеры монитора, считая что планшет 15", а монитор 22" (если не ошибся с теоремой Пифагора :) )?
и тут вас будет ждать разочарование — ничего не измениться для элементов WPF/Metro )
Я же писал в 1м сообщении, что для любых настроек DPI на обоих устройствах (точнее конечно на DPI, а масштабного коэффициента) на планшетике все будет мельче на 20% примерно
тут вся фишка в том что начальный коэффициент не совпадает с реалиями — и тут вы хоть занастраивайтесь, ничего не поменяется (именно для WPF или другой системы которая задает размеры в дюймах/сантиметрах, а для аэро винды, и всего остальнонго что пикселями меряет все будет масштабироваться)
это на самом деле сложно понять не видя перед собой два таких устройства и не пробуя различные настройки, я и сам то с трудом улавливаю суть, и могу оказаться не прав, просто знаю что это факт.
Ну для любых этого никак не может быть, по-моему, если только случайно реальный DPI*масштаб монитора не окажется на 20% меньше реального DPI*масштаб планшета. Ведь даже в статье по вашей ссылке у человека получилось сделать четыре дюйма четырьмя дюймами на разных дисплеях с разными реальными DPI, — причём выставил DPI не подбором, а реальные.

На коммент ниже: а с иксами сейчас ещё интереснее — одна подсистема выдаёт DPI и размеры из EDID, то есть близкие к реальным, а другая «виртуальные» исходя из разрешения и 96 DPI, а разработчики пользуются одной или другой на своё усмотрение, некоторые даже в одной программе двумя пользуются. Причём сделали это для совместимости с виндой, вернее с «other popular desktop environments», но мы то знаем…
не знаю как у него это получилось, возможно потому что он делал все на xp, там WPF работает не полноценно.
я вот прямо сейчас заканчиваю приложение на Metro под Win8, тестю на обоих устройствах — на планшете — меньше в любом случае чем на десктопе (еще раз, программные установки DPI никак не влияют на размер WPF(в моем случае Metro/Xaml это одно и тоже) тк размеры выставлены в дюймах по сути, они влияют только на те элементы размер которых выставляется напрямую в пикселях)
Это же и заявлено в спецификации WPF — пиксельно независимые размеры элементов, те что 300 пикселей в дюйме, что 50 — размер будет одинаков, но с поправкой — для этого же устройства.
те сама ОС думает что физическое разрешение планшета — больше, моник у меня 23" поэтому близко к реальности, поэтому и все что работает на ОС — будет думать так же
а вот про то что винда считает что размер физический устройства — другой, тут вы правы, и поэтому никакая другая система в винде не сможет посчитать по другому, отсюда и разница в размерах на WPF
Пока аппаратный пиксель — значимая для качества изображения величина — бессмысленно говорить о каких-то независимых привязках. Смасштабируйте на проценты изображение со схемой/диаграммой и вместо чёткого изображения получите размазню. То же самое с элементами UI.

Чёрная вертикальная или горизонтальная линия имеющая ширину равную аппаратному пикселю сдвинутая на полпикселя в сторону — это со всякими сглаживаниями фактически серая двухпиксельная линия, воспринимаемая как резко утратившая контраст и цвет.

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

Ну и отдельное «фи» любителям назначать новые смыслы терминам и ключевым словам, ломая логику работы программ. Как говорят у нас на Украине — «повбывав бы!»
ничего подобного, чёрная вертикальная линия или схема/диаграмма уменьшенная через какой-нибудь качественноый spline64 остаётся дотстаточно чёткой.
А можно пример? Очень интересно, где эта чёрная вертикальная линия находится физически, будучи сдвинута на полпикселя и обработана этим алгоритмом?
Пускай пиксель остается физическим пикселем. Это вполне понятная и важная единица. Если px переопределят, мы вообще потеряем возможность использовать физические пиксели. Может, захочется нарисовать тончайшую линию, какую только дисплей согласится показать. А может мы хотим рисовать в canvas со сглаживанием.

Но ведь есть миллиметры! Почему мы забываем про метры, сантиметры и миллиметры. Зачем усложняем себе жизнь и считаем в этих искусственных референсных пикселях или dip — «пикселях» mdpi дисплея? Миллиметры — очень понятная физическая единица, независимая от плотности экрана, сиюминутных обстоятельств и корыстных интересов.

Все необходимые инструменты уже в наших руках. Всего лишь нужно ими правильно распорядиться. А пиксели оставьте в покое, пожалуйста.
НЛО прилетело и опубликовало эту надпись здесь
Ну тогда развитие событий предопределено. «Грехи отцов» — это страшно. «Сон разума рождает чудовищ» — иначе и не скажешь.
Ещё хуже: For a CSS device, these dimensions are either anchored (i) by relating the physical units to their physical measurements, or (ii) by relating the pixel unit to the reference pixel.

То есть стандарт вообще не определяет однозначно привязку пикселей и физических размеров. Дизайнеру или верстальщику остаётся только гадать к чему и как производители привяжут. Или детектировать тип устройства (через media queries например) и надеяться что детектировал однозначно и, например, разрешение 800x600 соответствует телефону, а не старому 14" монитору.
НЛО прилетело и опубликовало эту надпись здесь
А я том, что нет формальных критериев для определения где «lower-resolution» и «unusual viewing distances», а где наоборот. Один производитель решит, что 296 DPI ещё «lower», а другой нет и на одинаковых экранах будем видеть разную картинку.
НЛО прилетело и опубликовало эту надпись здесь
НЛО прилетело и опубликовало эту надпись здесь
Допустим дизайнер или верстальщик выставили размер шрифта 0,423 см (1/6 дюйма или 12 пунктов) считая что это наиболее удобный размер для чтения с его монитора, расположенного в метре от глаз. На планшете, который держат в 30 сантиметрах от глаз или на распечатке этот шрифт будет слишком крупный, на 40+" телевизоре, который смотрят с 3-х метров — слишком мелким. Вывод: физические размеры не панацея, их восприятие прямо зависит от расстояния до глаз, а значит должны физические размеры зависеть хотя бы от этого сиюминутного обстоятельства, которое для конкретного девайса конкретного пользователя не такое уж сиюминутное.

Кому нужна тончайшая линия, которую глаз не увидит? Нужна линия минимальной толщины, которую ещё увидит глаз (грубо — одна угловая минута), а решать воспроизводить её одним пикселем на устройстве с 96 DPI или десятью на 2400 DPI должно устройство со своим софтом, учитывая типичное для этого устройства расстояние до глаз и пользовательские настройки.
НЛО прилетело и опубликовало эту надпись здесь
Зарегистрируйтесь на Хабре , чтобы оставить комментарий

Публикации

Истории