Ceci est une ancienne révision du document !
Over the past six years, this series has detailed just about every part of Inkscape, from basic shapes through to more complex features such as filters and path effects. With nothing more to cover, it’s time for this column to take a sharp turn from its previous tack: I’m going to look at how you can use graphics you’ve created in Inkscape on the world wide web.
On the surface, this might seem like a simple task – worthy of an instalment or two at most. But SVG is unlike any other graphics format; its XML heritage lends it to the same kind of manipulation with CSS and JavaScript as HTML, allowing for graphical tricks that go way beyond simply displaying a static image on a page. At the same time, you still have the option to treat SVG as a dumb image format, if that’s a better fit for your requirements.
Broadly speaking, there are four ways to include an Inkscape-created image in a web page. Each has its own pros and cons, which are outlined in the table shown above.
The first method is to simply avoid the whole SVG question entirely and export your image to a PNG file – possibly even converting it to a JPEG afterwards to reduce the file size, if the image doesn’t require transparency. The resultant raster image can be included in a web page via an <img> tag, used on social media sites or blogs, and generally be treated the same way as a photo from a phone or digital camera. Because you’re effectively creating a snapshot of the image as it appears in Inkscape, you also don’t have to worry about missing fonts, flowed text, or mismatches in browsers’ rendering engines. The downside is that the exported raster image is no longer infinitely scalable in the same way as a vector image. You also lose any concept of the individual objects that made up the image, so it’s not possible to manipulate them individually using CSS animations or JavaScript.
The second approach relies on the fact that most modern browsers do a pretty decent job of rendering SVG – so why not just use the SVG file directly, rather than converting to a raster format first? This is as simple as referencing an SVG file in your <img> tag, rather than a PNG or JPEG. Because the internal structure of your SVG is preserved, the browser knows about individual objects, so can animate them using CSS. In theory it could also allow JavaScript, but that’s prevented when using images like this, for security reasons.
What does security have to do with an SVG image, you may wonder. Consider that many social media platforms, forums, and other websites, will let you upload your own SVG file, then expose it to other people on the site by using an <img> tag. This would effectively give a malicious user a means to run their own JavaScript under the guise of the hosting website. The code could capture user’s keypresses, spoof a login dialog to record passwords, or redirect the user to another site entirely. Given that being able to upload an SVG file to a site and have it rendered as an image is generally a good thing, but that unfettered permission to run JavaScript in such a file could easily be abused, browsers take the sensible approach of allowing CSS animations to run (giving SVG an edge over raster images), but disallowing any JavaScript.
Unfortunately this method does come with one big drawback – though it’s a problem that diminishes every year. Because you are relying on your browser’s rendering engine to draw each object in your image, you no longer have complete control over the appearance of your image. For simple drawings, this isn’t generally a problem. But add in more advanced features, such as filters, and the output of the browsers begins to diverge.
Text rendering is a particularly significant problem. If the person viewing the image doesn’t have the same font installed on their machine that you used to create the document in the first place, it will be replaced with a different font. In HTML, this can be annoying, but usually the browser adjusts the page layout a little and no real harm is done. In an image format, however, it can be much more of a problem. Consider something like a comic strip: if the text is rendered at the wrong size it might not fit the speech bubbles; if it’s rendered in a different font it could change the feel of the narrative entirely. For this reason, I post all my comic strips as PNG or JPEG images, and link to the SVG files separately where I want to make the source files available for people to download.
The third approach is essentially another way of linking to an SVG file, but this time it uses the <object> element rather than an <img>. Whereas forums and social media sites are happy to expose a user’s file via an <img> link, they tend not to do the same via <object> – so, if you want to take this approach, you need to be able to edit the underlying HTML directly. This usually implies that you are creating content for your own domain, rather than just uploading something to a third-party site. What you gain from this extra requirement is an enhanced level of trust from the browser, allowing JavaScript in your image to execute. With sufficient knowledge and experience, it’s even possible to create two-way interactions between code on the page and in your image. But, again, you’re also at the whim of the browser in terms of the final rendering of your file.
The last approach is a relatively recent option. For years, SVG was neglected by the web developer community, largely because Microsoft refused to support it in earlier versions of Internet Explorer, at a time when it commanded the majority share of the market. But with later releases, Microsoft softened their stance, adding SVG support and paving the way for SVG to be promoted to a first-class citizen in the world of HTML5. Now, you can put a chunk of SVG code directly into your HTML and it will just work. And if you’re hand-coding your SVG, you no longer have to concern yourself with the complexities of namespaces in XML – just use the SVG tags in the same way as you would HTML.
With this last method, the SVG is a direct part of your web page, so writing code to manipulate the image is much simpler than with the <object> approach. But it does mean that your SVG code is right there in the middle of your HTML. If all you’re doing is drawing a couple of simple objects, that might not be so bad, but including all the code from a complex drawing can quickly overwhelm the rest of your page, making it harder to work with the surrounding HTML. And, once more, your browser’s rendering engine might make poor work of your image.
Enough theory, let’s put it into practice. Next month, I’ll describe how to use <object> and inline SVG, but, this time, we’ll deal with the <img> methods. Begin by loading a simple image into Inkscape, or creating one from scratch if necessary. I’m going to work with this basic circle (the square around it is the Inkscape canvas):
Let’s export this to a PNG image via the File > Export PNG Image… menu item. This opens a dialog in which to set the details for the export:
I covered this dialog way back in part 12 of this series, but, for the purposes of creating a PNG to use online, you can ignore many of the options. You do need to decide what to export using the buttons at the top: usually this will be the entire page, the entirety of your drawing (which could be larger or smaller than the page), or a rectangle that encompasses the currently selected objects. I’ve chosen to export the whole page, as I want to include a little bit of blank space around my circle.
Now comes the most important decision: how big do you want your image to be? This is set in the Image Size section, by adjusting the image dimensions or dpi (dots per inch). For web use, you can generally ignore the dpi option and go straight for setting the width and height in pixels. If you’re creating an image for a profile picture or banner ad, you’ll usually be told the dimensions your graphic must be. Note, however, that you can’t set these fields independently, so you’ll either have to create your design to the right proportions, or export a larger area that you can then crop in a bitmap editor such as The GIMP or Krita.
The last setting required is the filename to export to. Click the Export As… button and navigate to your destination folder in the file selector. Enter a filename in the selector, making sure it ends in “.png”, and then use the file selector’s Save button to return your selected location and name to the export dialog. Despite the name of the button, this won’t have saved a PNG file anywhere; it’s just saved the export location. In order to actually save the file, you have to click the Export button.
You should now have a PNG file on disk that can be uploaded to just about any site that accepts user images. If you want to use it in your own HTML page, that’s easy too. If you’re already familiar with writing HTML then you almost certainly know how to link to your image. But if you’ve never written a line of HTML in your life, why not give it a try now – it’s not as tricky as you might think. In a text editor type the code shown below.
Modify the “circle.png” string to suit the filename of your own PNG, and save the document into the same directory as the exported image, making sure to give the filename an extension of “.html”. Open the web browser of your choice, press CTRL-O to open the file selector, and load your HTML file. You should see a text heading with your PNG image displayed below it.
That wasn’t too tricky, was it? Linking directly to an SVG file is just as simple. If your original Inkscape file isn’t in the same directory as the HTML file, use File > Save a Copy… to put a copy of it there. When you look in the directory you should now see your HTML file, your exported PNG, and an SVG file. To get the latter to appear in your web page, just add the following lines below the existing image link:
<h1>IMG tag (SVG)</h1>
<img src=“circle.svg”></img>
Save the file, switch to your browser, and press F5 to reload the page. You should see both your PNG image and the SVG version. There’s a good chance that the images aren’t the same size, but SVG files are scalable so we can fix that easily. Given that my PNG was exported at 250px in width, I can modify the <img> tag for the SVG file to set it to the same:
<img src=“circle.svg” width=“250”></img>
Another press of F5 in the browser and you should find that both images are the same size. But what if we wanted them both to be larger? Try setting a width attribute on both of them, with a value of 1000 or more. Notice how blocky the PNG becomes, whilst the SVG is still rendered as smoothly as possible. That’s the main advantage of using an SVG file in a web page instead of a PNG.
Linking to an image via an <img> tag is a common way to display user-submitted images on the web. But, when coding your own pages, images are often used in other ways as well, typically via CSS. You can use an SVG file wherever you would usually use a PNG in these cases. For example, let’s fill the background of our web page with copies of the SVG file using this chunk of CSS, inserted between the </head> and <body> sections of the HTML code:
<style>
body {
background: url("circle.svg");
background-size: 50px;
}
</style>
Reload the page to see the result. As a rule, modern browsers will let you use an SVG image wherever a raster is allowed. But although the browser might be happy to do that, many websites still only let you upload pure raster formats such as PNG, GIF and JPEG. If you write your own HTML you have full control over what formats to use, but if you’re trying to upload an image to a third party site you may find your options limited. If you can use an SVG, though, I encourage you to do so. Only by ever more SVG content making its way online will browser vendors have an incentive to provide better support for the format, and the SVG working group have a chance to introduce more of the new features that would make this useful format even better.