Ceci est une ancienne révision du document !
Inkscape development has certainly picked up in pace over the past few years, which is great for users… but not so good for volunteer writers trying to extensively document all the features of the application in a monthly column. So I have slightly mixed feelings about the recent release of version 1.3. On the one hand it comes with various fixes and improvements, and some really impressive new features. On the other hand, I have barely started documenting the new features in version 1.2, so my backlog of topics has now grown many times longer!
In an effort to catch up with the Inkscape developers, I’m going to use this article to briefly revisit the 1.2.x features I’ve covered and describe any changes to them in 1.3. Then from next month I’ll be describing the changes and additions that have taken place in either 1.2.x or 1.3, but documenting them as they currently look and behave in the latest version.
I strongly recommend all Inkscape users to download the 1.3 release. The best way to do this right now is probably to visit the project’s website at https://inkscape.org and just click on the ‘Download Now!’ button. Linux users have the option of downloading an AppImage file, or using a PPA. I’m using the AppImage, simply because I need to have multiple different versions available while writing this column, which is not so straightforward with a PPA.
Now, let’s revisit the 1.2 features that I covered in the previous few articles…
Icons and the toolbar
In FCM #188 I introduced some of the changes that had taken place with the main toolbar, and with the icons within the application. I also drew attention to the fact that (on my machine, at least) the symbolic icons still seemed to creep into parts of the UI, even though I had chosen a full color theme.
With 1.3 there have been few changes to the toolbar. It can still be resized, and individual tools can be shown or hidden via the Preferences dialog, as I described previously. In fact, the only significant change to the toolbar is the addition of another new tool – the Shape Builder – which will be the subject of a future article.
I’m also pleased to note that the symbolic icons have disappeared, and the icons in my UI all come from the high color icon set that I prefer (being a dyed-in-the-wool Inkscape user of old). Interestingly my 1.2.x versions also now show the correct icons. Perhaps running 1.3 has updated a common system file, fixing the problem more generally.
Snap controls
Issue #188 was also where I introduced the new Snap Controls popup at the top-right of the Inkscape window. I covered both the Simple and Advanced modes that are available in this UI.
Version 1.3 fails to fix my biggest gripe with this popup – namely that switching to Simple mode then back to Advanced resets all the many checkboxes to their defaults. I still feel that using a more hierarchical tree structure so that individual sections can be collapsed would be preferable to a forced choice between a minimalistic Simple mode that doesn’t adequately describe its settings, and a comprehensive Advanced mode that can be overwhelming.
Perhaps not for the same reasons, but it seems that enough other users aren’t happy with the new UI that the old Snap toolbar has been brought out of retirement for version 1.3. The option to switch to this mode isn’t available from the Snap popup, so isn’t as discoverable as it could be. Instead it’s hidden away in the Interface > Toolbars section of the Preferences dialog. Here you can select between Simple, Advanced or Permanent, corresponding to the two views of the popup, or the traditional toolbar.
It’s worth pointing out, however, that even with Permanent selected things aren’t quite the same as older versions of Inkscape. The program used to have a badly named ‘Custom’ view, which offered absolutely no customisation. One thing it did do, however, was to move the Snap toolbar from the right of the window to the top. When enabling the Permanent option in 1.3 you get the Snap toolbar on the right, but as the Custom view no longer exists, and the toolbar can’t be dragged to another place, that location is where it must remain. So if you’re in that small crescent of the Venn diagram of users that both prefer a snap toolbar, and want it at the top of the window, you’re still out of luck.
Color palette
In FCM #189 the subject of this column was colour selection. Specifically I introduced the new colour picker options in the Fill & Stroke dialog. Nothing much has changed in the dialog itself for 1.3, but there have been some changes in the Inkscape preferences related to the color pickers.
If you open Edit > Preferences then expand the Interface section, you’ll find a new pane named ‘Color Selector’ (this screenshot is from my British English installation, so uses the UK spelling of ‘Colour’).
The first control here isn’t new, but it has moved. I discussed it back in issue #190, when it lived in the ‘Interface’ pane directly. Basically it lets you switch between the old-but-classic method of changing color selectors using some tab-like buttons, or the new-and-compact approach of a pop-up menu. I prefer the former, as it’s more immediate and requires fewer mouse clicks, but if you rarely switch between selectors then you might prefer something that takes up less space in the UI.
The second control consists of a set of toggle buttons that let you turn the individual color pickers on and off. If you never work with a color management system, for example (that would be most Inkscape users, I suspect) then you may wish to disable the ‘CMS’ picker. And perhaps you’ve read enough of these articles over the years to know that, internally, Inkscape only supports RGB colors, so the ‘CMYK’ picker is really a bit of a lie that may not be terribly useful to you. Whichever combination of pickers you enable will apply whether you use the compact or traditional mode switch.
Version 1.3 adds a new picker to the options in the form of OKHSL. I’ll let you look up the details of that color model yourselves, but I think it’s worth enabling for most users. OKHSL has been specifically designed to try to maintain the perceptual brightness and saturation of colours when only the hue changes. Using this can make for more consistent gradients, for example, and may make it easier to pick different colors which have similar intensity.
OKHSL has now made it into CSS – and, by extension, is valid in SVG. It is also rapidly being adopted by browsers. Because Inkscape still uses 8-bit RGB values internally, much like the CMYK picker this is a bit of a lie – though this one is perhaps more useful to everyday users. Unfortunately, extending Inkscape’s code to be able to support true OKHSL values (and other color models now supported by CSS) is likely to be a huge undertaking, so I don’t expect that to happen any time soon.
In issue #189 I also talked about the changes to the palette, at the bottom of the main Inkscape window. Little has changed here, but version 1.3 does introduce a small usability enhancement which really does make a big difference. Compare these screenshots – from 1.2.2 and 1.3 – for an object with a black stroke and gray fill.
Notice that 1.3 shows an open circle directly in the palette swatch for the currently selected stroke color, and a smaller filled circle for the fill. These have been perfectly sized so that they are both clearly visible even when the fill and the stroke have both been set to the same color.
A subtle aspect of this feature is that the color used for each of the circles changes to contrast with the swatch color, ensuring that they never disappear from view entirely. Even more impressively, these indicators just do the right thing if you have multiple objects selected. If all the selected objects share a common fill or stroke color the relevant circle(s) will be visible. But where the fill or stroke are not common across all the selected objects, the corresponding circle won’t be drawn, avoiding any confusion that might occur if colors are similar but not quite the same.
Multi-page documents
The multi-page tool was added in version 1.2 and I covered it in issue #192. When first clicking the tool, the UI has changed a little:
The resize button (the one with four arrows) has been removed, which I find to be a rather odd choice. Previously this would either resize the page to fit the contents (if you had nothing selected), or to fit the selected objects. You can still achieve the same effect using the equivalent button in the Document Properties dialog – but that only works for the first page of the document, not the currently selected page. As far as I can tell, there’s no way to auto-size an arbitrary page to fit its content, which feels like a significant omission – or rather, removal – to me. If you do wish to use the resize button in the Document Properties dialog, a new addition is that right-clicking away from any objects on the canvas will open a cut-down context menu which now offers a shortcut to open the dialog.
One thing I didn’t like with the Page Tool’s resize button in 1.2.x was that there was no way to include a little bit of padding or spacing around the objects. If you used the button the resultant page would hug your content closely. In most cases I prefer a little breathing space between my content and the very edge of the page, but neither the button in the page tool nor the one in Document Properties offer that facility. So when I saw the new ‘Margins’ field in 1.3 I thought that, perhaps, that was the answer. Type a value in there, and the page would resize to suit the content (or selection), plus a bit extra for the margin. Alas, that’s not what it does at all.
If you type a number in that field and press Enter (tabbing out of the field doesn’t cut it) then Inkscape will draw a rectangle, offset by the specified amount within the page. You can think of it as being a little like a guideline, but rectangular – though it doesn’t toggle on and off when you show or hide guidelines. It can, however, be used as a snap target, so if you know you need to allow, say, 5mm at the edge of your design for your particular printer’s page handling, this can help you to avoid going outside the safe area. But it’s only a guideline, and doesn’t get factored in when telling Inkscape to resize the page.
Usually typing a single number in this box will suffice, but there may be times when you need different margins for each side of your page. For example, it’s common to require a larger margin on the inside edge of the page to allow for binding if you are producing some artwork that will be made into a booklet. You can enter several space-separated numbers into this field, in a manner that might be familiar to web developers from the similar shortcuts CSS allows. 1 value: This will be used for all sides 2 values: The first dictates the top and bottom margins, the second sets the left and right margins 3 values: The first defines the top margin, the second is used for the left and right, and the third is used for the bottom 4 values: Top, right, bottom, left 5 or more values: All but the first four are deleted
You may notice that the margin box on the canvas also has some circular handles at the center of each side (only shown when the Page tool is active). You can drag these to dynamically adjust the values. Alternatively, clicking on the icon at the left of the field opens a small ‘doorhanger’ dialog in which you can set these values:
You’ll notice there’s also a section for ‘Page Bleed’ at the bottom of that dialog. Expanding this presents a single field for setting a bleed value that is used for all sides of the document. Again, you have to press Enter (or Return) to apply this value – tabbing won’t do – and again this draws a guideline-like box which can be snapped to. In this case the box lives outside the page boundary.
You may not be familiar with the idea of ‘bleed’ in printing. It doesn’t matter whether we’re talking about a cheap inkjet in your house, or a huge industrial press that fills a warehouse, all printers are obviously mechanical devices. As such they have tolerances between components, parts can wear, and things can simply be misaligned from their perfect positions. If you want to print a solid background color in your design, therefore, keeping within the page boundaries could lead to a slightly offset print in which the white paper shows along one or two edges.
To compensate for this it’s common to create your design such that it ‘bleeds’ off the edge of the page – that is, backgrounds and other objects extend a small way beyond the page boundary so that even if the paper is a little misaligned there will still be content to print which will cover-up the problem. For commercial printing a bleed of 5-10mm all round is common.
Conversely, margins are often specified to ensure that your content is safe from being trimmed when the final print is guillotined, for example.
So with these fields, Inkscape makes it a little easier for you to create designs to meet common commercial requirements. Set them to the values provided by the printing firm, and design accordingly: vital parts of the design should all be within the margins, while solid backgrounds or objects that must run right to the edge of the page should be drawn up to the bleed line or beyond.
On the canvas, both the margin and bleed boxes on are extremely faint – so much so that I haven’t bothered providing a screenshot, as I doubt they’d be visible in the magazine! Currently there seems to be no way to change their colors, which may cause a problems for some users. When treated purely as snap targets that may not matter as much, but if you wanted to use them as general guides just to get a visual idea of the placement of your objects, they may not be terribly useful for some users, or with some designs.
On the subject of snapping, both these boxes are enabled as snap targets when the ‘Bounding Boxes’ option is enabled in the Simple snap menu. In the Advanced menu they’re handled by a single ‘Page margins’ option at the bottom – though when I tested this it was a little buggy, and I ended up having to switch back to Simple mode to get them to work again. With the Permanent snap toolbar there doesn’t seem to be a way to toggle them at all!
None of the modes let you enable snapping for margins but not bleed, or vice versa. When designing for print I often treat the margins as a ‘hard’ edge that I can’t exceed, whereas bleed is more of an advisory that it’s okay to go beyond. Therefore I’d rather be able to enable these separately, but it’s not a huge inconvenience either.
Finally, I can confirm that the JavaScript code I presented last month – for adding named views for multi-page documents so they can be easily viewed in a web browser – works perfectly in version 1.3.