Arkady wrote:
>
> >> с каких это пор изображение на экране приобрело векторную
> природу?
> Так что же удерживает WEB-кудесников от «перегона»
> создаваемых страниц целиком в растр? — ведь буковки тоже
> можно растрировать
))
Замечание справедливое. Буковки, однако, частенько растрируют - когда набраны шрифтом, заведомо или с большой вероятностью отсутствующие в системе клиента. Насколько мне известно, возможность подгрузки необходимого шрифта с сервера (через CSS - @font-face) используется мало или вообще не используется. Кроме того, наличие растровых объектов снижает гибкость динамического форматирования страниц. о скорости загрузки растра и говорить не стоит.
> Речь идет о том, что WEB-кудесник делает работу GDI по преобразованию изображения в набор пикселей — или я не прав? и в результате прямая между двумя точками передается в браузер не в виде двух пар значений координат, а виде растрового файла.
Ты прав, Аркадий, я погорячился насчет "природы изображения на экране". хотя, все-таки, что было сначала - курица или яйцо? ))) первична математика, которая описывает вектор и переменные, которыми она управляется, - или растровый формат, в котором мы получаем представление о векторе в виде точечного изображения на экране? конечно, математика. и, конечно, вектор куда более гибок в управлении. но пользователь не в состоянии воспринимать изображение в виде формул и координат. ему надо видеть результат - графическое представление. а вот вопрос о том, почему веб-спец берет на себя задачу браузера (или, если угодно, вообще программы или программного интерфеса) по преобразованию гибкого и компактного векторного изображения в негибкое и тяжелое растровое - это скорее вопрос сегодняшних возможностей программ. (конечно, если не брать в расчет изначально растровые элементы дизайна страниц - они вне вопроса).
к примеру: большинство страниц сегодня строится на основе таблиц. они для веб-верстки играют одновременно роль несущей конструкции и модульной сетки. особенность _пустой_ ячейки такой таблицы такова, что она стремиться к наименьшей ширине и высоте, которая допускается содержимым в том же столбце/строке. чтобы этого избежать, веб-кодер ставить должен поставить хотя бы в одну ячейку растровую "распорку". часто это изображение - элемент дизайна (или slice, кусок такого изображения), но иногда эта распорка - просто "пустышка" - прозрачный или одноцветный gif с указанием размера, который он должен занять. пример (может, не самый явный) - зеленая плашка с текстом (растровым!) "Форумы" в верхней части этой страницы. К чему я пытаюсь все это сказать: растр - в некоторых случаях - неизбежность из-за несовершенства программ или их интерпретаторов. По той же причине градиентная заливка делается растровой (хотя это и можно обойти, сделав последовательность ячеек или других элементов с плавно меняющимися заливками). аналогичная ситуация с тенями и всякими размытиями (здесь Shlyapa прав, отчасти это реализуемо через различные фильтры, применимые к объектам и тексту: glow, mask, shadow, blur..., но это уже не язык гипертекстовой разметки как таковой, это его развитие в виде скриптов и языков программирования). с развитием веб-конструирования в эту сторону, возможно, содержимое страниц будет становиться все более "векторным", а одновременно гибким и динамичным. происходит же подобное в том же 10-м иллюстраторе, где чисто растровые эффекты незаметно стали почти родной частью векторных и управляются почти теми же инструментами (помню, какой восторг я испытал, впервые ковыряя gradient mesh)))).
не буду дальше об этом рассуждать. я не дока в веб-кодировании. я любитель, почти профан. хотя тема интересная и вообще-то не чужая для форума по векторной программе.
> Причем, просматривая структурированный документ [HTML, XML и
> т.п. ] и натыкаясь на элемент <image/> (или <img/> — не в
> названии дело) я никоим образом не могу получить (и
> обработать!) информацию об самом изображении, кроме как о его
> размерах, цветности — если об этом позаботился создатель
> документа.
А когда ты делаешь полиграфический дизайн, ты разве заботишься о том, чтобы клиент имел такую возможность?
а вообще, сейчас активно разрабатываются программы, которые должны распознавать (!!) содержимое (сюжет) изображений, тему текста, записанного в MP3 (например, лекций, книг), стиля музыки и т.п.
> Кстати, уважаемый Arhip, видимо, не застал ВЕКТОРНЫХ
> мониторов, в которых изображение рисовалось от вершины линии
> к вершине — наподобие перьевых плоттеров
))
Да, припоминаю их с трудом.)) но об этом я уже высказался выше. ты прав.