SVG File Setup and Use

On This Page

Introduction

We can create SVG files using simple text editors. SVG files are just plain text files that browsers render as images, so to start off on your SVG journey, you just need the ability to create and edit plain text files along with comfortability in navigating and editing text files with your screen reader.

Here are some common and accessible text editors that you can use to build and edit your SVG files:

Document software like Word, Pages, or Google Docs can work in a pinch, but it's important to be able to export that written text out as a plain text file. Rich text or proprietary file types will not work for SVG output.

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 your text editor of choice, 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.

SVG Template File Code

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 width="850" height="1100" 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 are 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!

Note: Older implementations of SVG needed the 'version' attribute written within the opening SVG tag, written as version="1.1".. With all modern-day browsers, this version attribute can now be omitted since the browsers ignore that attribute entirely when interpreting the SVG. We only need that attribute if we are building SVGs for a much older system or giving the SVG to an app that is expecting a version number.

For our purposes here in creating and outputting tactile graphics, the version attribute can be left out entirely.

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. Using these values, we can start understanding the spatial placement of different values for our shapes appearing on the canvas.

Working in Millimeters and Other Physical Units

Although SVG coordinates are always relative, it is sometimes useful to think about your drawings in real-world physical units such as millimeters or inches, especially when creating graphics intended for print or tactile output.

SVG allows this by letting you assign unit types to the width and height attributes of the opening <svg> tag. Common unit types include "mm" for millimeters, "in" for inches, and "px" for pixels.

It is important to understand that these unit types do not change how the drawing itself is written. All shape coordinates, path commands, and measurements inside the SVG remain unitless and relative. The width and height units tell the browser or output device how to map those relative values onto physical space.

For example, the following SVG defines a canvas that is 210 millimeters wide and 297 millimeters tall, which corresponds to an A4 sheet of paper:

<svg width="210mm" height="297mm" xmlns="https://www.w3.org/2000/svg">
</svg>

Within this canvas, coordinates still start at (0, 0) in the upper-left corner and increase to the right and downward. A shape placed at x="105" and y="148.5" would land in the center of the page, because those values represent halfway across and halfway down the defined canvas.

Some authors prefer to think directly in millimeters when placing shapes, while others prefer to think in abstract units or dots per inch and let the output scaling handle the conversion. Both approaches are valid, as long as you remain consistent throughout a file.

A common and reliable workflow is to draw using a simple abstract coordinate system, then use the width, height, and viewBox attributes together to scale the drawing precisely for the desired physical output size.

Regardless of which approach you choose, avoid mixing unit types within the same file. Pick a mental model, stick to it, and let SVG handle the final physical output.

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.

Note the lower camel-case way viewBox is written, with the letter B in Box being uppercase. When adding this attribute to your top SVG tag, make sure that it is written in this case, otherwise browsers may not interpret it correctly when opening your drawings up and getting them ready for tactile output.

The viewBox attribute takes four arguments and looks like this when incorporated into the SVG tag:

<svg 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 the 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.

Note: Make sure that you keep the width and height ratio equal to the ratio made in the viewBox width and height! Otherwise your final output will get stretched or squashed.

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 set to US Letter output at 100dpi, and then you'd only have to change the width and height attributes later on to control the output scale of your drawing:

<svg viewBox="0 0 850 1100" width="850" height="1100" xmlns="https://www.w3.org/2000/svg">
</svg>

Scaling for Google Chrome Output and Print

As previously mentioned, we try to think of our designs and units as being created in 100 dots per inch. This makes the math fairly easy with round numbers to use when placing shapes on a canvas. That's all fine and good for the file, but it turns out that browsers and graphics programs all interpret SVG files in different resolutions.

Google Chrome renders SVG files at 96 dots per inch.So instead of representing a sheet of US Letter paper as 850x1100 units, 96dpi changes it to 816x1056 units. We no longer have nice, round numbers, and you'll need a lot more math to make adjustments to your shapes. When designing SVG for digital output, this resolution doesn't matter as much, but it does become extremely important when we are outputting to an embosser or other tactile methods.

When recently making braille business cards in SCG, I was trying to line up my designs with a sheet of perforated Avery business cards, making my braille and designs land perfectly on each of the 10 cards in the 8.5x11" sheet of card stock. However, when opening my SCG in Chrome, my scaling kept getting messed up, and none of the numerical changes I'd make in my code made sense when having it rendered visually and embossed onto paper.

This is where I discovered the 96dpi versus 100dpi discrepancy in Chrome. By designing a drawing using inch units or our established 100dpi units, I was able to use the viewBox to set the canvas size and the units I wanted to draw in, and then used the width and height values of the SVG attributes to output at the 96dpi 816x1056 values. This method will work for whatever DPI you need to output for print. Here's a quick table of some of the letter paper widths and heights based on DPI:

DPI Values for Print and Tactile Output
DPI US Letter Width and Height in Portrait
72dpi 612x792
96dpi 816x1056
100dpi 850x1100
150dpi 1275x1650
200dpi 1700x2200
300dpi 2550x3300

Set these values for your SVG width and height to output a file at the right dimensions to be converted into the corresponding DPI when being scaled for printer output. Here's a code example of the opening SVG tag set up for US Letter in Portrait for Google Chrome embossing output:

<svg version="1.1" viewBox="0 0 850 1100" width="816" height="1056" xmlns="https://www.w3.org/2000/svg">

Testing and Debugging SVG Code

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

Google Chrome, Safari, and Firefox do 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 or any of these can prevent your image from rendering correctly. Double and triple-check your code and take full advantage of the browser debugging features 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.

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