SVG File Setup and Use

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.

Note: The SVG text files we're writing on this site use UTF-8 encoding. When creating a new plain text file, ensure that the file encoding is set to UTF-8 for full compatibility across browsers. This is a default for TextEdit, but double-check the preferences and settings of your particular text editor just in case.

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 tactile graphics project. Copy and paste the following code into a fresh plain text document with UTF-8 encoding, save the file with a .svg extension, and you now have your SVG template.

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

Just open your template, save it as another file, then start writing your new drawing shapes and elements between the SVG tags!

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.

If you happen to be writing inline SVG directly within an HTML file for a website, then this xmlns attribute is not needed, just don't forget it for anything you want to output as a tactile graphic.

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. Since a sheet of US Letter paper is 8.5x11 inches, this dot output resolution means we can think of the paper size as 850x1100 units; just multiplied the inches by 100.

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.

Going back to our sheet of Letter paper, this means that the top-right corner can be expressed as 850 over on x, but 0 on y, or (850, 0). The bottom-right corner can be expressed as (850, 1100), or 850 over on x and 1100 down on y.

If we divide those numbers by 2, or essentially go halfway horizontally across the paper and halfway vertically down the paper, we end up at (425, 550) which is smack-dab in the center of the paper. Using these values, we can start understanding the spatial placement of different values for our shapes appearing on 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.

An illustrative way to think about it is to consider each line of code as a separate shape made out of construction paper. Each line of code is you gluing that shape down onto your canvas in order, so the following line of code would be you gluing that next shape down onto the canvas, layering and stacking on top of the previous shapes you've glued down, and so on and so forth.

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.