 Okay, I'm going to be talking about the future of SVG and web standards. I work on Inkscape. Inkscape uses SVG as its native storage format. And from that, I got interested in working. I got invited to work with the SVG working group on improving SVG in the future. So this talk is going to be about what's coming up in the next version of SVG. And then I'm going to also comment a little bit about web standards. I think it's important to understand how the web standards get created and what you can do to help that process. So I've got quick introduction, what SVG is, short history of SVG. And then I'm going to talk about the SVG2. And then, as I mentioned, I'll talk about a little bit about web standards. In case you don't know, SVG stands for Scalable Vector Graphics. There are basically two kinds of graphics. There's the bitmap graphics, which is basically just pixels being turned on and off. And they're vector graphics, where you define a line by defining two points. And I want to have a line from this point to that point. And that's scalable. You can change the size, make it bigger, make it smaller. And it's always going to have the same accuracy. So it's quite advantageous. Now, in real life, all displays, in fact, are raster devices. So the real difference between a bitmap graphic and a vector graphic is at the point when the rasterization takes place. With SVG, it takes place at the last, or vector graphics in general, it takes place at the last moment when you're about to display it. When you know what your resolution of the screen is going to be. So you can see, I'm missing a figure there. When your screen resolution is the same as the resolution of your bitmap, there's no real difference in the two methods. But as soon as you enlarge something, then you can start seeing a bitmap, you can start seeing the pixelization take place. Okay, where can you find SVG used? Well, right now, all the major browsers support it, natively. It's been used in mobile phones for quite a while. Even before smartphones came along, it was being used. Actually, a special version of SVG was being used called SVG Tiny, which had less demands on the processor in the phone. Drawing programs, as I mentioned, Inkscape uses it as its native format. One thing that surprised me to learn is that most TV set-top boxes use SVG. eBooks, EPUB 3, specifies that SVG is one of the formats that you can use for images. It's used in some other strange places. Plotplotters and cutters can be driven using SVG. And there's an interface from Inkscape that drives this thing called an egg bot, which allows you to draw patterns on eggs. It's used in mapping. Of course, it's very useful in mapping because you want to be able to change scales. They're interested in using it for document storage because it's an open standard. That's very easy. It's XML, and I'll talk about that in a second, which makes it easy. Even if SVG is no longer being used in the future, you can easily translate the XML into whatever the next new best thing is. And one interesting talk in a conference I went to a couple years ago was someone interested in using it for graphics, for braille, for blind people, it can be able to feel things. You would have a device that raises up parts that you can feel with your fingers. Okay. A little short history, SVG is based on PGML, which is derived from PostScript and VML from Microsoft. It was basically taking the features of those two things and merging them together. And it uses XML. XML stands for Extensible Markup Language, which is interesting because you can then mix, if you have different XML specifications, you can mix them together because they have namespaces. It's very easy to do that, put MathML and SVG inside an XHTML document. It's easy to parse. It allows round tripping between formats, something that you can't do with HTML. And it can be styled with CSS. And so here's an example of a very simple SVG file. I guess, basically, you list the namespace, the size of the document, the width and the height. And then you have a circle. You define the center of the circle, the radius. And you say, you want the field to be red. See, the alignment isn't quite the same as on my screen. You have attributes. And you also, those things like fill, you can also determine, they're specified the field using style, which you can then change using CSS. SVG is a W3C standard. It was, SVG1 was published in 2001. SVG1.1 in 2003. SVG1.2, there's a draft in 2005, but it was never published. So what happened? Well, politics got in the way. Adobe bought Flash. Adobe was the primary mover behind SVG. And when they bought Flash, they no longer had any interest in supporting SVG at all. Also, Microsoft ignored SVG completely. All the other browsers started to support SVG, but Internet Explorer didn't until version nine. And a W3C was going through a rough period of time. They stumbled with the conversion of HTML, was supposed to be changed into XHTML, which is a better format for parsing and for being able to mix standards together. And well, Microsoft's IE6 wasn't interested in something new. Well, more recently, the other browsers got together and said, well, this move to XHTML isn't working. Well, nothing's happening, but we have new and new demands on what we want to do. And so there was a group formed, what WG? Which basically abandoned the move to XHTML. But they did include SVG and MathML in the HTML5 specification. Even though SVG and MathML are XML, they have special ways of fitting it in even without having the namespaces. And more recently, Adobe has given up on Flash. Adobe has come out strongly behind HTML5. And Microsoft finally supports SVG. So the interest in SVG has really grown recently. And in 2011, SVG 1.1, second edition came out. It was basically a maintenance version, lots of bugs fixes. And now we're ready to move on to SVG2. SVG2 is rapidly being developed. There's a lot of activity. The working group has expanded. They're more on the phone calls, we have weekly phone meetings. There are a lot more people on those phone calls than there were just two or three years ago. There are 45 members in the group with an active core of about 10. There's active participation by Adobe, Canon, Google, IBM, Inkscape, Institute Telecom, a French university. Or Institute, Mozilla, Opera, and the W3C itself. And there is some participation, although not quite as active by Apple, KDDI is a Japanese phone company and Microsoft. That's the thing that's a comment about this group now. It's dominated by browser vendors and it's HTML, CSS biased. Many members also belong to the CSS working group, which is much, much larger and much, much more active. And the comment I want to make is that most, if not all, members would not, I don't think would consider themselves to be designers. And I think this has an effect on what gets put in to the specification. So what's happening with SVG2? Well, SVG2 is basically SVG 1.1 being ripped apart. It's ripped apart into an SVG2 core and lots of modules that are being shared with CSS. And there are possibly a few modules that will be orphaned like SVG fonts. I'll talk about that a little more in a minute. This is a good thing in that the modules that are shared with CSS are more likely to be quickly incorporated into browsers, such as CSS3 colors, which allows you to specify colors using an HSL value. That's all right, you can already do that. Even in SVG, you can do that in the browsers, at least the ones I tested. Although being incorporated into the CSS and being used in HTML, it doesn't always necessarily mean that you can use it in SVG yet. SVG is a low priority for most of these browser, probably all of browser vendors. Their main focus is HTML. So just because something from CSS is available in HTML, it doesn't mean it's available in SVG yet. But hopefully it will be soon. In one case of that is 3D transforms. You can do 3D transforms in HTML. You can make your boxes rotate and do all kinds of fancy things. But you can't do that natively in SVG yet. This is also a bad thing because CSS HTML interests dominate. The SVG group can't just make changes by itself. Last week, due to some problems with Inkscape, I brought up the problem of image rendering. Right now, when you take a bitmap and you scale it up, the specification says that you have to use some kind of fancy algorithm to scale it up. Suppose you have some bitmap art, you end up with it all blurred when a lot of times you want to maintain its blocky nature. And you can control that kind of with image rendering by misusing it. Well, I brought up the group and found out when I was doing that that actually image rendering has been taken over by a CSS image specification. So we can't just go in and change it and add this blocky thing. Now, they're doing that, but it's going to be a year or two years before it's going to be released. We can't just put it in the spec now and be done with it. So there's also some problems with breaking things apart. So what is SVG2 going to look like? Well, there's the core, as I mentioned. There's CSS animations, which are not smile-based. Smile is a way of animating things that the SVG animation isn't exactly, native animation isn't exactly smile, but it's based on smile. So the way you're going to animate SVG is up in the air in the future. You can always use JavaScript, et cetera, but then you get problems with security issues, et cetera. It's not always useful. CSS backgrounds isn't really part of SVG, but uses SVG. You can specify backgrounds in CSS using SVG now. CSS color I already mentioned. CSS compositing and blending. They've taken the modes for blending and compositing out of SVG and putting them in a separate specification. Exclusions and shapes. These are used for flowing text into regions or excluding text from a region. And hopefully that will replace flow text, which is something that was in the SVG 1.2 specification which never got adopted. Inkscape actually does support flow text, but if you don't export it as regular text and you try to view your Inkscape SVG on a web browser, you're not gonna see the text. CSS filter effects, for example, blurring things, making a drop shadow that's been removed from SVG is now in its own specification. CSS fonts, the way of specifying a font. It's not the same thing as SVG fonts. So let's talk about SVG fonts as the actual design and being able to animate the fonts and do all kinds of crazy things with them. This CSS fonts is more about specifying, I wanna use this font and if this font isn't available, fall back to this font, this character's not available, or maybe I wanna use all caps or something. That's in the CSS font specification. Image values and replacement content. Masking, I'm getting short on time so I'll have to go a little quicker. Text decoration that is underlining, overlining, things like that. Transforms, those 3D transforms, like perspective transform that you can now do in HTML, that's all defined in CSS transforms. And web fonts, web fonts, fonts that are being downloaded. There's an effort to put SVG inside of the true type fonts. And the reason for doing that is internationalization. It's a bit complicated, you can ask me later, I guess I don't have time to go into that. So let's go to the SVG two editions. The first one is solid color element. This allows you to have custom palettes that you can then change in the future time. Inkscape simulates this by using one-stop gradients, but you can't then use that color everywhere. You can't use it, for example, on gradient stops. In CSS, you can style things with color, but you need to have a different, if suppose you wanna style the border, the stroke of an object with the same color that you use for a fill of a different object. You can't do that easily in CSS right now. So having a solid color element in SVG allows you to do that. Flexible paint border. In SVG 1.1, the stroke is always on top, which in the case of, if you wanna have a stroke around a letter, it doesn't work so well. It's better to have the fill on top and the stroke underneath. So that's a change. SVG 1.1, the stroke is always evenly placed around the edge of an object, half in, half outside. It'd be nice to be able to specify, I want it all on the outside, all on the inside. Well, it turns out that this is actually being deferred because there's nobody working on it. But so if you want this, you should holler at the SVG working group. Holler. Okay. Not just at me, though. Arc line join. There are three traditional ways in PostScript, PDF, whatever, for joining lines together. But if you have curves coming together, none of those three are really, and you want something sharp, none of those three really work well. So there is this new arcs line join. It came out of actually, some work in some of it, but I didn't escape. Oh, that one was black, that one was black. Common ways, hatches, common ways to shade shapes, technical drawings is to use hatching. You can simulate this by using patterns in SVG. You have a pattern and you repeat it over and over. The patterns are subject to anomalies at the boundaries and also the problematic for those people using SVG for plotting or engraving because you don't want the pen to be going up and down, up and down all the time or the engraver to go up and down all the time because that'll leave little defects. One big one. Finally, we'll be able to have automatically a marker, in this case the arrowhead, inherit the color of the stroke that's attached to. Another problem with markers is suppose you've snapped a line from here to here on your drawing and now you wanna put an arrowhead on and you want the arrowhead to point right at the end of your line where the line sticks out a little bit. So you can bring your line back a little bit but then it's not being snapped to the same place. So marker cutouts are in the specification so you can cut out a region where you don't see the path so the head of your arrow will be sharp without having to worry about snapping, getting things just lined up. Marker placement, you'll be able to add, right now you can add markers at the nodes, these pink circle, places where there are pink circles. You'll be able to, in SVG 2, put them in the center of a line or at a fixed distance along a path. Of course, my favorite is mesh gradients. A mesh is made up of a whole series of these patches. You define the colors at the corners of the patches and then the color inside gets diffused, diffused in. So here's a petal from a flower showing a patch. There was a pepper here. Two peppers and one was done as meshes and one was done as a photograph and you were supposed to be able to tell which is which. I've actually patched Inkscape as a test bed for meshes and in about an hour I was able to get a very nice looking pepper and without it wasn't buggy and with some improvements I had in mind that you probably five, 10 minutes, you could make a nice pepper. Now, there's some problems that I'm facing that give you kind of an idea of some of the technical things you face when you're working on a standard is, here are some, one minute left, here are some linear meshes or linear gradients and the red shows the profile, the color profile and what you'll notice especially in this one here is it looks a brighter where there is a sharp, sharp change in the gradient of the mesh. This is called mock banding and it's a problem that you see, you see even more when you start working with patches you get these little crosses. Well, it turns out that Adobe and Coral draw, what they do is they smooth the meshes and they're actually exporting when they export to PDF because PDF does include these meshes in there. They actually export an eight by eight patch array and if you look very closely at their images you can actually see this eight by eight array and that's something that we'd like to void in SVG and Adobe's, we've asked Adobe and they've said they're gonna look at it whether they can publicly tell us their algorithm and we've guessed what it is with, you're missing an image there, sorry. Okay, so that's the SVG two and I'll go quickly two slides over CSS animations, CSS color, I guess I'll skip this, these things, these are some things that apply, CSS things that apply to SVG. What's missing from SVG even after all this? Flowed text, well maybe we'll get that. Pagination, people would like to have multi-page SVGs, gradients, long strokes, connectors. In the specification already the browsers refuse to implement our SVG fonts, Firefox just simply refuses to implement them and Internet Explorer follows Firefox and this says, well Firefox doesn't do it, we don't have to do it. Also, Internet Explorer refuses to animate, to implement small animation believing that this new animation is the way to go. There are a few other things, I'm not gonna skip because I wanna get to the procedure of how SVG process works. SVG Working Group has created a list of requirements based on public input, the inclusion into the SVG2 specification is dependent on someone in the group taking responsibility for that feature and sometimes you can help, even if you're not a member of the group, if you help write up or say that you document exactly what you want and do a little work, it'll be very helpful. Once it's in the specification, tests must be written and there's a multi-step approval process to get actually released. And now the last thing I wanna stress here is all specifications must have, features must have at least two conforming implementations or they're dropped out of the specification. And since the browser vendors are most active, they're most likely to provide those implementations. And the problem here is we only have a few left. We have Gecko, Presto is gonna be replaced, Trident, Microsoft has actually come out and said they're not gonna do any more SVG work for a while. They'll see what other people do, so you can't count on them. There's WebKit, so that's only two left and you need to have both of them to implement something. And then now we have Blink, so maybe that helps out a little bit. There's some other implementations, but their problems, you know, I can escape those only static stuff. So what you can do, if there's something you want or need, you need to talk to the SVG CSS HTML working group members. You can join their mailing lists. You can submit comments on the drafts. The drafts are publicly available. The newest working draft was just released yesterday for SVG. And you need to tell the browser vendors what you want and tell Adobe. Adobe is very interesting in this because new stuff means they can sell new software to, you know, they're very seriously behind a lot of these things. So, okay, that's conclusion. So it's an exciting time for SVG. Thank you. Thank you.