Ceci est une ancienne révision du document !
There are still a number of changes and new features in Inkscape version 1.0 which I haven’t covered over the past few months. In order to get through as many new features as I can, this month I’m going to take a whistle-stop tour of some of the smaller features which don’t necessarily require complex examples to demonstrate. Hold on to your hats!
Y-Axis inversion I’ve said this before, and no doubt I’ll say it again: Inkscape is not a CAD program, despite offering some CAD-like features. Nevertheless, it has historically behaved the same way as most CAD programs – and even traditional paper-and-pen technical drawing – with regard to the position and orientation of its y-axis. Previous versions of Inkscape placed the origin (the 0, 0 point) at the bottom-left of the canvas, with the positive direction of the y-axis going upwards. If you come from a CAD, drafting or graphing background, this may seem perfectly sensible. But Inkscape is really an SVG editor, and SVG is a product of the web world. Web pages grow from the top downwards. Add some more paragraphs to your HTML page and the browser simply extends the scroll bar to let you reach them. SVG works in the same way, with its origin at the top-left of the drawing area (i.e. the browser window), and the positive direction of the y-axis going downwards.
This mismatch between Inkscape’s on-screen behaviour and the requirements of the SVG format meant that the coordinates of points viewed in the program would be different to the values that were actually stored in the file. For most users, this wasn’t a problem, but when using Inkscape to produce graphics that will ultimately appear on a web page, this mismatch could make life unnecessarily difficult, especially when trying to write JavaScript to dynamically alter the file within a web browser. With v1.0, Inkscape now defaults to the SVG standard for its origin and y-axis direction. Should this cause you any problems or confusion, you can revert to the previous behaviour by un-checking the “Origin in upper left with y-axis pointing down” setting in the Interface panel of the Edit > Preferences dialog.
Duplicating guides Version 1.0 introduces a means of duplicating an existing guide line. The behaviour of this differs between v1.0.x and the release candidate for version 1.1 (the full version of which may have even been released by the time this magazine is published). Let’s look at v1.0 first, where the change is rather frustrating and unintuitive. There’s a new “Duplicate” button in the Guideline dialog (opened by double-clicking on an existing guide). This duplicates the current guide, in-place, then closes the dialog. No other changes are made to the duplicate, regardless of what other parameters you set in the dialog. This can easily lead to confusion as it’s not always obvious that there are now two co-positioned guidelines. Double-clicking on the lines will open the dialog again, where you can make changes that will affect one of them.
Suppose, therefore, that you have a horizontal guideline and you wish to create two more parallel guidelines, with 10mm spacing between them. Here are the steps: • Double-click on the existing line to bring up the Guideline dialog. • Click the Duplicate button. The dialog closes. • Double-click on the newly duplicated line (which is on top of the existing line) to open the dialog again. • Enter 10mm into the “Y” field, check the “Relative change” box, and click the OK button. The dialog closes, but you now have two guides on the page, separated by 10mm. • Repeat all four steps, but starting with your newly duplicated and moved line.
Although the “Relative change” box remains checked between steps, the value in the “Y” field is cleared. This makes it frustrating to create a series of equally spaced guides. If you forget to click the “Duplicate” button before you change the value, you’ll end up moving your original guide by mistake. No amount of hitting Ctrl-Z will undo that mistake: you’ll have to reopen the dialog and move the guide by the opposite amount to get it back to where it started. Fortunately this feature has been improved in the 1.1 release candidate. In that version you simply open the dialog, put in your relative change, then press Duplicate (rather than OK) to create a duplicate guide with the movement already applied. Much simpler!
Filter Region size From a frustrating change to a delightful one. In order to reduce the amount of processing required when a filter is applied to an object, SVG includes the ability to set a finite boundary outside of which the filter is no longer calculated. For some filters – particularly those involving large blurs or offsets – the default filter region is too small, resulting in the edges of the filtered content being cut-off with a hard boundary. You can see the effect quite clearly at the sides of this heavily blurred circle.
It’s always been possible to adjust the size of the filter region, via the Filter General Settings tab of the Filter Editor dialog. But the four fields you’ll find there are less than obvious to anyone who hasn’t read up on the inner details of SVG filters. You’ll also have to guess – or find out through trial-and-error – what the best values need to be for your particular image. Set the filter area too large and you’ll slow down the rendering of your image. Set it too small, or in the wrong position, and you’ll see your filter being cut-off. With version 1.0, guessing the optimum values for these fields is a thing of the past. With a filtered object selected, switch to the Node tool (F2) and you’ll see diamond-shaped handles at the top-left and bottom-right of your object which can be dragged to directly adjust the filter region on the canvas.
Importing SVG files Inkscape v1.0 brings some more options when importing one SVG file into another, whether via File > Import, or by just dragging and dropping an SVG file from your file manager onto the Inkscape canvas. By default, a dialog will be presented offering three different ways to import the image, plus a couple of settings that have an effect on only two of the three choices. The first option will probably be the one most people use. It’s the same way that previous versions of Inkscape imported SVG images: by adding all the objects from the imported image as first-class, editable objects inside the existing document. Images imported in this way are essentially indistinguishable from any other elements drawn within the Inkscape document.
The second option embeds the SVG content as a base64 encoded string in an <img> tag. If those words are gobbledegook to you, then you’re probably not a web developer. In layman’s terms, it just means that the SVG content is stored within the file, but as a single image that can be treated much like a bitmap version of the vector image. Indeed, Inkscape actually renders it as a bitmap version, so zooming in, or scaling the image too large, can make it look blocky. More on that shortly. The third option links to the SVG file. Unlike the prior options, this means that the linked file can be updated outside of Inkscape, and the changes will be reflected in your Inkscape document. But it also means that moving the Inkscape file to another machine will also require the linked image to be sent, and the link potentially updated to reflect the new location of the file on disk. Inkscape also displays linked images as bitmap versions, so the same zoom and scale warning applies as previously.
Although Inkscape displays linked and embedded SVG images as bitmaps, it’s important to understand that the linked file, and the base64 encoded embedded content, are both still SVG documents in all their vector glory. For example, even the blockiest looking embedded SVG will look crisp and clean when the containing file is loaded into a web browser. When linking or embedding an SVG file, you do have some limited control over the bitmap that Inkscape displays as a proxy. The “DPI for rendered SVG” field in the import dialog lets you set the quality of the rasterized content. Higher DPI values will capture finer details from the vector content, which may allow you to scale or zoom with less obvious loss of detail. The “Image Rendering Mode” pop-up lets you select the trade-off Inkscape uses between quality and speed when rasterizing. Most of the time leaving this as “None (auto)” will be good enough.
Because the bitmap representation is just an artefact of the way that Inkscape works, and doesn’t affect the underlying vector content, it’s even possible to change the DPI and render trade-off after the image has been imported or linked. Right-click on the image and select Object Properties, or use Object > Object Properties. In the dialog that opens, you can modify the DPI setting or change the rendering mode – with even more options available than in the original import dialog. This means that any blockiness that appears as a result of scaling an imported SVG image can be addressed after-the-fact, so there’s no need to worry too much about which values you use when importing. The defaults for the import dialog are set in the Imported Images pane of the Edit > Preferences dialog (where you’ll also find the defaults for importing bitmap images). Should you check the “Don’t ask again” box in the dialog, then this is also where you need to come to re-enable it once you discover that the defaults don’t always suit your needs.
Mesh Gradient polyfill If you save an SVG image containing a Mesh Gradient (see part 59 of this series), Inkscape will now embed a JavaScript polyfill in the file. As I’ve remonstrated previously, browsers still don’t support mesh gradients in their SVG implementations. This polyfill goes some way towards addressing that shortcoming. When the SVG file is loaded directly into the browser, or is included within a web page in a way that allows JavaScript to run (i.e. via an <object> tag, or by inlining the SVG content), the polyfill code will execute, rendering a bitmap version of the mesh gradient in order to approximate the original appearance of the file.
The idea is to break the impasse that is preventing mesh gradients gaining browser support. The browser vendors won’t put time into their implementation due to a lack of files on the internet that use the feature. But few people put such files online because the browsers don’t support them. If you’re technically competent enough to be able to put SVG images online in an <object> tag, then I urge you to create something with mesh gradients and share it with the world. Only by increasing the number of such files out there can we ever hope to get native support in web browsers.
PNG export The PNG export dialog has gained an Advanced section which allows you to set a number of parameters for the exported file. Most users will probably never need them, so I won’t go into detail about them here, other than to point out that the “pHYs dpi” field is almost certainly what you’re looking for before opening a thread on the forum about how Inkscape PNG files don’t appear at the “correct” size in some other program. Unless you have a specific need to modify these fields, you can probably leave them as-is. They’re hidden in an Advanced section for a reason.
3-digit RGB values RGB colors are often denoted as 6-digit hexadecimal values. But a common shortcut in CSS is to provide just three hex digits, each of which is doubled to produce the final 6-digit (hex) version. So, a value of #1ca would be expanded to #11ccaa. Inkscape now supports entering three digits into the Fill & Stroke dialog to set colors, though the value that is actually stored in the SVG file will still be the full 6-digit version. The alpha (opacity) will be set to 100% (a value of 255, or #ff in hex), but if you enter a 4-digit hex value, this will be expanded in a similar way to produce both the 6-digit color and a 2-digit alpha value. So, #1cab would be expanded to #11ccaa and #bb.
Save as a template It’s long been possible to add to Inkscape’s set of templates by creating your own SVG file and putting it in the right place on disk. With version 1.0, the process has been made a whole lot simpler with the addition of a “Save Template…” entry in the File menu. Simply create the template you need, setting the page size and units, adding guides, and including some boilerplate SVG content if you wish, then choose the menu entry and enter a few basic details. Your template will appear in the “New from Template” dialog immediately – you don’t even need to restart the program.
It’s not all perfect, however. Although the creation dialog has a field for Keywords, there’s no indication as to how these should be delimited. From looking at the internals of existing templates, I believe that you need to use spaces between the words. Even doing this won’t make them searchable in the “New from Template” dialog, though. It appears that there’s a bit of a mismatch between the template files that Inkscape creates using this feature, and the code that displays them in the dialog. Existing templates store the metadata you provide in some XML elements whose names are prefixed with an underscore. Using the “Save Template…” feature stores them in un-prefixed elements. It’s possible to modify the XML content in a text editor, adding the underscores to make the template keywords searchable, but that really shouldn’t be necessary. I’ll be filing a bug report about this one. Even with this glitch, the ability to more easily create templates is a very welcome addition.
Removed features A few features have been removed from version 1.0 for various reasons. These are the main ones that you might notice: File > Import Clip Art: This feature used to allow direct downloading of files from the OpenClipart.org website, however the API that Inkscape used is no longer operational. The website does indicate that V2 of the API is in beta, so perhaps this feature will return in the future. Save As Cairo PNG: This option has been removed from the Save As dialog as it had limited functionality, and was often confused with the File > Export PNG Image option, which is much more capable. UniConvertor: Inkscape is no longer built with the UniConvertor library. This means that a number of third party file formats can no longer be opened or saved from Inkscape directly. If you do need to work with any of these file types a possible workaround would be to install the UniConvertor command-line tool and convert the files to the SVG format prior to loading them into Inkscape, or back the other way after saving.
Selection Sets: Despite being added in only version 0.91, the Selection Sets dialog has been removed. I described this feature in part 62 of this series, and I would rather have seen it polished and improved than dropped entirely. Performing some types of complex selections in Inkscape can still be tricky, and selection sets offer a way to combine several simpler selections to achieve the same result. Nevertheless, I doubt this dialog will be much missed by most users. When even the list of small changes fills a whole article, it’s clear that Inkscape development is continuing at a pace. The imminent release of version 1.1 will no doubt add to my list of topics to cover, but next month I’ll be continuing to describe some of the more significant changes in 1.0.x.