IssueTracker

I can not replicate this issue. I am using G1 Running RC30. I have gone to
http://en.wikipedia.org/wiki/File:Bitmap_VS_SVG.svg and other web pages that have embedded svg graphics and
I have found that the browser displays them fine.

What do you get for http://highlandsun.com/hyc/Kazakh/d3/ ? There are 3 SVGs in the
first 2-3 pages, none of them show up on the phone but they all work fine in a
regular browser. Opera on the G1 works too (but Opera doesn't render embedded fonts,
which this page also uses).

We have chosen intentionally to not support SVG in the browser to save space; full SVG adds over 1M to the
webkit image size.

As is described here:
http://googlecode.blogspot.com/2009/10/svg-at-google-and-in-internet-explorer.html

SVG is a really useful technology to have in a mobile browser.  And it is supported
by other mobile devices.

Perhaps the webkit build can be setup so SVG can be added as a downloadable app to
the built in browser.

I would like to use the Google Visualization API on an app that I am building. Is there
some way to do this other than to have the browser support the functionality?  

dacarys: I'm not aware of an interactive alternative to SVG.

We're considering enabling SVG for WebView in a future release, on devices with the memory to support it.

Please enable it by default. Yes, it's easy to enable it by "make ENABLE_SVG=true" and modifying
external/webkit/WebCore/config.h and maybe "external/webkit/WebCore/loader/FrameLoaderClient.h".
However, if it's not enabled by default, I think few devices will support it. And as discussed above, there is no
interactive alternative to SVG.

I hate to add a 'me too' comment, but lack of SVG in the Android browser seems like a big missing feature.  

SVG is part of the HTML5 group of technologies, and as such has wide support across a variety of devices and platforms, including things like the Google Chrome browser, and the iPhone Safari browser.  As linked above Google themselves promotes SVG graphics as excellent technology, being open, cross-platform, easily programmable, and accessible, too, so screen-readers can use them.

Finally, my Google Nexus One has 512 MiB of RAM, and a 1 GHz processor.  Having Android tell me it would be too much work for my hardware to render SVG is hard to accept. It's hard to understand a position which says Android shouldn't be a next-generation web-browser platform.

jonathan.stewart: you may be interested in comment #4 here: http://code.google.com/p/android/issues/detail?id=8202#c4

Can we get consistent status between these two bugs?  Is SVG enabled in the Gingerbread browser now?  Can this bug be closed?

[Comment deleted]

SVG has been enabled in a future release, but not necessarily a release called Gingerbread. Sorry for the confusion.

Although it's said that SVG will be enabled by default in next Android release (GingerBread?), we need to test SVG a bit on Android before we have GingerBread. So we tried to enable it. It turned out pretty easily. Tweaked several lines and "make ENABLE_SVG=true ENABLE_SVG_ANIMATION=true", then you got it. Since SVG will be enabled by default, and it's pretty simple,  we won't bother submit the patch. The attached file is patch against AOSP master

Would it be possible to include a replacement version of the browser with SVG support in the marketplace?

It's possible, but it may not be what you thought/wanted. The Android browser consists of three main parts: the Brwoser.apk, Java WebKit binding and related in the android.webkit package,  and the underlying C++ WebKit code. The rendering of SVG is the job of the C++ part. And, unfortunately, I don't think it's possible, or say, legal, to make a package to in the marketplace that can replace those C++ WebKit libs under /system/lib. That is, though what we want to have is a slightly tweaked SVG-enabled Android browser, the resulting package might need to have the 3 parts I mentioned.  

BTW, after I enabled SVG,  the Acid3 results changed from 93/100 to 96/100. However, three of the four remaining failed tests are SVG related.  See the attached file, or check http://www.tandroid.org/enable-android-webkit-svg

It turned that if all SVG code is enabled properly, the browser will pass all SVG tests. The remaining failed one is CSS media related.

https://review.source.android.com/#change,17258

SVG is becoming more and more important for web developers, as it is a popular standard now (Only MS Internet Explorer does not support it yet, but in IE9).

People are relying on it, developers as well as web page visitors, as it is much more performant than the HTML5 Canvas, regarding animation. (See http://www.lutanho.net/svgvml3d/index.html for examples of efficient 3D animations).

@koansin.tan
I am new on this forum and also just started android development. I donot know where to find Config.h (external/webkit/WebCore/config.h ) to Enable SVG. Can you pleae explain it Step wise. I am using Samsung galaxy i9000. will be gr8 if you can help.

iphone browser and mozilla fennec have svg rendering. so android needs it too

Interesting that webkit has support compiled out, yet Android device makers bundle in the Adobe SVG Viewer.  How heavy is that?

Please reconsider.  SVG is a longtime friend of open standard rendering that gives us features unavailable in Canvas.

[Comment deleted]

Hi, Can any one please tell me how to edit "external/webkit/WebCore/config.h and maybe "external/webkit/WebCore/loader/FrameLoaderClient.h" Where i can find these two *.h files ?

@atif.musaddaq

Modifying config.h is not necessary. Please read https://review.source.android.com/#change,17258
However, you need to recompile your WebKit (libwebcore.so). If you don't know to do that, you can
start from http://source.android.com/source/download.html

SVG is about providing Vector Graphics integrated with the DOM. Although faster at rendering 2D graphics, Canvas does not allow to setup DOM events, making it much slower than SVG to render interactive dynamic graphics especially on slower mobile device processors.

Zooming graphics with canvas also renders poorly because the actual result is raster graphics which loose the vector "intelligence" as soon as rendered.

For vector graphics on the Web there are 3 options: Flash, VML and SVG. The only really open standard is SVG. VML is being demoted as SVG will start to replace it gradually starting with IE9. Flash does not integrate with the DOM and will therefore never be a real alternative even it was an open standard.

More and more web application rely on SVG to render graphs and other computer-generated graphics. Popular JavaScript libraries such as Raphael.js and Dojo GFX support SVG and VML and will not support Canvas for the above reasons. jQuery also has an SVG (no VML here) plugin.

The lack of support for SVG on Android is therefore a severe restriction when it comes to modern dynamic user interface design especially when it has been supported on iPhone for years.

For the ones needing SVG support on their androids, Firefox Mobile 4.0b2 (beta) for Android supports SVG.

Dear Android team, will you give use SVG support for this christmas? In gingerbread?

Please enable SVG support. It is frustrating that I can use SVG for my iphone mobile applications, but they break for android. Seems strange to me and makes my life a little bit more difficult! :)

[Comment deleted]

Please add support for SVG!

[Comment deleted]

At least provide another version of the browser in the Marketplace, with SVG enabled.  Surely this should be possible now?

Firefox on Android supports SVG, and is available in the Marketplace.

apparently travesty corrected in honeycomb. http://twitpic.com/3vdro4 ye be saved, web loving mortals.

via http://twitter.com/#!/ariyahidayat/status/32327100480360448

I feel mutilated without SVG on Android browser...
 

> I feel mutilated without SVG on Android browser...

it's ok; we're sympathetic.  if this incident has left you with a feeling of shock, know that there are others suffering, and you should seek your local WebApp support group for help and consolation.  

the good news is help & sanity appear to be riding to the rescue; OHA appears to have flipped the ENABLE_SVG bit for honeycomb, & presumably 2.4 will be web compliant as well.

Given the number of comments on this ticket, and more 200 people starred it, it's really disturbing. How the hell you want to manage some developer community if you fail to explain your reasoning for not 'flipping a switch' sooner. Android is open as long as you wish to make a fork. Thank you very much for your openness

> How the hell you want to manage some developer community if you fail to explain your reasoning for not 'flipping a switch' sooner.

please read the thread. they've explained their reason in comment #4, August 2009 [1]:
> We have chosen intentionally to not support SVG in the browser to save space; full
> SVG adds over 1M to the webkit image size.

followed up in comment #7, April 28 2010 [2]:
> We're considering enabling SVG for WebView in a future release, on devices with the memory to support it.

[1] http://code.google.com/p/android/issues/detail?id=1376#c4
[2] http://code.google.com/p/android/issues/detail?id=1376#c4

Android is indeed open to a fork, and compiling an Android image with the ENABLE_SVG flag-bit flipped is easy as cake.  That, however, does application developers no good as their target audience is likely to have a manufacturer's build, which will likely follow OHA/Google's lead.

WebView is indeed used many many places in Android.  How about introducing a SvgEnabledWebView application developers can opt in to use?  That way there's no additional memory pressure from unused SVG code in existing cases, and those wishing to build Web Applications have a path forwards?

You're reading it backwards. It should be vendor's choice to opt-in/out of this feature. But given that the default is 'no you can't have it', how many vendors do you think will enable it? Do you seriously think that Samsung or HTC will opt-in because the memory on their devices is big enough, and then advertise as a feature? Don't think so. I'm familiar with the whole thread, and I don't consider 1MB of storage space as a valid reason (it's 2011). This was mentioned many times by others, but without any response from the team.

As of SvgEnabledWebView, that sounds good to me, although in some other form, we don't want to end up with CanvasEnabledWebView, WebWorkersEnabledWebView etc. Don't try to convince that the team is responsive, it's not.

They can enable it and they would enable it if there was user demand for this feature. They did much crazier things with their ROMs. The trouble is there's little user demand for SVG capability in mobile browser. This silly decision is currently limiting web developers and holding mobile web back. Ironical since Google claimed to have entered the mobile market to liberate the mobile web.

My main reason for wanting SVG in android is because it would make building dpi independent web applications much easier.