Reinventing Fire

WebFonts in SVG

July 29, 2012

Filed under: Fonts,SVG,SVG Basics,Technical — Magister @ 4:24 pm

Several times recently, people have asked on IRC how they can use nice fonts with SVG. My answer in the long-ago past, when Adobe’s excellent SVG Viewer plugin roamed the Earth, was to use SVG Fonts directly embedded in the SVG file… but that’s no longer practical with the current varied browser support.

By far the easiest way to do this today is to use webfonts, such as WOFF.

Authoring tools, like Inkscape and Adobe Illustrator, should simply manage this for authors, but until that happens, I thought I’d share a relatively simple workflow that has helped others. (Warning: I will use the words font and typeface with careless abandon to semantics in this article, though I know the difference. I’m afraid the more sensitive souls among you may suffer apoplectic righteous indignation.)

I will walk you through this workflow step-by-step, but if you get lost, just look at the source code… it’s pretty self-explanatory.

  1. Find a font you like. For this example, I chose Riesling, an Art Deco typeface by “Bright Ideas”. I made sure the font was free and didn’t have any restrictions for online or commercial use.
  2. Upload the font to FontSquirrel’s @font-face generator, and download the resulting package. This contains the webfonts, as well as some sample files (though not an example of how to use the files in SVG).
  3. Copy the resulting webfont files (*.eot, *.ttf, *.woff, *.svg) into the same directory as the SVG file that will reference them. (Note: do not confuse the SVG file in the FontSquirrel package for a content file; it is an SVG font, with no rendering content.)
  4. Copy the CSS @font-face style rule from the FontSquirrel package file (“stylesheet.css”), and put it in your SVG’s <style> element.
  5. Optionally, for local testing, install the original TTF file as a system font, and add the local value to the @font-face style rule
  6. Add a style rule for text elements, using the resulting font-family. In my example, I also created a style rule for textPath elements.
  7. No, really, that’s it. You’re done.

Here is the resulting SVG using webfonts:

Please use a modern browser.

A Word on the Future of SVG Fonts

Since I’ve mentioned SVG Fonts a couple of times, I thought I’d leave you with a final note about what the future seems to hold for them.

SVG Fonts were added in SVG 1.0, way back in 1999, as a way to embed fonts in the same file, using vectors and all the capabilities of SVG, including separate fill and stroke (which could be gradients or other paint sources), and even exotic features like clip-paths, animation, and so on; Jérémie Patonnier has a great article on the topic. As cool as this is, it doesn’t necessarily work well with existing font engines… The Adobe SVG Viewer had support for SVG Fonts, and Opera and WebKit added support for the less-powerful SVG Tiny 1.2 subset as well; but Mozilla and Microsoft decided not to add support for SVG Fonts, and that limits their usefulness. It doesn’t seem likely that SVG2 (being developed now) will include SVG Fonts, not necessarily even the more limited subset (though there is not yet consensus in the SVG Working Group).

In practical usage, SVG Fonts were once the only way to use webfonts on iOS devices (e.g. the iPhone and iPad), which is why FontSquirrel includes them in their font-face package; but this is no longer the case, and iOS 4.2 added support for TTF fonts, which reportedly perform better. I expect this use of SVG Fonts to dwindle away… people will naturally want to use as few font formats as possible.

But for all of you out there who, like me, love the cool things you can do with SVG Fonts that aren’t possible in traditional outline font formats, don’t despair! Even as I write this, a proposal is being prepared by the SVG glyphs for OpenType Community Group to add a subset of SVG to OpenType, for more interesting typeface capabilities.

SVG Fonts are dead! Long live SVG Fonts!

SVG Game Resources

October 13, 2010

Filed under: Games,SVG,SVG Basics,Technical,Work — Magister @ 12:36 pm

Mozilla is holding an Open Web Games competition. I expect that many of the games will be use the Canvas API, since many programmers are more familiar with the imperative programming mode, and there are some games libraries that have been developed for Canvas or adapted from existing drawing or gaming libraries.

But I’m calling for SVG developers and designers to step up to the plate, as well. SVG has a lot of features that make it easier out of the box to build interfaces, animations, and even games. There is a scene graph, and the DOM event model that gives you free hit detection for pointer events, for example. And I’d love to see someone make an open-web game that’s both accessible and fun…

To help developers along, I thought I’d share a few free, open-source SVG resources that could be useful in building games:
(more…)

Stumbling Towards a Graphical Workflow

March 8, 2010

Filed under: Authoring Tools,Browsers,Conferences,Standards,SVG,SVG Basics,Tech,Technical,W3C,Work — Magister @ 6:10 am

I’m working with a professional designer, Michael, on some graphics for my upcoming MIX presentation.  I’ve worked with designers before on various projects, some SVG, some traditional Web design, but this is my first time working on an SVG project with someone who never used SVG before, and it’s been an interesting experience, which I thought I’d jot down for anyone interested.

Both of us have been busy with other projects, and since we are in different places (me in Chapel Hill NC, him in Atlanta GA), we have only gotten to touch base a few times.  Michael has delivered some first drafts of the graphics, which look lovely, and I decided to dig into the underlying code, confident that I could trim down the file size and thus help browser performance.

My personal graphical editor of choice is Inkscape, which is a fine tool for all its warts (though it’s a little painful on Mac, where it is hosted as an X-11 application); typically, though, I create SVG either programmatically with a script or manually with a text editor (yes, I know that’s crazy… but it can be done).  Michael, being a professional designer, uses Adobe Illustrator, and I am keen to have him use the tools he is most comfortable with.  Since I want SVG to be used by mainstream designers, I want to understand how their tools work and what their workflow is like.

So, in order to make sure that we can roundtrip the files as seamlessly as possible, while still leveraging the features of SVG, I set about today to establish a workflow with Illustrator, TextMate (my go-to text editor, with a custom SVG code template bundle), Firefox, and its native debugger extension Firebug (with its handy “Inspect Element” context-menu selection).  My goal: to make reusable icons out of some of the graphical assets in the larger image, to be referenced by SVG’s <use> element. (more…)

CSS Link Hack in SVG

January 18, 2009

Filed under: Browsers,CDF,Standards,SVG,SVG Basics,Technical,W3C,Work — Magister @ 11:09 pm

While answering a question about styling SVG with CSS in the Freenode #svg IRC channel (yes, people still use IRC), I threw together a simple example to illustrate.  I like to do this, since in keeps me in practice, and gives me a chance to check the state of current implementations in the fast-changing world of SVG browser support.

The question was how to use CSS stylesheets, both internal and external, with SVG in Inkscape.  While I know that Inkscape makes heavy use of CSS inline style declarations on elements (more than is to my personal taste, to be honest), I didn’t (and don’t) know if it has any UI features for adding internal stylesheet blocks, or links to external stylesheets.  So I made a little test…

svgstyle.svg

<?xml-stylesheet type="text/css" href="svgstyle.css" ?>
<svg xmlns="http://www.w3.org/2000/svg"
     xmlns:xlink="http://www.w3.org/1999/xlink"
     width="100%" height="100%" viewBox="40 0 145 70">

  <style type="text/css"><![CDATA[
     ellipse
     {
       fill: lime;
       stroke: green;
       stroke-width: 10px;
     }
  ]]></style>

  <rect id="inline" x="50" y="10" width="30" height="50"
        rx="5" ry="5"
        style="fill:lime; stroke:green; stroke-width:3px;"/>
  <ellipse id="internal" cx="103" cy="35" rx="15" ry="25"
        style="stroke-width:3px;"/>
  <circle id="external" cx="150" cy="35" r="25"
        style="stroke-width:3px;"/>
</svg>

svgstyle.css

circle
{
   fill: lime;
   stroke: green;
   stroke-width: 10px;
}

Which looks like this (at least, in Firefox, Opera, Safari, and presumably Chrome):

Both internal styles worked fine in Inkscape, but the external reference did not, showing just a black circle.  I’m not really surprised.  Note the clunky way that you have to link to external stylesheets in SVG:

<?xml-stylesheet type="text/css" href="svgstyle.css" ?>

That’s really XSLT-licious. I have to confess, I don’t really care for PIs (insert dated Magnum PI joke here), or XML prologs in general… they seem somehow clumsy and un-XMLy, like a throwback to SGML. And as far as I know, they can’t be created or changed dynamically via clientside script. Compare that to the relatively easy and straightforward X/HTML way of linking to external stylesheets:

<link href="svgstyle.css" rel="stylesheet" type="text/css"/>

In the SVG WG, we intend to allow authors to reference external stylesheets in a manner a little more modern and consistent with what authors are already used to using, in some upcoming spec. We could do that a couple of different ways. We could allow them to use an xlink:href attribute on the <style> element, in the same way we currently treat the <script> element (that is, if there’s a resolvable external link, we use that, otherwise we use the child content of the element), or we could add a <link> element like X/HTML, or both. I kinda like the idea of allowing either.

To that end, I made a couple of tests, just playing around, to see if any browsers accidentally supported either of those options, by merit of having some shared codebase with X/HTML in their implementations. Unsurprisingly, neither worked.

But then I had another idea… use the an <xhtml:link> element in the XHTML namespace…

<xhtml:link href="svgstyle.css" rel="stylesheet" type="text/css"/>

With this rather happy result, which works in at least Firefox, Opera, and Safari.
external-link-xhtml.svg:

I don’t know if this is by design, or if it just fell out of the model, but I have to say I’m pleased as punch that it works. If nothing else, it’s a great proof of concept for adding more ways of linking to CSS in the SVG spec. This one goes in my toolkit, and I’m going to try to ensure that it gets standardized, if it’s not already there in some corner of some other spec. Probably somebody already knows about this (hell, probably everybody does, and I’m late to the party), but for me it was a w00ty discovery.

Update: heycam speculated that you might also be able to use @import rules, and indeed you can:

<style type="text/css">@import url(svgstyle.css);</style>

Speaking at SD West

November 1, 2006

Filed under: Conferences,SVG Basics,Travel,Work — Magister @ 6:55 pm

I just sent in my confirmation letter for my presentation at SD West 2007, a respected technical conference series in Santa Clara, California. I’ll be speaking on (can you guess?) SVG (you got it!) in a talk entitled Scalable Vector Graphics: Shaping Up the Web. The conference will be going on March 19-23, 2007. My company is really working on getting speaking engagements, so I think this may be only one of several that I’ll be doing in 2007. Of course, I will be speaking at –and helping to plan– the SVG Open conference next year as well. I normally give a 101 class introducing SVG there, in addition to a presentation on current projects I’m developing.

What is it, this SVG?

September 8, 2006

Filed under: SVG,SVG Basics,Technical,Work — Magister @ 3:11 pm

I’m going to be writing a lot about SVG, so I thought I’d give some explanation as to just what it is. Scalable Vector Graphics is an XML language for creating graphics. It’s a bit like HTML for images. If you want to draw a circle on your page, you type:

<circle cx="50" cy="35" cx="20" fill="blue" />

And then you have a blue circle with a radius of 20 pixels (more on that in some later post), centered 50 pixels from the left and 35 pixels from the top. Obviously, since people want to draw more than just circles, it gets a lot more complicated than that, but that’s the basic idea. SVG is a vector-based language, which means that rather than a collection of dots, like raster images (rasters are formats like bitmaps, JPEGs, etc.), SVG shapes are sets of instructions that tell the browser how to best draw the image. For instance, a line in a raster is just a series of unconnected dots… if you zoom in on it, that’s what it breaks down into; but an SVG line tells the browser to start at this point and go to that point, and so no matter how you zoom in or out, it remains a smooth, solid line. Each image is composed of a number of shapes, or elements, that have identities and properties. If you move your mouse over an element, or click on it, the browser knows about it, and the author can give instructions (either using script or something called declarative programming) for what to do… it might let you drag the shape, or change its color, or most anything else you want.

SVG is an open format, meaning anyone can make a browser or an authoring tool that uses it without having to pay any royalties. This sets it apart from similar technologies like Adobe Flash and Microsoft XAML. (I strongly believe in open standards, because it gives everyone a chance to control the future of the format; specifically, I think that all democratic governments should use open standards as much as possible, rather than rely on one company who can control the costs and future access to the information stored in their format.) And the fact that it’s open pays off. SVG is supported natively in Firefox, Opera, Safari, and other browsers for both the desktop and mobile devices. Right now, it is not supported natively in Internet Explorer, but you can get a plug-in for that (see later posts for updates on this). No other vector format is natively supported across so many browsers.

SVG can be simple and free to author. There are several good programs that let you draw images and save them as SVG, including Adobe Illustrator and Inkscape (a free drawing app that works on most platforms). But if you want to get your hands dirty, you can dig in and create shapes just by typing out the code; this is how most programmers tend to do it, because it lets you control how the drawing behaves according to scripted instructions. If you want to see how someone drew an image, you can always view the source code and, if permitted, create or change it to suit your needs, just as many people learn HTML and Javascript.

But SVG is not just shapes. Because it is intended to allow rich presentations in an accessible way, you can also use text in SVG, and even define your own fonts (though this is not yet as widely supported). Animation is native to the language, and in later versions (such as ones shipping on phones), audio and video are also available.

Finally, SVG can be used with HTML, to create a rich Internet document. Because it was designed from the ground up to be used with other languages (including styling languages like CSS and XSL), as well as on its own, it is truly a part of the Web, and as it grows more popular, the possibilities of the Web will grow even more.

Powered by WordPress