300 dpi полиграфии это цифра пальцем в небо. Разрешение подавляющего числа печатной картинки (когда оттенки создаются стандартным амплитудным растрированием) считается по формуле 1.41*lpi. (некоторые правда ошибочно считают коэффициент 2, но это не улучшает качества изображения). Большая часть обычных журналов имеет lpi — 150, а глянец изредка доходит до 175. Таким образом реальное разрешение цветного печатного изображения ближе к 225-250 dpi, а не к 300. Хотя нашему зрению этого вроде как хватает.
Но вторая особенность в том, что края 100% красочных плашек, например черных букв «выведенных на печать» из векторных шрифтов, соответствуют не lpi растра, а dpi фотонаборного автомата (или CTP), то есть обычно 4800 dpi (и более), откуда острота и точность текста в печатных изданиях многократно превышает таковую на экране, даже самого высокого разрешения. Так что с точки зрения точности отображения шрифтов, экранам пока не удастся дотянуться до обычной газетной печати.
PS изложенное — не IMHO, а основа полиграфического техпроцесса.
PPS я осознано не упомянул стохастического растрирования — это не самый распространенный процесс и фору экрану он дает еще большую.
Главный враг этого «моноцикла» — инерция. разгоняешся — тебя заваливает на спину, тормозишь — пытаешься кувыркнуться. резкий тормоз и вместо остановки не управляемо катишься кубарем вперёд. чтобы немного сгладить эту проблему без второго колеса нужно увеличить диаметр до нескольких метров, но решить ее совсем в отсутствии хотя бы еще одного колеса не получится. иными словами идеальный моноцикл это велосипед.
Понимаю вашу логику, но не готов разделить ее.
Для себя выбрал стратегию graceful degradation. Если у пользователя старый браузер или какой-то новый стандарт/драфт не поддерживается, то функция может быть отключена без проблем для сути страницы. В крайнем случае пользователя можно предупредить, что его браузер не до конца передает задуманное и предложить ему выбор — наплевать на отсутствие какого-то градиента или обновить/сменить браузер.
CREATE TABLE IF NOT EXISTS `sph_counter` (
`counter_id` int(11) NOT NULL,
`max_doc_id` int(11) NOT NULL,
PRIMARY KEY (`counter_id`)
) ENGINE=MyISAM DEFAULT CHARSET=latin1;
а так выглядит секция sphinx.conf
source main {
type = mysql
sql_host = 127.0.0.1
sql_port = 3306
sql_db = *DB*
sql_user = *LOGIN*
sql_pass = *PASS*
sql_query_pre = SET NAMES utf8
sql_query_pre = REPLACE INTO sph_counter SELECT 1, MAX(nid) FROM node
sql_query_range = SELECT 1,( SELECT max_doc_id FROM sph_counter WHERE counter_id=1 )
sql_range_step = 1000
sql_query = select r.nid as id, r.nid as nid, r.title as subject, concat(r.teaser, r.body) \
as content, n.created, n.changed as last_updated, NOT(n.status) as is_deleted, n.type as nodetype, \
n.uid as uid \
from node_revisions r, node n where n.vid=r.vid and n.status > 0 \
and n.type IN ('news', 'poll', 'blog', 'story') and r.nid between $start and $end \
and r.nid <=( SELECT max_doc_id FROM sph_counter WHERE counter_id = 1 )
sql_attr_uint = nid
sql_attr_uint = uid
sql_attr_timestamp = created
sql_attr_timestamp = last_updated
sql_attr_bool = is_deleted
}
source delta : main {
type = mysql
sql_query_pre = SET NAMES utf8
sql_query_range = SELECT ( SELECT max_doc_id FROM sph_counter WHERE counter_id=1 ), MAX(nid) FROM node
sql_range_step = 1000
sql_query = select r.nid as id, r.nid as nid, r.title as subject, concat(r.teaser, r.body) \
as content, n.created, n.changed as last_updated, NOT(n.status) as is_deleted, n.type as nodetype, \
n.uid as uid \
from node_revisions r, node n where n.vid=r.vid and n.status > 0 \
and n.type IN ('news', 'poll', 'blog', 'story') and r.nid between $start and $end
}
Чего тут нет:
— индексации комментариев (она была не нужна)
— разбивки индекса на части (в данный момент main легко обновляется за 4 секунды глубокой ночью), а delta раз в 5 минут обновляется за несколько десятых секунды.
Не сочтите за укор, но что для вас важнее, скорость разработки или производительность последующей работы? Лишняя картинка это лишний запрос к серверу от каждого нового пользователя. Если пользователей не планируется больше 100 в день, то ответ склонится в пользу скорости разработки, а если это популярный и расширяющийся сервис, то оптимизацией лучше озаботиться сразу. css-градиенты это один из способов избавиться от многих ненужных картинок. Кстати спрайты и data-url тоже намного сложнее реализовать, чем россыпь простых картинок, но оно обычно того стоит.
Аналогично использую девелоперскую версию drupal.org/project/sphinxsearch в которой убрал их собственный интерфейс индексации и написал ручные запросы sql. >30к материалов индексируется за 4 секунды против 6 минут встроенного скрипта.
Давайте не передергивать мои слова :) Промо-сайты нужная штука, но они именно — произведения искусства, которым место в галерее ИМХО. Перед тем, как спорить со мной скажите какое число их посетителей возвращается поработать с ним еще? Поглядели, восхитились и ушли работать с нормальными, серыми для вас, сайтами. У меня есть сайт, куда постоянные посетители (около тысячи) ходят в среднем по 5 раз в сутки на протяжении полутора лет. Покажите мне такой же сайт на флеше и я признаю вас правым.
Флэш, с его инструментами анимации и языком программирования, не ограничивает вас в вашей фантазии.
А лучше бы ограничивал. ;-)
Ладно бы дизайнеры отдавали себе отчет в юзабилити, но для пользования таким сайтом часто надо учиться понимать логику вашего неограниченного дизайнера, а это не то зачем люди ходят в интернет. Ну а если дизайнер научится следовать пользовательскому опыту, то большую часть сайта оставит на html/css/javascript, чтобы не повторять то же самое на флеше ради пары эффектных штрихов. Вот и получается, что интерактивным флешевым сайтам место в художественной галерее, а не в реальном интернете, где люди привыкли копировать текст, ссылки и картинки со страницы и будут недовольны тем, что вы мешаете им продвигать ваш же ресурс цитатами, если он им понравился. Вот для этого мы мучаемся с javascript вместо flash. Вот поэтому разработчики браузеров уделяют время обеспечению копируемости содержимого, в отличие от разработчиков проигрывателя флеша.
Я разработчик. И во флеше в нынешнем виде вижу пример компромисса. Это был бы идеальный инструмент если бы:
1. Был открытым стандартом с конкурентной средой. В нынешнем виде Эдоби (они просят называть себя так) не особо стремятся к улучшению производительности и распространению на все возможные платформы.
2. Имел бы открытый код, чтобы такие простые досадные ошибки как проблемы с кирилицей под Linux можно было решить парой человеко-часов, не ожидая годами этого простого патча.
3. Имел бы кроссплатформенный компилятор с возможностью программной генерации кода. Если я не ошибаюсь, они уже сделали возможность создания проектов в xml, осталось сделать возможным заставить работать это на существующих *nix серверах.
В данный момент я оцениваю «войну с флешем» как единственно возможный способ повлиять на недружелюбное поведение монополиста, заставить его последовать общим правилам развития интернета через общественное влияние, раз уж здоровая конкуренция невозможна. Уверен, что никакой смерти флеша не будет, если Эдоби начнут прислушиваться к требованиям времени.
PS по теме вашей реплики: Для создания сайтов есть веб-стандарты. Они учитывают пользовательский опыт обращения с сетью. Сайты, целиком написанные на флеше этот опыт перечеркивают. Этого фактора мне достаточно, чтобы быть категорически против них. При этом я всеми руками За флеш в медиа-блоках сайтов, будь то баннеры, игры или интерактивные элементы пользовательских данных. Проигрыватель видео или звука лучше, имхо, встроить в браузер, хотя я не буду против флешеого проигрывателя, если он расширяет возможности стандартного.
От грифельных карандашей космонавты отказались как раз в пользу таких ручек (кстати это не фломастер) из-за неприятных особенностей невесомости — маленькие обломки графита с кончика карандаша в там представляют немалую угрозу. Например электропроводностью, в сочетании со способностью проникать через щели в крышках электронного оборудования.
Нет, вы не поняли. У меня не cree, а SSC P7, имеющий 12W и 900лм (это где-то в идеальных условиях, но 650-700лм он дает). На одном аккумуляторе 16850 он работает порядка часа и дает свет сопоставимый с автомобильной фарой — его отчетливо видно не только на освещенной ночной улице, но и днем в не солнечную погоду.
Я уже второй год езжу на велике с 12W светодиодом (яркость на уровне средней автомобильной фары). В данный момент на dealextreme есть хороший комплект для такого света за $80. Жаль, что как и в моей модели, свет нельзя настроить так же точно как и в автомобильной оптике.
За то работают не только мышцы ног. Я вот наоборот не люблю скучный вкрут по шоссе — ищу варианты со сложными условиями передвижения по маршруту. За прошлое лето великом и спину поднакачал и руки.
Но вторая особенность в том, что края 100% красочных плашек, например черных букв «выведенных на печать» из векторных шрифтов, соответствуют не lpi растра, а dpi фотонаборного автомата (или CTP), то есть обычно 4800 dpi (и более), откуда острота и точность текста в печатных изданиях многократно превышает таковую на экране, даже самого высокого разрешения. Так что с точки зрения точности отображения шрифтов, экранам пока не удастся дотянуться до обычной газетной печати.
PS изложенное — не IMHO, а основа полиграфического техпроцесса.
PPS я осознано не упомянул стохастического растрирования — это не самый распространенный процесс и фору экрану он дает еще большую.
Для себя выбрал стратегию graceful degradation. Если у пользователя старый браузер или какой-то новый стандарт/драфт не поддерживается, то функция может быть отключена без проблем для сути страницы. В крайнем случае пользователя можно предупредить, что его браузер не до конца передает задуманное и предложить ему выбор — наплевать на отсутствие какого-то градиента или обновить/сменить браузер.
в базу добавлена таблица
а так выглядит секция sphinx.conf
source main { type = mysql sql_host = 127.0.0.1 sql_port = 3306 sql_db = *DB* sql_user = *LOGIN* sql_pass = *PASS* sql_query_pre = SET NAMES utf8 sql_query_pre = REPLACE INTO sph_counter SELECT 1, MAX(nid) FROM node sql_query_range = SELECT 1,( SELECT max_doc_id FROM sph_counter WHERE counter_id=1 ) sql_range_step = 1000 sql_query = select r.nid as id, r.nid as nid, r.title as subject, concat(r.teaser, r.body) \ as content, n.created, n.changed as last_updated, NOT(n.status) as is_deleted, n.type as nodetype, \ n.uid as uid \ from node_revisions r, node n where n.vid=r.vid and n.status > 0 \ and n.type IN ('news', 'poll', 'blog', 'story') and r.nid between $start and $end \ and r.nid <=( SELECT max_doc_id FROM sph_counter WHERE counter_id = 1 ) sql_attr_uint = nid sql_attr_uint = uid sql_attr_timestamp = created sql_attr_timestamp = last_updated sql_attr_bool = is_deleted } source delta : main { type = mysql sql_query_pre = SET NAMES utf8 sql_query_range = SELECT ( SELECT max_doc_id FROM sph_counter WHERE counter_id=1 ), MAX(nid) FROM node sql_range_step = 1000 sql_query = select r.nid as id, r.nid as nid, r.title as subject, concat(r.teaser, r.body) \ as content, n.created, n.changed as last_updated, NOT(n.status) as is_deleted, n.type as nodetype, \ n.uid as uid \ from node_revisions r, node n where n.vid=r.vid and n.status > 0 \ and n.type IN ('news', 'poll', 'blog', 'story') and r.nid between $start and $end }Чего тут нет:
— индексации комментариев (она была не нужна)
— разбивки индекса на части (в данный момент main легко обновляется за 4 секунды глубокой ночью), а delta раз в 5 минут обновляется за несколько десятых секунды.
А лучше бы ограничивал. ;-)
Ладно бы дизайнеры отдавали себе отчет в юзабилити, но для пользования таким сайтом часто надо учиться понимать логику вашего неограниченного дизайнера, а это не то зачем люди ходят в интернет. Ну а если дизайнер научится следовать пользовательскому опыту, то большую часть сайта оставит на html/css/javascript, чтобы не повторять то же самое на флеше ради пары эффектных штрихов. Вот и получается, что интерактивным флешевым сайтам место в художественной галерее, а не в реальном интернете, где люди привыкли копировать текст, ссылки и картинки со страницы и будут недовольны тем, что вы мешаете им продвигать ваш же ресурс цитатами, если он им понравился. Вот для этого мы мучаемся с javascript вместо flash. Вот поэтому разработчики браузеров уделяют время обеспечению копируемости содержимого, в отличие от разработчиков проигрывателя флеша.
1. Был открытым стандартом с конкурентной средой. В нынешнем виде Эдоби (они просят называть себя так) не особо стремятся к улучшению производительности и распространению на все возможные платформы.
2. Имел бы открытый код, чтобы такие простые досадные ошибки как проблемы с кирилицей под Linux можно было решить парой человеко-часов, не ожидая годами этого простого патча.
3. Имел бы кроссплатформенный компилятор с возможностью программной генерации кода. Если я не ошибаюсь, они уже сделали возможность создания проектов в xml, осталось сделать возможным заставить работать это на существующих *nix серверах.
В данный момент я оцениваю «войну с флешем» как единственно возможный способ повлиять на недружелюбное поведение монополиста, заставить его последовать общим правилам развития интернета через общественное влияние, раз уж здоровая конкуренция невозможна. Уверен, что никакой смерти флеша не будет, если Эдоби начнут прислушиваться к требованиям времени.
PS по теме вашей реплики: Для создания сайтов есть веб-стандарты. Они учитывают пользовательский опыт обращения с сетью. Сайты, целиком написанные на флеше этот опыт перечеркивают. Этого фактора мне достаточно, чтобы быть категорически против них. При этом я всеми руками За флеш в медиа-блоках сайтов, будь то баннеры, игры или интерактивные элементы пользовательских данных. Проигрыватель видео или звука лучше, имхо, встроить в браузер, хотя я не буду против флешеого проигрывателя, если он расширяет возможности стандартного.