SVG File Setup and Use

On This Page

Introduction

SVG files are written in XML, and the syntax is similar to HTML and CSS, but pay close attention to how shapes and objects are closed. The files themselves are text files that have the ".svg" file extension; when saving out from notepad++, TextEdit, or whatever you are using as a text editor, just add the extension after your filename and it will become an SVG file.

While the drawings/graphics can exist as their own files, they can also be written inline within HTML documents, provided that all the code is wrapped within the <svg> tags.

It's recommended that you make a template file with the following code so you always have the correct SVG tags ready for your next project. Just open your template, save it as another file, then start writing your drawing between the SVG tags. Copy and paste this as your template file:

<svg version="1.1" width="1000" height="1000" xmlns="https://www.w3.org/2000/svg">
</svg>

The common elements of an opening <svg> tag is the SVG version, the width and height of the canvas, and that odd looking "xmlns" attribute that contains a URL. This URL establishes the SML "namespace" for the SVG, meaning it tells a browser that everything within the SVG tags is meant to be considered SVG XML code and to not think of it as HTML.

Important:This xmlns attribute is required for our SVG files for browsers to render them as images when it comes to getting them set up for embossing/printing. If it is missing from your file in the initial opening SVG tag, it will not render in the browser and you will be sad.

Just adjust the width and height to whatever canvas size you want to use, and off you go!

Sizing and Units

All units in SVG code are relative units, meaning they adapt into whatever units are being used by the device they are being viewed on. It's generally alright to think of them as pixels, but since these graphics can scale infinitely up or down, they could also be understood as millimeters, inches, feet, etc.

You can define any unit type that works for your particular project just by using the correct unit abbreviation. "px" for pixels, "in" for inches, "mm" for millimeters, and so on. Leaving out a unit abbreviation just leaves the space in an entirely relative space.

Embossers can vary in print resolution, but 100 pixels per inch can be understood as a standard. If your canvas is 400 SVG units wide, this can equate to 4 inches across a page when embossed.

The entire canvas can be understood as one quadrant of a graph. Points and attributes can be expressed as x, y coordinates. The origin of the graph is in the upper-left corner of the canvas; this is the coordinate point (0, 0). Note that while you increase the number for an X value to move it from left to right, increasing the number for a Y value will actually move it down in the canvas.

Viewbox and Scaling

While we are primarily concerned with building SVG files for tactile output, it's still good to know about another potential way to set up and manipulate your drawings for digital presentation.

The viewbox attribute can be added to the initial SVG tag at the top of the file, along with the width and height attributes. The viewbox attribute sets up the actual coordinate space origin and the height and width of the relative area which will contain your shapes and drawings. The width and height attributes control the overall output size of the final result.

Viewbox takes four arguments and looks like this when incorporated into the SVG tag:


<svg version="1.1" viewbox="0 0 400 500" width="800" height="1000"...>

The first two numbers within the viewbox quotes define the x and y origin numbers, in this case (0, 0) in the top-left corner of the canvas. The next two numbers define the actual width and height of the overall canvas area, so starting from 0, the width of the overall canvas will be 400 units and the height of the canvas will be 500 units.

In this instance, your entire drawing will want to be contained within those values. If you draw anything wider than 400 units or taller than 500 units, it will be cut off at the edge of canvas.

Why would we need this? Well, notice that the SVG width and height attributes are also there in the snippet. Note how they just happen to be double the sizes of the width and height values in the viewbox quotes. Doing this effectively doubles the scale of your entire drawing, sizing it up to a total size of 800x1000 without distorting and without having to redo all of the shape math and numbers.

It works the other way as well. Drawing within the viewbox parameters and then creating width and height values that are smaller than the canvas will output a smaller overall image. Consider this following code:


<svg viewbox="0 0 400 500" width="200" height="250"...>

Note that the width and height attributes are half the values of the viewbox width and height numbers. If you guessed that this is scaling down your original drawing by half, you'd be correct! This viewbox and width/height pairing and manipulation is a great way to control the overall output of your drawings when you need to create multiple different sizes of the same drawing, and prevents you from having to redraw everything.

Ultimately, if we are only concerned about one specific size for our files, we can stick with just using width and height, but adding in a viewbox attribute will give you more flexibility down the line. If you choose to go that route, grab this code snippet instead, which has the viewbox and width/height attributes equal, and then you'd only have to change the width and height attributes later on to control the output scale of your drawing:

<svg version="1.1" viewbox="0 0 1000 1000" width="1000" height="1000" xmlns="https://www.w3.org/2000/svg">
</svg>

Testing and Debugging SVG Code

As you develop your drawings, it's good to open the graphic itself up in Google Chrome or Firefox every so often to make sure that you haven't broken anything or introduced a bug.

Google Chrome does a great job at analyzing your SVG code and calling out any issues including the line number and exactly where in the line the error is occurring. Each error is separated by a heading element so they are easy to navigate should any be present.

Most modern text editors have a command to jump straight to a line in your document. Pressing Command+L in TextEdit on the Mac, for instance, opens a dialog box where you type in the line number you want to jump to and hit Enter, and the cursor will be focused right at that line.

The syntax, or the way SVG code is typed, is very important. One missing tag, one missing double-quote, an incorrect minus sign instead of an equal sign, all are necessary to have your drawing render without any problems. Double and triple-check your code and take full advantage of Chrome's debugging messages whenever possible.

Drawing/Layering Order of SVG Elements

SVG is written in code, and code is rendered in the order that it appears as it is read from top to bottom, left to right in your files.

This means that whatever shape appears last in the document closest to the ending </svg> tag will be rendered on "top" of all the other shapes that have come before it in the code if the shape position happens to place it over everything else under it.

Keeping this layering aspect in mind as you draw will be important when it comes to defining perspective, how foreground and middle ground shapes can obscure background shapes when creating depth, and how you use these layering techniques to construct more and more complex imagery.

Now that you have your SVG file template set up, let's start getting into some drawing!