Comments 97
Ещё бы неплохо написать хотя бы пару слов про поддержку браузерами
caniuse.com/#search=svg
caniuse.com/#search=svg
Случаем не подскажите, как Raphaël произносится? Как Рафаёл? Рафаэль?
В английском нет ë.
А, например, во французском — есть: там ë читается как обычная e, независимо от предшествующей буквы. То есть, например, в словах Noël, Moët произношение сочетания oë можно приблизительно передать русскими буквами оэ. Возьмите для сравнения словосочетание chef d'oeuvre — вторая его часть произносится (приблизительно) как дёвр.
С Рафаэлем — та же фигня. Без точек был бы Рафэль. Во французской википедии есть даже статья об этом имени, там оно пишется аналогично:
А, например, во французском — есть: там ë читается как обычная e, независимо от предшествующей буквы. То есть, например, в словах Noël, Moët произношение сочетания oë можно приблизительно передать русскими буквами оэ. Возьмите для сравнения словосочетание chef d'oeuvre — вторая его часть произносится (приблизительно) как дёвр.
С Рафаэлем — та же фигня. Без точек был бы Рафэль. Во французской википедии есть даже статья об этом имени, там оно пишется аналогично:
Raphaël est un prénom masculin.
«Рукипедия» не совсем тщательно написана — Diaeresis_(diacritic) и Umlaut. Умлаут — это, буквально, «перезвучка» звука, трема — это обозначение на письме, в т.ч. и обозначение умлаута в германских языках.
В английском и французском букв с двумя точками, строго говоря, нет. Но иногда две точки над второй гласной применяются. Они служат, чтобы «разбить» диграф и заставить каждую букву читаться по своим собственным правилам.
Предположим, по правилам буква «o» читается как звук «о», буква «e» читается как звук «э», а сочетание «oe» читается как русская «ё». Тогда «oë» будет предписывать чтение не как «ё», а по отдельности: «оэ». Что и продемонстрировал коллега shoorick в примерах про Noël и Moët.
Предположим, по правилам буква «o» читается как звук «о», буква «e» читается как звук «э», а сочетание «oe» читается как русская «ё». Тогда «oë» будет предписывать чтение не как «ё», а по отдельности: «оэ». Что и продемонстрировал коллега shoorick в примерах про Noël и Moët.
Боже, зачем Вы изощряетесь, когда на сайте продукта во втором же абзаце указано произношение: ['ræfeɪəl]? По правилам англо-русской практической транскрипции по-русски это пишется так: «Рэ́фейэл».
Raphaël назван в честь известного художника ренесанса и произносится Рафаэль. Диарезиз в название добавлен для англоязычных читателей, чтобы они не читали “ae” как один звук.
Вообще не стоит заморачиваться, как произносит большинство, так и правильно. Мало кто поймёт у нас что «найки» и «эдоби» это на самом деле Nike и Adobe. ;)
Вообще не стоит заморачиваться, как произносит большинство, так и правильно. Мало кто поймёт у нас что «найки» и «эдоби» это на самом деле Nike и Adobe. ;)
А как в SVG нарисовать кривую Безье?
Хороший формат. До появления Рафаэль нужно было использовать адобовский плагин, который позволял работать чуть ли на в 5-м IE…
Вы пробовали делать сложные анимации с использованием svg?
Даже несложная svg анимация, ощутимо грузит firefox. Причем как CSS Transition/Animate, так и с помощью SMIL или javascript.
Глюки при работе с сложными svg в opera. Проблема рендеринга. Встречается при определенных обстоятельствах, но подпортит нервы неплохо.
Проблемы с фильтрами. Плохо работает гауссово размытие в chromium ниже 20-ой версии. В firefox неплохо, за исключением ужасной прожорливости и опять же отсутствие поддержки некоторых параметров в фильтрах.
Это все с анимациями связанными с svg.
Со SMIL все не так радужно (не везде работают правильно правила связанные с begin="(#).end + (n) s").
Причем вопросы с chromium и opera легко решаемы(за исключениями), а вот проблемы с firefox — это ужасная беда. Причем в багтрекере Фокса часто ссылаются на svg team, типа они виноваты.
Сам по себе SVG отличный формат. И для работы с простыми композициями пойдет. Но для создания и работы со сложной композицией, с анимациями, текущие реализации SVG — проблемны(причем особенно в Firefox).
Даже несложная svg анимация, ощутимо грузит firefox. Причем как CSS Transition/Animate, так и с помощью SMIL или javascript.
Глюки при работе с сложными svg в opera. Проблема рендеринга. Встречается при определенных обстоятельствах, но подпортит нервы неплохо.
Проблемы с фильтрами. Плохо работает гауссово размытие в chromium ниже 20-ой версии. В firefox неплохо, за исключением ужасной прожорливости и опять же отсутствие поддержки некоторых параметров в фильтрах.
Это все с анимациями связанными с svg.
Со SMIL все не так радужно (не везде работают правильно правила связанные с begin="(#).end + (n) s").
Причем вопросы с chromium и opera легко решаемы(за исключениями), а вот проблемы с firefox — это ужасная беда. Причем в багтрекере Фокса часто ссылаются на svg team, типа они виноваты.
Сам по себе SVG отличный формат. И для работы с простыми композициями пойдет. Но для создания и работы со сложной композицией, с анимациями, текущие реализации SVG — проблемны(причем особенно в Firefox).
Да все в порядке с анимацией в SVG. Вот не очень простая анимация на Halloween нигде вроде особенно не тормозит.
Только что проверил.
Разница работы:
Chromium. Полет нормальный.
Firefox:
1)В конце домик не загорается.
2)Не хило грузит, даже после проигрывания анимации.
3)Анимация не имеет много мелких и сложных элементов.
4)Нет сложных трансформаций, в том числе групп.
Оперу еще не смотрел.
Всё проверено сейчас на Ubuntu и Vista.
Да кстати, в анимации нигде нет фильтров
Разница работы:
Chromium. Полет нормальный.
Firefox:
1)В конце домик не загорается.
2)Не хило грузит, даже после проигрывания анимации.
3)Анимация не имеет много мелких и сложных элементов.
4)Нет сложных трансформаций, в том числе групп.
Оперу еще не смотрел.
Всё проверено сейчас на Ubuntu и Vista.
Да кстати, в анимации нигде нет фильтров
Это как раз простая, нет трансформаций и масштабирования объектов!
ФФ 16.0, вин хп: лагает ощутимо.
Мне вот очень понравилась фишка прямого включения SVG-кода в HTML-страницу, внутри элемента SVG. Примерно так:
И после этого хоть что с элементами делай — они включены в DOM tree, можно их дёргать jQuery и тому подобное. И гиперссылки можно навешивать на элементы.
<!DOCTYPE html>
<html xmlns="http://www.w3.org/1999/html">
<head><meta http-equiv="Content-Type" content="text/html; charset=utf-8"></head>
<body>
Над картинкой<br>
<svg xmlns="http://www.w3.org/2000/svg" version="1.1" baseProfile="full" width="560px" height="540px">
<g transform="scale(0.5)">
<svg x="574" y="526" fill="red" stroke="black" stroke-width="1" stroke-linejoin="round">
<a xlink:href="somewhere-else">
<path d="M 15,45 l 0,52 a 228,228 0 0,0 114,-55 l -37,-40 a 176,176 0 0,1 -77,43 z"></path>
</a>
<path d="M 15,120 l 0,116 a 360,360 0 0,0 211,-96 l -78,-79 a 251,251 0 0,1 -133,59 z"></path>
<path d="M 78,269 l 53,218 a 629,629 0 0,0 109,-36 l -7,-13 a 611,611 0 0,0 154,-103 l -145,-146 a 408,408 0 0,1 -164,80 z"></path>
<path d="M 319,242 l 41,43 l 25,-26 l -39,-39 z"></path>
</svg>
</svg><br>
Под картинкой
</body></html>
И после этого хоть что с элементами делай — они включены в DOM tree, можно их дёргать jQuery и тому подобное. И гиперссылки можно навешивать на элементы.
А какие браузеры поддерживают такое включение?
По данным Microsoft, все: samples.msdn.microsoft.com/ietestcenter/#html5ForeignContent
Под Android, похоже, никакие…
А мне очень нравится фишка включения HTML в SVG, получается примерно
так

Действительно, очень удобно.
И с javascript работать просто, и стили для svg-элементов можно в основной css-файл помещать.
Пример — мой редактор html-карт habrahabr.ru/post/152731/
И с javascript работать просто, и стили для svg-элементов можно в основной css-файл помещать.
Пример — мой редактор html-карт habrahabr.ru/post/152731/
Если уж взялись разъяснять основы, то ссылка на спецификацию была бы не лишней.
Не только; ещё через собственно
Internet Explorer 8 и ниже вполне себе поддерживают SVG через сторонние плагины, например эдоубиевский.
Вставлять на страницу SVG можно с помощью embed, iframe и object
Не только; ещё через собственно
svg
(инлайново), img
, background-image
, favicon
и font-face
.SVG поддерживается почти всеми современными браузерами за исключением Internet Explorer 8 и ниже.
Internet Explorer 8 и ниже вполне себе поддерживают SVG через сторонние плагины, например эдоубиевский.
Во-первых, эдоубиевский плагин — не единственный, хотя не знаю, какова судьба остальных. Во-вторых, зачем ему разработка и поддержка, если он нужен только для старых IE? В-третьих, тот, кто до сих пор имеет старый IE, весьма вероятно имеет и плагины, которые там требовались. В-четвёртых, если вдруг не имеет, можно выдать предложение поставить, о чём я писал два года назад, но по нынешним временам, вероятно, лучше предложить обновить браузер.
Хочу поговорить про векторную графику в интернете.
Apple перевела все свои устройства на дисплеи высокого разрешения. Есть разные мнения на тему «зачем оно мне надо», но суть не в этом. Что бы мы об этом ни думали, через пару лет все производители сделают то же самое, поскольку технология существует и маркетологи не упустят шанс навариться на ней.
Множество крупных сайтов уже сейчас в какой-то мере поддерживают экраны с высокой плотностью точек, но они делают это довольно тупо: для каждого элемента с изображением готовят два файла — обычного разрешения и удвоенного (иногда достаточно кратности 1.5). Сейчас не учитывается один важный момент: при высокой плотности точек можно интерполировать все подряд и это будет выглядеть хорошо. То есть, вам не нужно делать картинки 100%, можно выбрать любой удобный размер, который всех устроит. А пользователь будет активнее пользоваться масштабированием в браузере. Причем, масштабирование будет плавным (как в Safari), а не ступеньками (как в Chrome). Не будет такого, что сайт сверстан под 1024 или какое-то другое разрешение.
И для обеспечения работы таких сайтов очень пригодится векторная графика. Конечно, основная масса контента останется растровой, но в оформлении и в инфографике удобно будет использовать вектор.
Apple перевела все свои устройства на дисплеи высокого разрешения. Есть разные мнения на тему «зачем оно мне надо», но суть не в этом. Что бы мы об этом ни думали, через пару лет все производители сделают то же самое, поскольку технология существует и маркетологи не упустят шанс навариться на ней.
Множество крупных сайтов уже сейчас в какой-то мере поддерживают экраны с высокой плотностью точек, но они делают это довольно тупо: для каждого элемента с изображением готовят два файла — обычного разрешения и удвоенного (иногда достаточно кратности 1.5). Сейчас не учитывается один важный момент: при высокой плотности точек можно интерполировать все подряд и это будет выглядеть хорошо. То есть, вам не нужно делать картинки 100%, можно выбрать любой удобный размер, который всех устроит. А пользователь будет активнее пользоваться масштабированием в браузере. Причем, масштабирование будет плавным (как в Safari), а не ступеньками (как в Chrome). Не будет такого, что сайт сверстан под 1024 или какое-то другое разрешение.
И для обеспечения работы таких сайтов очень пригодится векторная графика. Конечно, основная масса контента останется растровой, но в оформлении и в инфографике удобно будет использовать вектор.
Старые браузеры и с PNG имеют некоторые проблемы. Тогда уж GIF.
Старые браузеры бывают только у Microsoft, это раз.
Через два-три года не будет даже IE8, это два. IE9 уже обогнал IE8 в рунете.
Через два-три года не будет даже IE8, это два. IE9 уже обогнал IE8 в рунете.
А что Firefox 3.6? Мы под него разработку ведём, и используем при этом SVG.
Для меня как для инженера минусом является то что нет возможности сохранить в какой нибудь чертежный формат. Пусть хотябы в открытый DXF. Это уже открыло бы большие перспективы для разработчиков. И тогда наконец для нас, инженеров, появились бы адекватные сервисы контроля версий, подобные GIT, SVN и т.д. для программистов.
Хотя… может быть есть такая надстройка? Никому не попадалась?
Хотя… может быть есть такая надстройка? Никому не попадалась?
Можно. Можно даже по кривой отображать текст.
Примеры не буду писать, наглядно можно увидеть это в InkScape.
Примеры не буду писать, наглядно можно увидеть это в InkScape.
По кривой как раз сейчас не интересует. Интересует именно форматированный вывод. Если можно, поделитесь, пожалуйста, примером.
По спецификации W3C
Но это SVG версии 1.2 который конечно же полностью не поддерживается браузерами.
Поэтому пока только размещение текста по кривой(которая может быть прямой, внутри прямоугольника), с изменением параметра у тега textPath startOffset="(значение)"
Так что в SVG можно, но браузер это проигнорирует.
Но это SVG версии 1.2 который конечно же полностью не поддерживается браузерами.
Поэтому пока только размещение текста по кривой(которая может быть прямой, внутри прямоугольника), с изменением параметра у тега textPath startOffset="(значение)"
Так что в SVG можно, но браузер это проигнорирует.
Все предельно просто:
<foreignObject>
<div xmlns="http://www.w3.org/1999/xhtml">
<p>My <strong>text</strong></p>
</div>
</foreignObject>
Боюсь там не все красиво как кажется
баги webkit
баги webkit
Малый размер: объекты SVG весят намного меньше растровых изображений.
неправда ваша. бывает и наоборот. особенно на 24" можно запросто достичь :)
поясните, пожалуйста, как размер экрана влияет на объём svg-кода?
Ну если внутрь SVG присобачивать растр, как этим грешит Corel, то конечно объем раздуется =)
Рассмотрим 1920х1080 например. Растр такого разрешения займет 49766400 самых глубоких бит. Однако сохраненный в PNG файл окажется всего-лишь 165Кб. SVG такого размера представить, да и сгенерить (исключительно вектор, заметьте), совсем не сложно. Инфа 100%. Существует правда SVGZ, однако не принципиально.
Что касаемо диагонали отображающего устройства, то не станем же мы пихать в 4" андроида какого-нибудь то же самое, что хорошо разместится на 24". да?
Что касаемо диагонали отображающего устройства, то не станем же мы пихать в 4" андроида какого-нибудь то же самое, что хорошо разместится на 24". да?
<svg xmlns="http://www.w3.org/2000/svg" version="1.1" baseProfile="full"><path d="M 78,269 l 53,218 a 629,629 0 0,0 109,-36 l -7,-13 a 611,611 0 0,0 154,-103 l -145,-146 a 408,408 0 0,1 -164,80 z" fill="red" stroke="black" stroke-width="1" stroke-linejoin="round"></path></svg>
Этот SVG займёт ровно 307 байт как для андроида с экраном 4", так и для устройства с экраном 24".
Ещё раз, поясните мне, как вообще тут что-то может зависеть от размера экрана?
Если есть огромное количество объектов в SVG, то спору нет — он может оказаться в разы больше.
PNG как таковой сжатый формат(который сжимается по определенным алгоритмам), поэтому все таки нормально сравнивать именно с SVGZ.
PNG тоже не любое изображение может оптимально сжать. Особенно когда значение RGBA практически каждого пикселя уникально.
Но тут для проекта надо подбирать, где SVG, где PNG, где JPEG, а где и старый GIF подойдет.
А вот насчет разрешения… Вон тут недавно был топик про retina, Торвальдса и пр.. Так что черт знает, что там с разрешениями сейчас. Слишком большой разброс поддерживаемых разрешений теперь.
PNG как таковой сжатый формат(который сжимается по определенным алгоритмам), поэтому все таки нормально сравнивать именно с SVGZ.
PNG тоже не любое изображение может оптимально сжать. Особенно когда значение RGBA практически каждого пикселя уникально.
Но тут для проекта надо подбирать, где SVG, где PNG, где JPEG, а где и старый GIF подойдет.
А вот насчет разрешения… Вон тут недавно был топик про retina, Торвальдса и пр.. Так что черт знает, что там с разрешениями сейчас. Слишком большой разброс поддерживаемых разрешений теперь.
Очень понравилась статья, все по делу
Каким образом Raphael.js осуществляет поддержку IE?
Статью пока не прочитал.
Осуществил год назад часов за 8-12 на этой хрени свою мечту — измерение пути по скриншоту карты. На Оперу под Андроид 2.1 перенеслось криво (вообще и на виндах работает по-разному в FF и хроме). Когда поменял планшет на таковой с ёмкостным экраном, вообще понял в какую лужу сел — в моём поделии почти всё было завязано на дабл-клик, на резистивном было хоть как-то реально со стилусом…
В общем, технология гиморная, но перспективная.
Осуществил год назад часов за 8-12 на этой хрени свою мечту — измерение пути по скриншоту карты. На Оперу под Андроид 2.1 перенеслось криво (вообще и на виндах работает по-разному в FF и хроме). Когда поменял планшет на таковой с ёмкостным экраном, вообще понял в какую лужу сел — в моём поделии почти всё было завязано на дабл-клик, на резистивном было хоть как-то реально со стилусом…
В общем, технология гиморная, но перспективная.
Кому хренасе, а некоторые на трёх браузерах проверяли код, который в экран не влазит и размеры меняет — как он на скроллинг реагирует. Не, согласен, что претензия на GIU на чистом SVG — это несколько изврат. Но всё же.
Да, а ещё я на нём объект XMLHTTPRequest обнаружил…
Да, а ещё я на нём объект XMLHTTPRequest обнаружил…
Так что, раз на разных браузерах по-разному, пока только «перспективная»…
недавно только писали про «оранжевый цвет» habrahabr.ru/post/156451/ и тут бабах! такое лого… или такой?
window.onload=function() {
//сюда вставить код Raphael
}
Боже, мои глаза.
//сюда вставить код Raphael
}
Боже, мои глаза.
Не понял кстати, зачем разделять синтаксис line и polyline — по сути ведь это одно и то же.
И еще непонятно, почему у прямоугольника правый и нижний бока жирные.
И еще непонятно, почему у прямоугольника правый и нижний бока жирные.
Sign up to leave a comment.
Знакомство с SVG-графикой