using SVG images in Rails
john
code that works outside of Rails. I guess it has something to do with
allowed mime types. Yet the awesome Scruffy graph library is
supposedly written in Ruby so it can be done. Meanwhile I've
downloaded that code and maybe I can figure out how they did it. If
anyone else has been using SVG, please let me know how you are doing
it. thks.
Daniel Amelang
Yea, love it when people live dangerously and venture into SVG land.
I'm still hopeful that SVG will be a viable option for general-purpose
web development. Not sure how that'll happen while IE still
dominates... :(
What's the behavior that you're currently getting? I remember having
some initial issues with getting things set up, too. I think I
resolved it with some tips from the SVG authoring page at MDC:
http://developer.mozilla.org/en/docs/SVG
In particular the inline SVG guide:
http://developer.mozilla.org/en/docs/SVG_In_HTML_Introduction
and the pure SVG guide:
http://jwatt.org/svg/authoring/
On a side note, I just noticed the (new?) example they put up with the
swarm of motes. Pretty cool:
http://developer.mozilla.org/samples/svg/swarm-of-motes.xhtml
Dan
Hans Fugal
love it when people live dangerously and venture into SVG land.
> I'm still hopeful that SVG will be a viable option for general-purpose
> web development. Not sure how that'll happen while IE still
> dominates... :(
>
Actually SVG has been waiting on Mozilla for a very long time. Like
since before there was firefox. Adobe's IE plugin was fully functional
way back then and I don't think that's changed one bit.
It will be nice when SVG is included, in all its glory, in the
browsers themselves, but requiring a plugin download hasn't stopped
flash so I don't think we can blame that at all.
Without looking at the code/error/etc. I think you're probably right
about the mime types thing. If your whole document is the SVG file,
then it needs to have the right mime-type and getting rails to do that
was less than easy last time I looked (although I wasn't trying for an
SVG mime type at the time). OTOH if you just have an svg object
embedded on your page then rails shouldn't have anything to do with
that, other than serving the right content.
--
Hans Fugal
Fugal Computing
john
> Without looking at the code/error/etc. I think you're probably right
> about the mime types thing. If your whole document is the SVG file,
> then it needs to have the right mime-type and getting rails to do that
> was less than easy last time I looked (although I wasn't trying for an
> SVG mime type at the time). OTOH if you just have an svg object
> embedded on your page then rails shouldn't have anything to do with
> that, other than serving the right content.
for some reason the html way of displaying it in firefox using embed
just doesn't work under a rails view (I don't understand why if it's
just plain html code but ....). However, though I didn't find much
under a google search, searching under the rails google group I found
someone posted a way to do it (it includes adding a mime type, but
other stuff too). I just need some time to try it out (next few days).
SVG is just very cool - I think using RJS with it could also be very
powerful. Sure you need firefox or the adobe plugin under IE but it's
well worth it where you can insist on such use.
The Scruffy graphs are very cool - but I think they simply take the SVG
and use ImageMagic to render a png.
Daniel Amelang
>
> On 1/16/07, Daniel Amelang <daniel....@gmail.com> wrote:> Yea,
> love it when people live dangerously and venture into SVG land.
> > I'm still hopeful that SVG will be a viable option for general-purpose
> > web development. Not sure how that'll happen while IE still
> > dominates... :(
> >
>
> Actually SVG has been waiting on Mozilla for a very long time. Like
> since before there was firefox. Adobe's IE plugin was fully functional
> way back then and I don't think that's changed one bit.
> It will be nice when SVG is included, in all its glory, in the
> browsers themselves, but requiring a plugin download hasn't stopped
> flash so I don't think we can blame that at all.
That may be true for pure SVG document rendering, but notice my
original wish: for SVG to be a viable option for general-purpose web
development. Mixing ASV+other web technologies often requires
convoluted hacks (see
http://wiki.svg.org/Inline_SVG#The_ASV_Hack_and_Namespace_Prefixes for
example), you have to jump through the loops mandated by the
HTML+CSS+inline SVG buggy behavior, even with the iframe method you
run into inter-document communication problems, and then there's no
foreignObject support in ASV, I could go on but I'd just be
reproducing what's been said for years on the svg-related mailing
lists.
So you can say that ASV has long been fully-functional (although not
complete) as an SVG document viewer, but that's not enough for
general-purpose web development IMO. SVG just doesn't mix well with
the other web technologies when implemented by a plug-in. And since
the plug-in alone couldn't compare with what Flash offered (despite it
being a plug-in also), SVG didn't take (at least that's my analysis).
So now, years later, I believe SVG's future will be in augmenting the
existing web technologies. Like an animated gaussian blur on a block
of HTML, or a shear transformation on a some CSS-styled div that
contains an image. You can't do any of that with ASV, or any plug-in
(currently). SVG's font embedding capabilities may be the solution to
the poor font support in HTML, once the two can be freely mixed.
So, I guess that's what I'm looking for when I say I want "SVG to be a
viable option for general-purpose web development".
Dan Amelang
john
> On 1/17/07, Hans Fugal <fug...@gmail.com> wrote:
>
> So you can say that ASV has long been fully-functional (although not
> complete) as an SVG document viewer, but that's not enough for
> general-purpose web development IMO. SVG just doesn't mix well with
> the other web technologies when implemented by a plug-in. And since
> the plug-in alone couldn't compare with what Flash offered (despite it
> being a plug-in also), SVG didn't take (at least that's my analysis).
>
The big difference is that the Flash plug-in ships with IE and ASV does
not plus even if you are missing the Flash plug-in, a message pops up
about instantly downloading and installing it - that doesn't happen
with SVG and most users don't know enough or can't be bothered with
manually downloading a plug-in. Whether this is done on purpose or
whatever is left to the reader.
SVG works well with Firefox, Opera, and the Safari web kit, and is also
prominent on cell phones. For a general public website where 80% of
users have IE I would say you are right - it's use is more limited but
there are still some cool applications using ASV. In a more internal
or specialized situation SVG is a great way to go - we simply tell our
customers they need to use Firefox and eventually may just ship them a
tablet computer that runs it.
Hans Fugal
one that could be achieved until after SVG was viable at least as a
plugin. In other words, I'm saying SVG was indeed held back by the
whole ASV/Mozilla fiasco even though in the end we may not want
ASV/Mozilla. Thankfully for us some other people in open source saw
the potential of SVG (gnome, kde, etc.) and svg support came from
another source.
I haven't looked at svg support in quite some time, but last I looked
the firefox internal support was limited to static effects, stuff like
what you're describing. ecmascript and dynamic changing was severely
lacking. Has that changed?
As for why Flash succeeded and SVG didn't, I think there's two
reasons. A) Flash beat SVG to "market". Which started first I don't
know but Flash was "out there" before SVG, to be sure. B) Flash had
whiz-bang graphics designer-friendly (and expensive) tools. With SVG
you crafted the XML yourself. I don't think it's rocket science to
figure out why Flash was more popular. Also the support for things
like sound and animation and so on was a long time coming for SVG but
was there from the start with Flash.
SVG has many benefits over flash including being open, potentially
more powerful, easier to generate dynamically, a more sound
theoretical foundation, etc. It's a great technology and I'm happy to
see it coming into its own.
Daniel Amelang
>
> I see what you're getting at. It's a neat goal, but I don't think it's
> one that could be achieved until after SVG was viable at least as a
> plugin. In other words, I'm saying SVG was indeed held back by the
> whole ASV/Mozilla fiasco even though in the end we may not want
> ASV/Mozilla. Thankfully for us some other people in open source saw
> the potential of SVG (gnome, kde, etc.) and svg support came from
> another source.
Agreed.
>
> I haven't looked at svg support in quite some time, but last I looked
> the firefox internal support was limited to static effects, stuff like
> what you're describing. ecmascript and dynamic changing was severely
> lacking. Has that changed?
Dynamic SVG (via Javascript) has been supported since Firefox 1.5.
But, even FF 2.0 still doesn't support all of SVG Basic, and there are
some performance issues. The overall goal is to beef up SVG support
(especially foreignObject), introduce SMIL animation and get
performance to a reasonable level.
Little plug for my Masters thesis project: "Optimizing Performance in
the Cairo Vector Graphics Library" :) Cairo is what Mozilla uses for
2D rendering.
>
> As for why Flash succeeded and SVG didn't, I think there's two
> reasons. A) Flash beat SVG to "market". Which started first I don't
> know but Flash was "out there" before SVG, to be sure. B) Flash had
> whiz-bang graphics designer-friendly (and expensive) tools. With SVG
> you crafted the XML yourself. I don't think it's rocket science to
> figure out why Flash was more popular. Also the support for things
> like sound and animation and so on was a long time coming for SVG but
> was there from the start with Flash.
Agreed. The fact SVG was only available as a plug-in was only one of
many downsides it had, and the reasons you gave were more important,
IMO. Thing is, even with native browser support, the designer-friendly
tools still aren't there for SVG (at the level that the Flash tools
are), so the most (?) important hurdle is still there. People often
point to Inkscape as the solution to that, but it has a long way to
go.
>
> SVG has many benefits over flash including being open, potentially
> more powerful, easier to generate dynamically, a more sound
> theoretical foundation, etc. It's a great technology and I'm happy to
> see it coming into its own.
Me, too. I encourage anyone else that wants to see SVG succeed for
those same reasons to help out, hint, hint :)
Thanks to the Ruby/Rails list for hosting this discussion. :) It's my
fault, really, that we got off topic.
Dan
john
> On 1/18/07, Hans Fugal <fug...@gmail.com> wrote:
>
> IMO. Thing is, even with native browser support, the designer-friendly
> tools still aren't there for SVG (at the level that the Flash tools
> are), so the most (?) important hurdle is still there. People often
> point to Inkscape as the solution to that, but it has a long way to
> go.
Inkscape actually does quite a lot (layers, gradients, blur) perhaps
more than what is supported in the browsers I think. However, it
doesn't support a timeline or animation yet (it's further down the
roadmap) - I guess it means it isn't good for doing those obnoxious
flashing banner ads. We use Inkscape for all our icons, logos, static
maps, etc which is why I'm so interested in getting it to work with
Rails. And while everything in Inkscape can be easily saved out to a
png, once you get used to scalable images, it's tough to go back.
Meanwhile, making progress on the display front - adding the mime types
is part of it (I'll upgrade to 1.2 and test out some suggestions).
Hans Fugal
> Little plug for my Masters thesis project: "Optimizing Performance in
> the Cairo Vector Graphics Library" :) Cairo is what Mozilla uses for
> 2D rendering.
Cool. It bears mentioning that my dynamic pedigree chart ran into
performance issues of the adobe plugin. Certainly there was room for
optimization, but what we were doing shouldn't have brought the
computer to its knees, but it did. Maybe they've made progress since
then (CPUs sure have).