Ceci est une ancienne révision du document !
Aside from the snap controls that I described last month, at first glance it may not look like much has changed in the main Inkscape window with the release of version 1.2 – apart from the welcome return of these zoom buttons to the main Control bar, of course: Observant readers may notice that not only have the ‘Zoom to fit selection’, ‘Zoom to fit drawing’, and ‘Zoom to fit page’ buttons reappeared, but they’re accompanied by a new sibling. Clicking this fourth button will center the page in the window, but without changing the current zoom. This can be useful when you’ve lost your way in a drawing, either because you’ve zoomed in or out too far, or have gone a bit wild with the pan option. A less obvious addition to the main window is a change to the toolbox. Last month, I looked at the new preferences that allow you to turn individual tool icons on and off, or to change their size. But those are not the only changes to the way these buttons are displayed. It’s now possible to adjust the width of the toolbox by dragging the right-hand separator. There’s no obvious visual affordance for this (i.e. a ‘handle’), but if you move the mouse slowly over the dividing line between the toolbox and the ruler (or canvas, if you have rulers hidden), your mouse pointer will change to indicate where you can click-and-drag. This allows you to transition seamlessly from the classic vertical list of icons, to a squarer layout in which each group of buttons occupies its own row – or, indeed, something in-between if you prefer.
Personally I think that the one-row-per-group view is rather wasteful, as it’s not possible to dock other dialogs in the empty space below the icons. But I can certainly see the benefit of changing to two columns if you’re working on a screen with limited height, but still want access to all of the icons rather than turning some off. One thing to note is that it’s possible to drag the divider the other way, to collapse your toolbox down until it’s no longer visible. That’s not the same as using the View > Show/Hide > Toolbox menu entry – that menu will still indicate that the toolbox is visible, even though you can’t see it. To avoid confusion, I suggest not collapsing the toolbox by dragging the separator: if you want to hide it, use the menu entry instead. If that’s something you do regularly, then you can assign a keyboard shortcut to the menu option via Edit > Preferences > Interface > Keyboard. It’s in the ‘Canvas Display’ section of the keyboard shortcuts. Once again, observant readers may notice the addition of a new icon to the end of the toolbox. This is for managing multiple pages in an Inkscape document, which is such a major new feature that I’ll be covering it separately in future.
There’s been one other significant change to the main window but, like the resizeable toolbox, it’s not immediately obvious that anything is different. The color palette, at the bottom of the window, has seen a major overhaul. Most of the changes take place towards the right of the palette, where you’ll find a pair of up/down buttons, and a menu button. We’ll skip the up/down buttons for now, and go straight to the menu button. Users familiar with earlier releases may know that there’s been a pop-up menu hanging around in this corner for a long time, allowing you to switch between different palettes and adjust a few settings related to the display of the swatches. The old design was a text-only menu, with some submenus providing a limited selection of options (e.g. None/Solid/Wide for the border around each color swatch). The new menu is a richer UI widget, allowing for a small thin-line preview of each palette – which makes it much easier to pick the right one. This image shows the old and new menus, for comparison. The various options for configuring the display of the palette have now been moved into a single pop-up which is opened via the ‘Configure…’ option at the bottom of the menu.
The options in here are pretty self-explanatory. ‘Tile size’ sets the basic size for the swatches, though the actual height and width will vary based on the aspect ratio. I’ll gloss over the fact that the ‘Aspect’ slider runs from -1.0 to 1.0 (that’s not really how aspect ratios work), and just state that negative values make the swatches taller than they are wide, positive values make them short and fat, and zero makes them square. The nice thing about all the controls in this pop-up is that you can see their effect on the swatches dynamically as you change them, so it’s not worth getting too caught up in the specific values – just drag the sliders until the palette looks the way you want it to. The ‘Stretch to fill’ option is a little odd. Ticking it disables the Aspect slider entirely, which in ‘normal’ UI terms should really mean that the checkbox is put above the slider to indicate the parent-child relationship between them. That’s not what makes it odd though: the weird thing is that it really does what it suggests it will only for palettes with few entries. Let’s start by looking at a case where it does work: the very limited color set of the ‘Android icon palette’. Here’s how that palette appears with the ‘Stretch to fill’ option disabled (top) and enabled (bottom).
It doesn’t take a genius to see that the ‘Stretch to fill’ option has stretched the individual swatches to fill the available space. No big surprises there – it’s exactly what you would expect an option with that name to do. But what happens if there are a larger number of colors in the palette – something like the ‘Blues’ palette, for example. Here’s how that palette appears with the ‘Stretch to fill’ option disabled (top) and enabled (bottom). If you’re struggling to spot the difference, you’re not alone. In both cases, the swatches actually extend over three rows (on my screen), with those up/down buttons being used to switch between them (you can also use the scroll wheel on your mouse, if you prefer). But clearly the swatches haven’t been made narrower in order to fit them all in the available space, as you might expect or want. ‘Stretch to fill’ very specifically means ‘Stretch’ and not ‘Compress’. Perhaps you’re thinking that Inkscape is just being sensible, as there are too many colors in that palette to fit on one row in a usable way. Not so: unchecking that option and manually setting the tile size to 11 and the aspect to -0.7 is enough to get the entire palette to fit in a single line.
Moving on from the inconsistencies of stretching swatches, the ‘Border’ option adjusts the amount of space around each swatch. If you want your palette to look like a continuous gradient of color (assuming the tones are so arranged), then set this to zero. Higher values add more space around each swatch, which may be useful to avoid mis-clicks, or simply to ensure each swatch appears as an individual item rather than blending with its neighbours. The final option, ‘Rows’, exposes what I think is the most significant flaw in the new palette interface. When the number of swatches is simply too large for them all to appear in the available space, they overflow onto multiple rows. You can then scroll through them using the up/down buttons or the mouse wheel, as I described above. The ‘Rows’ control determines how many rows can be displayed in the palette area – basically, how tall the palette area is. This can allow you to display an entire palette at once, rather than having to use the up/down buttons to access them all. This image shows the difference between Rows=1 and Rows=5 when using the Inkscape Default palette. If you’re the sort of person who wants to see all the colors in the palette, all the time, this might be fine. But what if you’re also the sort of person who switches between different palettes, depending on your needs? Here’s how the palette area looks when you’ve got Rows=5 but you’ve selected the Android Icon Palette.
That’s a lot of wasted space. Enabling the ‘Stretch to fill’ option doesn’t help much either, as that only stretches the swatches horizontally, and does nothing to fill the additional blank rows. The ‘Rows’ parameter sets a fixed number of rows to display, even if fewer rows would make more sense. It would be nicer, I think, to have the number of displayed rows adjust dynamically, using the ‘Rows’ parameter to set a maximum. But in my opinion there’s a bigger issue to consider. In previous versions, the palette would scroll horizontally if it couldn’t all fit on screen. You could switch to a vertical scrolling mode by enabling the ‘Wrap’ checkbox in the palette menu, which would give the same effect as the palette in version 1.2. But the new release doesn’t offer an equivalent way to revert to the horizontal scrolling design of its predecessors. You’re forced to use a vertically scrolling palette, whether you like it or not. This may seem like a trivial gripe, but there are pragmatic reasons why a horizontally scrolling palette is arguably better in some cases. Let’s consider that sweeping blue palette once more – here it is with Rows=3 on my machine. Try to imagine that as one long horizontal palette. Yes, you can only see a small ‘window’ of colors at a time, but scrolling the mouse wheel over the colors smoothly moves the line along, with no breaks or discontinuities. It’s easy to see the relative colors of every swatch when compared with its neighbours.
With a multi-row display, however, there are breaks artificially added to the flow of color. Your eyes have to scan from the end of one row to the start of the next in order to continue progressing along the palette. Swatches can now be completely surrounded by up to 8 immediate neighbours, not just one on each side. This affects your eye’s ability to discriminate between the colors, especially where (as in this screenshot), some light colors are sandwiched between darker rows. And the position of those breaks aren’t consistent, but change with the window size and the parameters chosen for the palette display. Your favourite shade of blue might be at the start of the second line one day, but buried somewhere in the middle of a block of color the next. For now, us ‘single row’ advocates just have to live with this forced vertically scrolling design, but I do hope that a horizontally scrollable palette makes a return in a future release. Moving on from the palette to a related topic: the Fill & Stroke dialog has seen some useful tweaks and improvements. You may recall that previous versions offered tabs, and then buttons, to switch between different color pickers. The choices were RGB, HSL, HSV, CMYK, Wheel, and CMS. Those tabs/buttons have been replaced once more, with a pop-up menu that adds ‘HSLuv’ to the mix.
You may have noticed that there’s no ‘Wheel’ option on the menu. Fear not! The wheel has been moved to a collapsible section in the HSL, HSV and HSLuv modes, giving you the option to use both the wheel and the sliders in combination far more easily. I don’t understand why it didn’t also make it into the RGB view, as I can’t see any technical reason for preventing it (Inkscape uses RGB internally, so, even if you pick your colors using CMYK, what ends up in the file is actually an RGB conversion of your color). The HSLuv view is an interesting one: I can’t really make sense of it, even with the visualisation offered by the wheel view, but I daresay there are users with more specific color requirements (and knowledge) who will benefit from the addition of this mode. The color pickers aren’t the only change in the Fill & Stroke dialog… but I’ve reached my word count for this article, so the other new additions will be the subject of next month’s instalment.