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. Celui-ci est simple. Les largeur et hauteur de l’image seront de 100 px par 200 px par défaut, et les coordonnées du dessin formeront une image sur une base de 1:1. Si vous dessinez un rectangle de 100 unités de large pour 200 unités de hauteur, il remplira l’espace disponible dans la fenêtre du navigateur (en supposant que vous le positionnez en haut à gauche de votre dessin). Essayons-en un autre : <svg …
width="100" height="200" viewBox="0 0 500 1000" … >À nouveau, l’image est affichée dans une taille de 100 px par 200 px dans votre navigateur. Mais l’attribut viewBox définit un autre système de coordonnées. Les 550 px de votre dessin deviennent 100 px dans le navigateur. Si vous dessinez un rectangle qui, cette fois, est de large 100 px et haut de 200 px, il n’occupera seulement qu’un coin de l’image (étant dessiné réellement en 20 px par 40 px dans le navigateur). Pour remplir l’image, vous devrez dessiner un rectangle de 500 unités par 1000 unités. 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 pge 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, ex pxcept 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: