Ceci est une ancienne révision du document !
There’s a part of the Inkscape user interface that is so common, and so taken for granted, that you’ve probably never given much thought to it: the page border. Yet this seemingly mundane part of the display plays a vital role when it comes to creating SVG files for use online. By understanding what it represents, and how to manipulate it, you will open up some techniques that can make your SVG files far more versatile, even if they’re only being included via an <img> tag. By default, creating a new document in Inkscape will create an A4 page (210x297mm), displaying a thin outline to represent the page border, and a drop shadow to make it look a little more like a page of paper than a simple rectangle. I can’t say for certain if A4 is used as a default everywhere, or if there is a locale dependency that creates US Letter pages in the USA, for example, but either way, you get a default size and visible page border. Changing the page size is done via the File > Document Properties (Ctrl-Alt-D) dialog: you can either select one of the predefined page sizes or enter a custom width and height, with your choice of units. The bottom of the dialog also provides options to show or hide the page border and to display it without the drop shadow, if you prefer.
I’ve seen a few video tutorials where the presenter heads straight to this dialog to turn off the page border, but I think that’s usually a mistake. If you’re designing for print then having an idea of how your work fits into the page is essential. But the border is just as important for web work, as anything that is drawn outside it won’t be rendered by the browser. If you turn the border off, there’s a real danger that parts of your design might inadvertently fall outside it, preventing them from rendering as expected. The non-display, or non-printing, of content outside the page border, can be a blessing. If your design has to bleed off the edge of the page, it can be essential. You can also use the area outside the page to store rough designs, notes, spare elements, or the source objects for clones (particularly those with unset fills) – anything which you want to keep with your image, but don’t want to be visible in the final product. I’ve often used this capability to include Easter eggs in my comic strips – even to the extent of holding extra panels or even entire extra strips that can be found only by opening the original source file in Inkscape.
For many uses, the page size can natively be set in the Document Properties dialog, with no need to concern yourself any further. This sets the “width” and “height” attributes on the main <svg> which determines the default size that your image will be drawn in the browser. For an icon design, for example, you might set the dimensions to 32px by 32px, and that’s the size it will be rendered. But what happens when you want to use a different scale inside your drawing? Your drawing might be in metres or even miles, yet you still want it displayed at a reasonable size in the browser. For this, there is the viewBox attribute. The viewBox attribute is a list of four numbers, representing the x and y coordinates of the origin in the drawing, and the width and height of the drawing in “user units”. Let’s look at a couple of examples: <svg … width=“100” height=“200” viewBox=“0 0 100 200” … >
This one’s simple. The width and height of the image will default to 100px by 200px, and the coordinates in the drawing are mapped to the image on a 1:1 basis. If you draw a rectangle that’s 100 units wide and 200 units tall, it will fill the available space in the browser window (assuming you position it at the top left of your drawing). Let’s try another: <svg … width=“100” height=“200” viewBox=“0 0 500 1000” … > Again the image will render to a size of 100px by 200px in the browser. But the viewBox defines a different coordinate system. Now 500 units in the drawing map to 100px in the browser. If you draw a rectangle that’s 100 units wide and 200 units tall this time, it will occupy only one corner of the image (actually being drawn as 20px by 40px in the browser). To fill the image, you would need to draw a rectangle that’s 500 units by 1000 units.
Changing the x and y values lets you move the origin of your coordinate system. It lets you say “the origin for the browser (i.e. the point that’s used as the top left of the image) should actually be 100 units down and 50 units across in my drawing”. Another way to think of it is that the viewBox lets you create a viewport into your drawing of a specific size and location: everything inside the viewport will be scaled up or down to fill the image in the browser; everything outside the viewport will be cropped and left un-drawn. For use in a web page, this capability to render only part of the image lets us perform a rather neat trick. By changing the viewBox values, we can selectively display subsections of the file, letting us store multiple images in one file. This reduces the number of network requests needed by your page, in turn speeding up your site.
Consider this collection of four images – a star, a circle, a spiral path, and some text in the rather wonderful free font, Trump Grotesk Bold. I’ve drawn them in four sections of a tall, thin page that is 250px wide by 1000px tall (so each element occupies 250px by 250px). With the viewBox set to “0 0 250 1000”, we have a 1:1 mapping when the image is drawn in the browser. You can pretty much ignore the “Scale x” and “Scale y” values – they get set automatically by Inkscape as you change the viewBox fields. As you might expect, when I save this image and load it into the browser, I see all four elements, taking up a space of 250px by 1000px. But look what happens if I change both the page height and the viewBox height to 250: As you can see, the page border only surrounds the text. If I save the page and load it into the browser, all I get is a 250px by 250px image showing the text element.
If I now set the “y” value for the viewBox to -250, thus moving the viewport upwards, only the spiral appears in the page. Saving the file and loading it in a browser now only renders the spiral, hiding the other three elements. I’m sure you’ve worked out by now that setting the “y” value to -500 will put the page around the circle, whilst -750 puts it around the star. Now let’s just remind ourselves what the HTML <img> tag looks like to render this image: <img src=“views.svg”></img> Well that’s pretty terse and to the point. It just tells the browser to show the “views.svg” file using the width and height set in the SVG file, and displaying the default viewport set by the viewBox attribute. But we can append a little magic to the filename to tell the browser to override the default viewbox: <img src=“views.svg#svgView(viewBox(0, -750, 250, 250))”></img>
By changing the viewBox values in the URL we can therefore select a specific region of the image to display. In this case, it allows us to choose between one of several sub-images, making this approach ideal for files that contain multiple icons or logos. An alternative is to use viewBox values that focus on a particular part of your design, or cause some section to be zoomed in. That gives you the possibility of showing, for example, an overview and a detail view, both taken from the same image. Hard-coding the viewBox dimensions into the URLs does have one significant problem: if your image changes, such that elements are swapped or moved, you also need to update the HTML or CSS file containing the URLs. SVG has an answer to this problem as well: named views.
Named views are, as you might have guessed, a way of giving a particular set of viewBox values a name – that can then be referenced from elsewhere. Unfortunately, Inkscape has no specific support for them, except to expose the underlying code in the XML editor. But the syntax is straightforward enough that they’re easy to add via a text editor. They can go pretty much anywhere in the SVG file, but as they’re not visible objects in their own right, I prefer to keep them in the <defs> section where things such as filter and gradient definitions live. Named views can be thought of as viewBox definitions, so this location makes sense to me. Here’s an example of the top section of the SVG file above, once I’ve added named views for each of the objects to my <defs> (below). In this example, the viewBox attribute in the <svg> element is set to show the text content, but I could equally have set it to show all four objects, just a couple of them, a smaller part of one of the objects, or any other rectangular space in the image. This is the viewBox that will be used by default if nothing else is specified in the document’s URL.
In the <defs> section, you can see that I’ve also defined four <view> elements. Each of these has an ID that will be used to reference them later, together with a viewBox attribute. The IDs aren’t special: I’ve called them “textView”, “spiralView” and so on, simply to make it clear what they’re showing, but I could equally have gone for “fred”, “wilma”, “barney” and “betty” – had I wished to. The only requirements are that they are valid XML IDs, and are unique within the document. If in doubt, stick to plain text with no punctuation and you should be okay. Using your named view in an <img> tag is trivially straightforward – you just have to set the appropriate ID as the fragment identifier (the bit after the “#” character in a URL): <img src=“views.svg#spiralView”></img>
Of course there’s nothing to stop you referencing the same image more than once in a web page, with a different fragment identifier each time. You can also mix and match named views, the “svgView()” syntax, and the default viewBox. In this way, a single SVG image can easily be used to provide a whole host of icons and other images for your page. To finish off, here’s an example of an HTML document that uses the SVG image from this tutorial: You should now be able to understand how our single SVG image is used multiple times to give the final result: