Текст книги "Веб-дизайн"
Автор книги: Дмитрий Кирсанов
Жанр:
Интернет
сообщить о нарушении
Текущая страница: 5 (всего у книги 29 страниц) [доступный отрывок для чтения: 11 страниц]
Растровое (bitmap) представление графики можно рассматривать как «вырожденную» разновидность векторного, в которой допустим только один вид объектов: расположенные в прямоугольной решетке разноцветные квадратики, называемые пикселами. Однако если на векторном изображении мы видим те объекты, из которых оно состоит, то в растре вместо отдельных пикселов мы воспринимаем целостную картину, в которую пикселы складываются в нашем сознании. Главное преимущество растра состоит в его абсолютно свободе: пиксел изображения может быть любым – пусть его изменения ограничены только одной координатой (цветом), он не обязан подчиняться каким–то математическим формулам или «помнить» об очертании того объекта в изображении, которому оно принадлежит.
Разница между вектором и растром напоминает отличие студийной записи от «живого» концерта. Студийная мастер–копия сохраняет на отдельных дорожках партию каждого инструмента; как и векторное изображение, ее можно «пересводить», сколько угодно преобразуя, сдвигая, выбрасывая отдельные звуковые слои и добавляя новые. Концертная же запись и растровая картинка если и поддаются обработке и «приглаживанию», то лишь с помощью хитроумных фильтров. За эту негибкость вы получаете взамен в музыке – характерную экспрессию и «живую» фактуру звука, а в компьютерном растре – богатство текстур и некоторые принципиально недостижимые в векторе эффекты.
Интересное следствие этой концептуальной простоты – относительно небольшое количество используемых растровых форматов. Сейчас в этой области уже вряд ли можно придумать что–нибудь принципиально новое. Большинство растровых форматов, которые, как и векторные, начинали свою историю в качестве фирменных форматов той или иной программы, давно уже зажили собственной жизнью и кажутся теперь одинаково «родными» всем существующим растровым редакторам (а следовательно, нет никакой нужды выходить за пределы двух–трех общеупотребительных форматов). Из векторных форматов настолько же «обобществленным» сумел стать разве что PostScript, но и для него не редкость ситуация, когда записанный в одной программе PostScript–файл отказывается считываться в другой, – что невозможно себе представить для формата растрового.
На все четыре стороны. Экзотическая разновидность растровой графики – панорамные форматы, хранящие не двумерную картинку, а полный круговой обзор из некоторой точки, «склеенный» из нескольких снимков широкоугольным фотоаппаратом. Для просмотра такой панорамы нужно либо распечатать и свернуть ее в кольцо, либо (что, конечно, гораздо удобнее) «прокручивать» специальной программой, компенсирующей искажения, возникающие при проецировании кругового изображения на плоский экран. Некоторые из этих форматов дают не только панорамный, но и сферический обзор, включающий вид «в зенит» и «под ноги». Такими панорамами пользуется, к примеру, фирма Toyota для показа потенциальным клиентам интерьера своих автомобилей.
Цвета. Самые важные для веб–дизайнера форматы – GIF и JPEG – подробно рассматриваются в гл. IV (стр. 252), поэтому здесь вместо форматов растровой графики мы обсудим цветовые ограничения этих форматов и компьютерных устройств вывода (ведь и компьютерный дисплей, и принтер могут отображать только растр, пусть и генерируемый программой «на лету» из векторного представления). Хотя цветовой спектр есть непрерывный континуум, компьютер способен хранить лишь конечное число отличающихся друг от друга цветов. Поэтому особую важность приобретает вопрос о том, сколько оттенков способен различить человеческий глаз: если «цветовое разрешение» формата
превышает разборчивость нашего зрения, цветовые переходы в изображении будут казаться нам идеально плавными, в обратном же случае неизбежны «ступеньки» или диффузия (стр. 245). В свою очередь, количество доступных цветов определяется тем, сколько бит информации приходится на каждый пиксел.
Так, формат GIF имеет от одного до восьми бит на пиксел и, следовательно, может отображать от 21 = 2 до 28 = 256 цветов. С использованием диффузии даже полноцветную фотографию можно ужать в 256 цветов так, что она будет выглядеть пристойно – но, к сожалению, не более чем «пристойно». Уровень качества, при котором глаз неспособен отличить компьютерную фотографию от настоящей, достигается только при не менее чем трех байтах на пиксел, что дает 224, или около 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-форм – до сих пор не стали и, очевидно, никогда уже не станут несущим каркасом для информации Интернета. Однако во многих случаях программирование способно с выгодой «оживить» статические веб–страницы и реализовать те функции, без которых невозможно полноценное общение с компьютером, в какой бы среде оно ни происходило.
Разработанный в 1995 г. фирмой Netscape для версии 2.0 своего броузера язык JavaScript до сих пор остается вспомогательным, но в то же время абсолютно незаменимым инструментом, позволяющим загруженной в броузер странице динамически управлять своим содержимым, а заодно и собственно броузером. По своему набору функций этот язык близок к макроязыкам, которые с давних пор встраиваются в любую достаточно сложную программу или систему программ. В отличие от Java, JavaScript–сценарии не замыкается в изолированном апплете (стр. 69), а свободно переплетается и взаимодействует с HTML-разметкой страницы. Будучи тесно связан с HTML, язык этот имеет сходные недостатки и очень похожий по извилистости жизненный путь.
JavaScript из Netscape 2.0 не умел почти ничего, кроме как открывать и закрывать окна броузера (стр. 198), загружать в них документы, управлять фреймами и взаимодействовать с полями форм (например, проверяя правильность введенных в них значений). Сценарий, встроенный в документ с помощью тега SCRIPT, мог вставлять кусочки HTML-кода в то место документа, в котором расположен сам, но не мог ни считывать содержимое других частей документа, ни, самое главное, изменять текст или графику документа после его загрузки на компьютер пользователя.
В третьей версии броузера Netscape набор объектов, которыми мог манипулировать сценарий, был существенно, хотя и не кардинально расширен. Стали возможными такие трюки, как плавное изменение цвета фона при загрузке страницы или «живые» меню, каждый пункт которых изменяется, когда над ним проводишь мышью (эффект «перекатывания», стр.213). Эти усовершенствования, однако, лишь разбудили аппетит веб–дизайнеров, которых все меньше устраивал произвол авторов языка: почему такой–то атрибут такого–то тега сценарий может менять динамически, а другие атрибуты этого же тега или аналогичный атрибут другого тега – нет?
Недоделанность 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). Веб–страница не имеет возможности выяснить, в какую операционную систему она попала на компьютере пользователя, так что выбор нужной версии программы из нескольких имеющихся отпадает. Это ограничение можно обойти, пересылая с сервера не готовый к исполнению двоичный код, а исходный текст программы на языке программирования, с тем чтобы компьютер пользователя самостоятельно превращал его в понятный ему код. Такое решение, однако, имеет свои недостатки: потерю значительной части быстродействия, незастрахованность от ошибок при компиляции и необходимость устанавливать на компьютер наряду с броузером еще и интерпретатор языка программирования (который будет тем объемистее, чем больше возможностей предоставляет данный язык).
• Давать любому желающему возможность выполнять на вашем компьютере свои программы – более чем рискованная затея. В отличие oTJavaScript–сценария, в котором соответствующих средств нет и не может быть в принципе, программа на обычном языке программирования способна заразить вас вирусом, попортить данные на вашем диске или уворовать конфиденциальную информацию.
• Наконец, довольно трудно обеспечить небольшой объем файла с программой, приемлемый для перекачивания по сети. Если графику всегда можно попытаться оптимизировать, уменьшив ее размер за счет некоторой потери качества, то объем файла программы почти не поддается изменению без существенного усечения ее функций.
На данный момент существуют три технологии встраивания программных объектов в документ. Все они так или иначе пытаются справиться с перечисленными ограничениями.
• Технология подключаемых модулей (plug–in modules) подразумевает наличие двух компонентов: общего для всех объектов данного типа модуля, который достаточно перекачать из сети один раз и установить на компьютере пользователя как обычную программу, и подключаемых к HTML-странице объектов. Последние интерпретируются и выводятся на отведенное им место в пределах страницы соответствующим модулем, запуск которого (как правило, в фоновом режиме, т. е. без создания собственного окна) берет на себя броузер.
Объекты могут состоять исключительно из данных – например, звукозаписи или изображения в особом формате, обрабатываемом только этим модулем. Если же они включают в себя и программный код, то объем его, как правило, невелик, так как самая трудоемкая часть доступных объекту функций реализована внутри основного модуля. Это позволяет добиться небольших объемов пересылаемых по сети данных (разумеется, «небольшими» они будут только после того, как пользователь перекачает себе сам модуль, объем которого редко опускается ниже мегабайта).
Проблема безопасности при использовании модулей обычно не стоит: очень немногие типы объектов хотя бы в принципе способны навредить компьютеру, на котором они выполняются, и в любом случае от них можно защититься, просто не устанавливая себе соответствующий модуль (к счастью, установить на компьютер новый модуль без ведома пользователя невозможно). Что же касается третьего ограничения – межплатформенной несовместимости, – здесь никакого облегчения нет и не предвидится: разработчикам модуля, как и любой другой программы, приходится создавать отдельные его версии для каждой операционной системы (к счастью, это относится только к самому модулю, а не к встраиваемым в веб–страницы объектам).
● Апплеты на языке Java, при всех своих особенностях, имеют немало пунктов сходства с подключаемыми модулями. Основную часть выполняемой апплетом работы берет на себя не передаваемый по сети объект минимального объема, а большая программная система, называемая «виртуальной машиной Java» и устанавливаемая на компьютер пользователя только раз (в отличие от подключаемого модуля, пользователю не приходится перекачивать ее из сети, так как оба визуальных броузера поставляются уже со встроенными виртуальными машинами). Подключаемый к веб–странице объект содержит так называемые «байтовые коды» – нечто среднее между исходным текстом и скомпилированным двоичным файлом программы, компромисс между идеалами быстродействия и переносимости.
Набор функций у апплетов ограничен даже сильнее, чем у подключаемых модулей. Хотя Java и относится к полнофункциональным языкам программирования, в апплетах этот язык имеет дело не с реальным компьютером, а с внутренностями виртуальной машины, надежно ограждающей компьютер от любых продуктов жизнедеятельности апплета. Конечно, везде, где есть защита, можно постараться ее обойти, и поиск «дыр» в виртуальных машинах доставляет и долго еще будет доставлять приятные минуты компьютерным взломщикам. И все же в целом Java–апплеты можно считать достаточно безопасной технологией.
К сожалению, виртуальная машина у каждого из броузеров своя, и, несмотря на декларируемую совместимость между ними, апплет, который работает на одной из этих машин, иногда может отказаться работать на другой. Кроме того, как и любая многоуровневая система, Java–апплеты в сравнении с обычными программами сильно проигрывают в быстродействии. Наконец, необходимость «настоящего» программирования для изготовления апплетов обуславливает трудоемкость этого процесса. С другой стороны, наличие готовой виртуальной машины почти на каждом компьютере и, опять–таки, богатые возможности полнофункционального языка программирования открывают перед этой технологией определенные перспективы. Так, уже упоминавшаяся технология Macromedia Flash (стр. 58) позволяет сохранять Flash – «мультики» в виде Java–апплетов, для работы которых не нужен установленный на компьютере Flash–модуль.
● Одно время Java–апплетам пытались составить конкуренцию так называемые «компоненты ActiveX» – технология фирмы Microsoft, ограниченная только броузером Internet Explorer и только платформой Windows. Это наделавшее поначалу много шума, но быстро забытое нововведение интересно отсутствием какой бы то ни было «прокладки» между программным модулем (по сути, обычным исполняемым файлом в формате Windows) и операционной системой. Для решения проблемы безопасности была разработана система «электронных подписей» с регистрацией законопослушных авторов ActiveX-апплетов у спонсируемых Microsoft «цифровых нотариусов». Неудивительно, что эта громоздкая система оказалась нежизнеспособной. В настоящее время изредка используются лишь ActiveX-объекты самой фирмы Microsoft, поставляемые вместе с ее броузерами.
В Windows–версии броузера Internet Explorer (начиная с версии 4) технология ActiveX является не одним из усовершенствований, а буквально фундаментом всей программы. При запуске броузера управление получает контейнер, сразу же вызывающий ActiveX-модуль, в котором, собственно, и заключены все функции броузера. Любой программист может, таким образом, без труда встроить в свою программу самый настоящий броузер, написав всего лишь небольшую функцию для вызова этого модуля и обмена данными с ним. Отдельные функциональные блоки броузера – виртуальная машина Java, интерпретатор HTML и даже сам блок взаимодействия с органами управления ActiveX – реализованы в виде ActiveX-модулей.
