define('DISALLOW_FILE_EDIT', true); SVG – unFocus Projects – Kevin Newman and Ken Newman

SVGView for Xamarin.Android

Instead of making dozens of PNG files for all the various screen sizes for icon assets, I wanted to use vector graphics (such as SVG) in an Android app I’m building with Xamarin.Android. There is a tool for generating images, and that’s better than nothing, but SVG is even easier, and I’m all about easier. I thought this would be relatively easy to do, but it turns out Android has no built in support for vector image formats.

Xamarin has a nice binding project and sample for using an SVG library (I think it wraps SVG-Android on GitHub) in Android apps, but it wasn’t clear how to use that, and there was an annoying gotcha I hit along the way, that I thought I’d document here.

There are two projects in the sample solution. One is the library project, and the other is a sample project, with sample art that you can build to see it working. What we want to do is build the library, and then copy the necessary components into our own Android app project. Here’s how to do that using Xamarin Studio.

  1. Download and unzip the project files from Xamarin (or fork it on GitHub). Open the Solution in Xamarin Studio. You should see something like this:
  2. Put the build mode into “Release” and then right click (or control click) on SvgAndroid (Highlighted in the screenshot above), and then click Build SvgAndroid (or highlight the project and press cmd+K). This will make a release .dll file (a .NET assembly) in the bin folder:
  3. You’ll need to copy two files into your own project. SvgAndroid.dll from bin/Release, and svg-android-1.1.jar from the Jars folder. I put SvgAndroid.dll file in the project/Assemblies folder in in my project hierarchy so that the dll could be managed in git with the rest of my project (the git rule of thumb – include what you need to build, and I need this dll to build the app). The jar file – svg-android-1.1.jar – went into the project/Jars folder.
  4. Add the assembly to the project: Right click on references in the Solution panel, and choose “Edit References.” In there, add the .dll under the “.Net Assemblies” tab.
  5. Add the jar file: Add the jar file to your project using add file or add folder (to add the entire Jars folder). Then right click the jar file, and choose “Build Action” -> “AndroidJavaLibrary” to make sure it gets packaged with your application.

That’s it! Those two files are all you need. Now you can create an SVGView class, and use that in your axml layouts. Here’s a quick and dirty example of the class:

[csharp]using System;
using System.Collections.Generic;
using System.Linq;
using System.Text;
using Android.App;
using Android.Content;
using Android.OS;
using Android.Runtime;
using Android.Util;
using Android.Views;
using Android.Widget;
using Com.Larvalabs.Svgandroid;

namespace unFocus
public class SVGView : ImageView
protected string svgSrc;
public string SVGSrc {
get {
return svgSrc;
set {
svgSrc = value;
setupSVG ();

public SVGView (Context context) :
base (context)
Initialize ();

public SVGView (Context context, IAttributeSet attrs) :
base (context, attrs)
Initialize (attrs);

public SVGView (Context context, IAttributeSet attrs, int defStyle) :
base (context, attrs, defStyle)
Initialize (attrs);

void Initialize ()

void Initialize (IAttributeSet attrs)
var a = Context.ObtainStyledAttributes(attrs, Resource.Styleable.SVGView);
SVGSrc = a.GetString(Resource.Styleable.SVGView_svgSrc);
a.Recycle ();

void setupSVG ()
// svg-android doesn’t work in hardware mode, so set software
SetLayerType (LayerType.Software, null);

if (null == SVGSrc)
SVG svg = SVGParser.GetSVGFromAsset (Context.Assets, SVGSrc);
SetImageDrawable (svg.CreatePictureDrawable ());
Invalidate ();

And in values/attrs.xml:

[xml]<?xml version="1.0" encoding="UTF-8" ?>
    <declare-styleable name="SVGView">
        <attr name="svgSrc" format="string"></attr>

Now you can create SVGViews in axml using:

   android:id="@+id/icon" />[/xml]

SVG files go in the Assets folder, in whatever tree you want. In this example, they are in Assets/svg/. Build action for svg files is “AndroidAsset,” which should be the default.

There is an irritating gotcha, that’ll have you tearing your hair out if you don’t know about it.

SVG files MUST have width and height attributes on the root element to work with this library. If you don’t have them, and Adobe Illustrator CC doesn’t add them by default, the lib will fail with cryptic error messages. The fix is easy enough, just open the SVG in Xamarin and add width and height attributes. There will already be a viewBox attribute with the correct attributes (viewBox=”0 0 70 70″ <– the second two, width and height). You’ll need to add these: width=”70px” height=”70px”.

Update: One other thing I forgot to mention – this didn’t work on the Xamarin Alpha for some reason. The SVGAndroid binding was failing if I remember correctly (at least that’s where the runtime  errors seemed to originate). So if you are having trouble getting this to work, it might be something in the Alpha channel.

Update 2: What I’ve showed you here will work, but some folks on the Xamarin forums suggest there may be advantages to including third party code in alternative ways (like including an entire project, etc.). Have a read.

Update 3: SVG-Android won’t work under hardware acceleration, which is enabled by default in apps targetting Android 3.0 and newer. You just get a blank space. The easiest way around this is to set the Application, Activity, or the specific view you are working on to use software acceleration.

I modified the SVGView example above to do this automatically, but you can also do it yourself (using the code above) or by setting the android:layerType=”software” on the specific view (or somethings its parent).

This is worth knowing about because other types of drawables (such as animations) seem to display other types of incompatibilities with hardware acceleration (such as fuzzy low resolution renderings), and setting software mode can fix it.


The Third Option for HTML Font Embedding

In the debate over whether web browser makers should implement .eot font support for Firefox in addition to their support for .ttf files (and .otf), their is an alternative that rarely gets any mention – SVG Glyphs in an html context. This is already supported by Opera 10, Safari 4, and Google Chrome (all prerelease at the time of this post). Using SVG Glyphs this way addresses a number of concerns, which are not often mentioned, or simply not well understood.

This gets sticky, but to understand the need for SVG glyphs you need to understand the debate around DRM. DRM doesn’t work. It’s such a failure, that Apple and others have completely abandoned it in their music formats, and game companies are starting to do the same. The reality is that if the crackers and pirates can get their hands on the material (like an encrypted music file), they are going to strip out the protection. So let’s write off DRM.

That’s not to say we should write off all forms of protection. Since we can’t stop the crackers, let’s concentrate on an area we can do something about, casual piracy. Consider a regular end user, who might view the source of a website, or checks their FireBug Net tab, and grab the font file to either install or use on their own system or website illegally. This is where SVG and EOT can play a role. EOT addresses both of these scenarios out of the box – it can be tied to a particular domain, so it cannot be easily installed on another website or blog, and it cannot be easily installed on an end user’s system folder, since it’s not a regular system font. By default, SVG addresses only one of these two problems – they can’t be installed on the user’s system, but they can be easily copied to another site. However, the EOT domain protection can be mimicked through the use of other web technologies. For example, you could serialize the SVG into a dataURL, and then further serialize that into some javascript (and even obfuscate and encrypt it if you wanted to), where you can do all the domain checks you want. This kind of protection is the ideal solution. It provides the maximum protection that DRM has ever been able to practically offer other – it makes it difficult for honest users to pirate fonts.

It is true that with enough googling, downloads and virus scans, the tools are available to extract something like an installable font from PDFs, SWFs, and even SVG files. For an end user to do that, they need a specific intent to steal the material, as well as a the technical capability to actually pull it off. Here we are back into pirate land, and those guys are more likely to hop on usenet, or bittorrent sites anyway – or their local file server at work, rather than attempt to extract some half version of a font from a PDF, EOT, SWF or SVG font (which tend to be subsetted). Dealing with them is a job for lawyers and the law, and it not a technical challenge. Fighting them on the wrong front will cost more than it nets, in terms of lost sales from not participating (and not making sales), or from the support headaches of dealing with ill-conceived DRM technology.

Having a font format that keeps the honest honest, is not too much for type designers to ask for. They spend a lot of time creating type faces, and frankly, they deserve some kind of protection from casual piracy – protection that is at least on par with the kinds of protection other forms of media are already receiving on the internet – and that even fonts are receiving in other formats, such as PDF and Flash SWF files.

Web browser makers, should implement EOT font support, the format supported by the 10,000 pound gorilla – Microsoft‘s Internet Explorer – which is huge, but they probably will not due mostly to a lack of interest from someone willing to do that work – and maybe other concerns. Since that is the case, SVG glyph fonts are great second choice. They provide all the protection that can be reasonably expected from an online media format, and starting over with a new font format is undesirable, if it means we have to wait for 10 more years to get any progress. The upshot is, it’s already in most of the current alternative browsers! Only Mozilla‘s Firefox has yet to implement SVG glyph support – they do seem ready to do it. The future of HTML font embedding is looking bright!

Update: I saw this earlier, but didn’t have the link handy. In bugzilla bug #119490 comment #15, John Daggett mentions that they plan to add this feature for Gecko 1.9.2. This is great news! It does mean more waiting though, as Gecho 1.9.2 is slotted to run whatever version of Firefox comes after the soon to be released 3.5 (3.6 at the moment).