Разница между вектором и растром напоминает отличие студийной записи от "живого" концерта. Студийная мастер–копия сохраняет на отдельных дорожках партию каждого инструмента; как и векторное изображение, ее можно "пересводить", сколько угодно преобразуя, сдвигая, выбрасывая отдельные звуковые слои и добавляя новые. Концертная же запись и растровая картинка если и поддаются обработке и "приглаживанию", то лишь с помощью хитроумных фильтров. За эту негибкость вы получаете взамен в музыке - характерную экспрессию и "живую" фактуру звука, а в компьютерном растре - богатство текстур и некоторые принципиально недостижимые в векторе эффекты.
Интересное следствие этой концептуальной простоты - относительно небольшое количество используемых растровых форматов. Сейчас в этой области уже вряд ли можно придумать что–нибудь принципиально новое. Большинство растровых форматов, которые, как и векторные, начинали свою историю в качестве фирменных форматов той или иной программы, давно уже зажили собственной жизнью и кажутся теперь одинаково "родными" всем существующим растровым редакторам (а следовательно, нет никакой нужды выходить за пределы двух–трех общеупотребительных форматов). Из векторных форматов настолько же "обобществленным" сумел стать разве что PostScript, но и для него не редкость ситуация, когда записанный в одной программе PostScript–файл отказывается считываться в другой, - что невозможно себе представить для формата растрового.
На все четыре стороны.Экзотическая разновидность растровой графики - панорамные форматы, хранящие не двумерную картинку, а полный круговой обзор из некоторой точки, "склеенный" из нескольких снимков широкоугольным фотоаппаратом. Для просмотра такой панорамы нужно либо распечатать и свернуть ее в кольцо, либо (что, конечно, гораздо удобнее) "прокручивать" специальной программой, компенсирующей искажения, возникающие при проецировании кругового изображения на плоский экран. Некоторые из этих форматов дают не только панорамный, но и сферический обзор, включающий вид "в зенит" и "под ноги". Такими панорамами пользуется, к примеру, фирма Toyota для показа потенциальным клиентам интерьера своих автомобилей.
Цвета. Самые важные для веб–дизайнера форматы - GIF и JPEG - подробно рассматриваются в гл. IV (стр. 252), поэтому здесь вместо форматов растровой графики мы обсудим цветовые ограничения этих форматов и компьютерных устройств вывода (ведь и компьютерный дисплей, и принтер могут отображать только растр, пусть и генерируемый программой "на лету" из векторного представления). Хотя цветовой спектр есть непрерывный континуум, компьютер способен хранить лишь конечное число отличающихся друг от друга цветов. Поэтому особую важность приобретает вопрос о том, сколько оттенков способен различить человеческий глаз: если "цветовое разрешение" формата
превышает разборчивость нашего зрения, цветовые переходы в изображении будут казаться нам идеально плавными, в обратном же случае неизбежны "ступеньки" или диффузия (стр. 245). В свою очередь, количество доступных цветов определяется тем, сколько бит информации приходится на каждый пиксел.
Так, формат GIF имеет от одного до восьми бит на пиксел и, следовательно, может отображать от 2 = 2 до 2 = 256 цветов. С использованием диффузии даже полноцветную фотографию можно ужать в 256 цветов так, что она будет выглядеть пристойно - но, к сожалению, не более чем "пристойно". Уровень качества, при котором глаз неспособен отличить компьютерную фотографию от настоящей, достигается только при не менее чем трех байтах на пиксел, что дает 2, или около 16 миллионов цветов.
Кроме растрового формата, на пути к зрителю графика проходит через еще один фильтр - компьютерный дисплей, также способный отображать лишь конечное количество цветов. Если сам компьютер не в состоянии отобразить больше 256 цветов (а такие системы еще составляют значительный процент всех подключенных к Интернету компьютеров), то от хранящегося в файле миллионного богатства оттенков проку будет мало. Цветовые возможности компьютера зависят от количества его видеопамяти, в которой хранится экранное изображение, и, как правило, один и тот же компьютер может работать в нескольких режимах - либо с большим разрешением (стр. 193), но меньшим количеством цветов, либо с меньшим разрешением, но более богатым цветом.
Видеопамять компьютера расположена не в мониторе, а на видеоплате в системном блоке; сам же монитор - устройство в основном аналоговое, а не цифровое, так что у него просто не может быть такой характеристики, как "количество отображаемых цветов". Тем не менее, в этой книге я буду пользоваться термином "256-цветные мониторы" для обозначения компьютеров, которые из–за аппаратных ограничений или установок ОС не могут отображать на своем мониторе больше 256 цветов.
Кроме идеального с точки зрения цветопередачи трехбайтового режима, который обычно называется "true color", у многих дисплеев есть промежуточный режим - "high color", отводящий по два байта (точнее, по 15 битов) на пиксел. На широких плавных цветовых переходах в режиме high color можно, приглядевшись, заметить "ступеньки", но для большинства практических нужд режим этот ничем не уступает true color.
Палитры. Выяснив, сколько памяти нужно для хранения цветовой информации, разберемся теперь с тем, как именно эта информация устроена. Так же как для однозначного указания положения точки в пространстве достаточно трех координат, любой цвет можно разложить на три составляющих, смешение которых даст цвет, ничем не отличающийся от исходного. В качестве "координат" в компьютере используются чистые красный, зеленый и синий цвета, расположенные на равном расстоянии друг от друга в цветовом круге (стр. 105).
Таким образом, объем памяти, выделенной на каждый пиксел, делится на три равные части, хранящие яркость красной, зеленой и синей составляющих цвета данного пиксела. В режиме high color на каждую составляющую приходится по 5 бит (что дает 32 градации яркости), а в true color - 1 байт (256 градаций). А поскольку известно, что режим true color превосходит цветовую разрешающую способность человеческого глаза, можно сделать вывод, что для качественной передачи монохромного изображения, изменяющегося только по одной цветовой координате (или, что то же самое, сохраняющего одно и то же соотношение трех составляющих), должно быть достаточно одного байта на пиксел.
По–иному устроены форматы с 256 цветами: вместо того чтобы делить и без того коротенькие байты на три части (тем более что восемь на три не делится), выгоднее хранить для каждого пиксела не его цвет, а номер его цвета в общей для всего файла таблице используемых цветов - палитре. Понятно, что количество цветов в этой таблице в любом случае не может превышать 256, но, поскольку цветовые значения в таблице задаются в трехбайтовом формате true color, цвета пикселов могут быть любыми, совсем не обязательно равномерно распределенными по цветовому континууму. В GIF-файлах палитра составляется на основе цветов, присутствовавших в исходном полноцветном изображении (это одно из ухищрений, позволяющих добиться приемлемого качества в ограниченной палитре), а у 256-цветных компьютерных дисплеев небольшая часть палитры фиксирована (она используется для отображения рамок окон, иконок и т. п.), а остаток отдается в распоряжение активной в данный момент программе, которая может переопределять эту часть палитры для своих нужд.
СИСТЕМЫ ПРЕДСТАВЛЕНИЯ ЦВЕТА
Самая распространенная и понятная компьютеру без перевода система RGB (от англ. "Red, Green, Blue", т. е. "красный, зеленый, синий") - не единственная. Если цвет компьютерного экрана изменяется от черного (отсутствие цвета) до белого (максимальная яркость всех трех составляющих), то на бумаге, наоборот, отсутствию цвета соответствует белый, а смешению максимального количества красок - черный (точнее, темно–бурый). Поэтому вместо системы RGB, называемой аддитивной ("складывающей"), при подготовке к печати изображение должно быть переведено в субтрактивную ("вычитающую") систему, использующую противоположные исходным цвета - противоположный красному голубой, противоположный зеленому пурпурный и противоположный синему желтый. Чтобы расширить диапазон цветовоспроизведения, к этим трем компонентам добавляется четвертый - черный, и вся система получает наименование CMYK ("Cyan, Magenta, Yellow, Black"; черный обозначается в этой аббревиатуре буквой К, чтобы не путать его с синим). Таким образом, для подготовленного к печати изображения в системе CMYK нужно 4 байта на пиксел, и далеко не все растровые форматы способны хранить такое изображение (чаще всего для этого используется формат TIFF).
В компьютерных графических программах применяется еще одна система представления цвета - система HSV (от англ. Hue - Saturation‑Value, тон–насыщенность–яркость; эту же систему называют иногда HSB, Hue - Saturation-Brightness, или HLS, Hue‑Lightness-Saturation). Эта система представляет собой абстракцию, моделирующую не физические свойства цвета, а его восприятие человеком. Растровые форматы не используют систему HSV для хранения изображений, но с ее помощью очень удобно подбирать цвет при практической работе (стр. 103).
Важно помнить, что цветовой охват системы CMYK существенно уже, чем у RGB или HSV, так как на бумаге в принципе невозможно воспроизвести некоторые особо яркие и насыщенные экранные цвета. Поэтому изображения, готовящиеся для печати на бумаге, с самого начала должны рассчитывать на узкий цветовой спектр CMYK
Программирование
За всем, что мы видим не только в окне своего броузера, но и вообще на экране компьютера, стоят программы - множество программ, передающих и преобразующих информацию на длинном пути от веб–сервера к вашему экрану. В то же время сами веб–страницы не относятся к категории программ - это не более чем "мертвые" данные, лишенный самостоятельности материал.
Существуют, однако, исключения из этого правила. Интересно отметить, что если до сих пор всегда программы порождали данные и оперировали ими, то в Интернете, наоборот, данные (веб–страницы) могут включать в себя и подчинять своим целям программные вставки. Эти "островки интерактивности" - JavaScript–сценарии, Java–апплеты и даже элементы HTML-форм - до сих пор не стали и, очевидно, никогда уже не станут несущим каркасом для информации Интернета. Однако во многих случаях программирование способно с выгодой "оживить" статические веб–страницы и реализовать те функции, без которых невозможно полноценное общение с компьютером, в какой бы среде оно ни происходило.
JavaScript
Разработанный в 1995 г. фирмой Netscape для версии 2.0 своего броузера язык JavaScript до сих пор остается вспомогательным, но в то же время абсолютно незаменимым инструментом, позволяющим загруженной в броузер странице динамически управлять своим содержимым, а заодно и собственно броузером. По своему набору функций этот язык близок к макроязыкам, которые с давних пор встраиваются в любую достаточно сложную программу или систему программ. В отличие от Java, JavaScript–сценарии не замыкается в изолированном апплете (стр. 69), а свободно переплетается и взаимодействует с HTML-разметкой страницы. Будучи тесно связан с HTML, язык этот имеет сходные недостатки и очень похожий по извилистости жизненный путь.
JavaScript из Netscape 2.0 не умел почти ничего, кроме как открывать и закрывать окна броузера (стр. 198), загружать в них документы, управлять фреймами и взаимодействовать с полями форм (например, проверяя правильность введенных в них значений). Сценарий, встроенный в документ с помощью тега SCRIPT, мог вставлять кусочки HTML-кода в то место документа, в котором расположен сам, но не мог ни считывать содержимое других частей документа, ни, самое главное, изменять текст или графику документа после его загрузки на компьютер пользователя.
В третьей версии броузера Netscape набор объектов, которыми мог манипулировать сценарий, был существенно, хотя и не кардинально расширен. Стали возможными такие трюки, как плавное изменение цвета фона при загрузке страницы или "живые" меню, каждый пункт которых изменяется, когда над ним проводишь мышью (эффект "перекатывания", стр.213). Эти усовершенствования, однако, лишь разбудили аппетит веб–дизайнеров, которых все меньше устраивал произвол авторов языка: почему такой–то атрибут такого–то тега сценарий может менять динамически, а другие атрибуты этого же тега или аналогичный атрибут другого тега - нет?
Динамический HTML
Недоделанность JavaScript пришлась как нельзя более на руку компании Microsoft, как раз в это время бросившей все усилия на завоевание рынка броузеров. Еще в третьей версии Microsoft Internet Explorer язык сценариев (который фирме пришлось назвать JScript, так как марка JavaScript принадлежала Netscape) отличался от своего конкурента разве что тем, что многочисленные ошибки и упущения в его реализации были расположены в непривычных местах. В четвертой версии, однако, фирма Microsoft решила уйти в отрыв.
Как известно маркетологам, одно из главных условий успеха любой новинки - запоминающееся название. Чтобы не раздражать пользователей путаницей между JScript и JavaScript, фирма Microsoft окрестила комбинацию, включающую расширенный язык сценариев, частичную поддержку CSS2 и несколько мелких усовершенствований, словосочетанием "динамический HTML", - развернув, по своему обыкновению, массированную рекламную кампанию, подающую его как средство от всех без исключения болезней "обычного" HTML. Netscape волей–неволей должна была ответить на вызов и, скрепя сердце, объявила о поддержке динамического HTML в четвертой версии своего броузера, - хотя его возможности имели довольно мало общего с набором технологий Microsoft.
Основную идею динамического HTML можно сформулировать очень просто: полный контроль языка сценариев над всеми без исключения элементами документа, параметрами их оформления и размещения (как подразумеваемыми в HTML, так и задаваемыми с помощью CSS) и даже над самим текстом страницы. Благодаря этому любой элемент HTML-документа сможет двигаться в произвольном направлении, как угодно изменять свое форматирование и буквально переписываться - как в ответ на действия пользователя, так и по собственной инициативе. В сочетании с абсолютным позиционированием элементов средствами CSS (стр. 241) это позволяет реализовать на веб–странице почти полноценный программный интерфейс с выпадающими многоуровневыми меню (стр. 214), перетаскиванием объектов мышью и т. п.
До сих пор, впрочем, динамический HTML особого распространения в Интернете не получил, и для этого есть объективные причины. Главную роль играет, конечно, несовместимость броузеров–конкурентов, из–за которой очень трудно, а в некоторых случаях и невозможно создать одну версию динамической страницы, которая сохраняла бы работоспособность в обоих броузерах. Сказывается также конкуренция со стороны формата Shockwave Flash, в котором можно реализовать не менее интерактивные эффекты, чем в динамическом HTML, который притом полностью застрахован от несовместимостей (существует только один, разработанный самой фирмой Macromedia подключаемый модуль для просмотра Flash–вставок) и имеет стандартную специализированную среду разработки. Конечно, с доступностью информации в неграфических средах (стр. 34) у Flash дела обстоят куда хуже, чем у динамического HTML, но графические дизайнеры, к сожалению, редко задумываются о таких вещах.
Как всегда с опозданием, свое слово сказал и W3C. Разработанный им стандарт "объектной модели документа" (Document Object Model, DOM) подробно описывает взаимодействие встроенного в веб–страницу сценария с элементами документа, перечисляя все возможные действия, свойства и взаимозависимости для объектов, на которые распадается содержимое документа с точки зрения сценария. Пока достаточно близко к этим предписаниям подошел только броузер Microsoft.
Спецификация DOM оперирует достаточно общими принципами и потому не зависит ни от конкретного языка разметки документа, ни от языка сценариев. В то же время стандартизации не избежал и сам JavaScript; его "официальная", в общественном пользовании находящаяся версия называется ECMAScript (стандарт этот был создан не W3C, а европейской промышленной ассоциацией ЕСМА). Интересно следить за тем, как компании, всегда стремившиеся любыми средствами добиться преимущества над конкурентами и по возможности монополизировать свой сектор рынка, начинают уступать инициативу независимым организациям - стандартизаторам (состоящим, впрочем, из представителей тех же самых фирм–конкурентов), постепенно осознавая важность единых и обязательных для всех "правил игры".
МОДУЛЬНЫЕ ТЕХНОЛОГИИ
Недостатки JavaScript, как это обычно бывает, продолжают его достоинства. Тесная связь с HTML позволяет (по крайней мере, в идеале) свободно манипулировать материалом страницы, но сильно ограничивает репертуар доступных этому языку "общекомпьютерных" функций, которые бы позволили реализовать на веб–странице фрагменты по–настоящему интерактивного интерфейса.
И наоборот, почти никаких ограничений нет у "обычных" компьютерных языков программирования, с помощью которых создается большинство компьютерных приложений (включая, кстати, и сам броузер). Поэтому первой в голову приходит идея включить в состав веб–страницы готовую к выполнению программу точно так же, как к ней подключаются хранящиеся во внешних файлах изображения. В окне броузера этому объекту будет соответствовать прямоугольная область определенных размеров, внутри которой управление выводом на экран и взаимодействие с пользователем полностью возьмет на себя подключенная программа. От обычного, запущенного на том же компьютере приложения такая "встроенная" программа отличалась бы только отсутствием собственного окна и сохранением своего положения относительно других элементов страницы (в частности, рабочую область этой программы можно будет промотать вверх или вниз вместе с прочим содержимым окна броузера).
К сожалению, существует сразу несколько препятствий к реализации этой простой схемы.
• Исполняемый файл программы, скомпилированной для одной компьютерной платформы (например, для Windows 95), не будет работать на другом типе компьютеров (например, на Макинтоше) или в другой операционной системе (например, в DOS). Веб–страница не имеет возможности выяснить, в какую операционную систему она попала на компьютере пользователя, так что выбор нужной версии программы из нескольких имеющихся отпадает. Это ограничение можно обойти, пересылая с сервера не готовый к исполнению двоичный код, а исходный текст программы на языке программирования, с тем чтобы компьютер пользователя самостоятельно превращал его в понятный ему код. Такое решение, однако, имеет свои недостатки: потерю значительной части быстродействия, незастрахованность от ошибок при компиляции и необходимость устанавливать на компьютер наряду с броузером еще и интерпретатор языка программирования (который будет тем объемистее, чем больше возможностей предоставляет данный язык).