Ceci est une ancienne révision du document !
It’s hard to believe that I’m now onto my third article about the changes and additions that Inkscape 1.2 brought to the Fill & Stroke dialog, yet there’s still plenty to write about. I love that: this dialog is one of the most frequently used parts of Inkscape for almost any workflow, so the fact that the developers have chosen to put some serious effort into improving it should bring benefits to every user. Previously, I looked at the new color pickers and the return of a gradient editor. Now it’s time to turn my attention to the changes in the Stroke Style tab. Let’s begin by comparing the old version, 1.1 (below left) to the new version, 1.2 (below right).
I sense you may be a little disappointed with that grand reveal. On the surface little has changed. The Markers buttons now show a thin line when no marker is selected, and the order of the Join buttons has changed to better match that of the Cap buttons, but otherwise things are about the same, right?
In truth, there have been two significant additions to this tab, but they both hide behind pop-up menu buttons. The first is the Dashes pop-up, which now shows as a two-column list, making it easier to see all the dash options at once, especially on smaller screens.
While I like the idea of a two-dimensional display for the dashes, I’m not sure the current arrangement works terribly well. The ‘order’ of the entries runs along the rows first, rather than the columns. This makes it difficult to see the relationship between groups of patterns that were previously vertically adjacent to each other. Using a column-first order would have been a better choice, I think. Better still would be to take the new design a step further with a three-column layout: one for dots, one for dashes, and one for mixed patterns.
The Custom option, which used to live at the bottom of the list, has been promoted to the top – and with good reason. In earlier versions of Inkscape, this was a misleading option to say the least. It was more of an output than an input; an indicator, rather than a control. If you were to load an SVG file with a custom dash pattern, then Inkscape would switch to this option in the UI. But manually selecting it for your own Inkscape-drawn lines did nothing, and certainly didn’t allow you to create a custom dash pattern (other than via a trip to the XML editor). That has now changed, and selecting this option expands the fields in the dialog a little, adding a ‘Pattern’ field.
The content of this field needs a little explanation, if you’re not intimately familiar with the way dash patterns are defined in SVG. It takes a series of space separated numbers. The first number is the length of the first dash (or dot – which is really just a small dash in this case). The second number is the length of the space that follows it. The third is the length of the second dash, and the fourth is the space that follows that. And so it continues, with odd entries defining the lengths of the dashes, and even entries defining the length of the spaces.
Fortunately there is a shortcut built into the spec to make your life a little easier. There’s no need to list enough entries to cover the entire length of your path: the pattern is automatically repeated for you. Entering ‘1 2 3 4’ is exactly the same as entering ‘1 2 3 4 1 2 3 4 1 2 3 4…’. But this also has a significant effect if you enter a series with an odd number of entries: this automatic repeating means that it’s the same as entering a series with an even number, in which the second half is a duplicate of the first. So ‘1 2 3’ becomes ‘1 2 3 1 2 3…’. The significance of this is that any odd entry in the first half (denoting a dash) turns into an even entry in the second half (denoting a space), and vice-versa.
From this you might have worked out that the simplest dash pattern is just a single number. ‘5’, for example, would actually be equivalent to writing ‘5 5 5 5 5…’ - i.e. a series of equally sized dashes and spaces, each 5 units in length.
Ah yes, the units. You may have noticed that all my examples have been simple numbers with no units. The SVG spec states that the numbers are all in ‘user units’, which should relate to the viewBox used in the SVG. Unless you’ve been messing around with that in the Document Properties dialog, Inkscape will generally set the viewBox dimensions to be the same as the document size. So if your document is defined in mm (e.g. an A4 page), then each ‘user unit’ will be 1mm. At least that’s the theory. But, in practice, it doesn’t seem to work like that, so you’re probably best just using a bit of trial and error to get the parts of the pattern to be the lengths you want.
The SVG spec also supports percentages in the dash pattern, but Inkscape does not appear to do so. Percentages are actually less useful than you might expect for this purpose. It would make sense for percentages to be based on the length of the path segment. That would allow you to enter a single value of ‘20%’ in order to get three equal length dashes (with two matching spaces between them), which exactly fills the length of the path. But for reasons that I can’t fathom, the SVG spec uses the size of the viewport (i.e. the window) as the basis for calculating percentages, making them practically useless, in my opinion.
There’s a workaround for that limitation, in SVG terms. You can add a ‘pathLength’ attribute to a <path> element which tells the renderer to override the actual path length when performing some calculations – such as defining the dash pattern. By setting pathLength to 100, any values entered in the dash pattern should therefore work as percentages. Here’s an example SVG file which draws a 90 unit long path, but uses pathLength to tell the browser to treat it as 100 units, so that the dash pattern value (in the ‘stroke-dasharray’ attribute) is effectively treated as 20% of the path length.
The top line is the output when this path is rendered in Firefox. You can see that there are three equally sized dashes, with two equally sized spaces between them, as expected. The bottom line is the same file rendered in Inkscape. The pathLength attribute is ignored, so the pattern does not fit exactly into a 90 unit path, resulting in longer dashes and spaces, with the last dash being cut-off. It’s a real shame that this attribute isn’t honoured in Inkscape, as it’s the only way to create dash patterns that always fit the path exactly. For now you’re stuck with some trial and error in the dash pattern field, and you’ll have to resign yourself to repeating the process any time the path length changes.
You may have noticed that the dash pattern always starts with a value for the first dash, with the first space coming after it. What if you want your pattern to start with a space, followed by a dash? There’s no way to specify that in the pattern itself, but the spinbox to the right of the Dashes pop-up button lets you apply an offset to the rendering of any dash pattern, whether it’s one of the built-in options or a series of your own devising. This can be used to nudge your pattern forwards or backwards to make it start with a space rather than a dash (or, indeed, with a half-dash or quarter-space, or any other adjustment you care to make).
Moving on from dashes, the pop-ups for the start, mid and end markers have also seen a major overhaul in version 1.2, turning markers into a hugely more versatile tool than they previously were. Unfortunately, if you’re on a small screen, you might find a bit of a problem with the new UI. My personal preference for dialogs is to have them floating in separate windows, rather than docked to the main window. This goes doubly for a small screen, as it gives me the ability to move them out of the way easily or, courtesy of my window manager, to ‘shade’ them (i.e. collapse them to just the title bar) when I’m not actively using them. But if you try to open one of these pop-ups when the Fill & Stroke dialog has been reduced to its smallest practical size, you will find that many of the controls are cut off.
The only workarounds for this that I’ve found are to either make the dialog larger, or to dock it at the side of the Inkscape window. In either case, clicking one of the marker fields will open the full pop-up.
Until you select a marker type, the bottom half of the dialog will be disabled. The first icon, at the top-left of the pop-up, is always just a thin gray line. This is the ‘no-marker’ option, and is the thing to click if you wish to remove the current marker selection. Following that, on the top line, is an entry for each marker definition that is currently used in the document. This makes it much easier to re-use the same marker for the start and end of the line, or to maintain consistency throughout a document. Do note, however, that using this option will ‘link’ all the uses of that marker to a single reference in the SVG; if you subsequently edit one of the markers (see below), all the linked versions will also change. For that reason it’s often best to choose your marker from the lower part of the palette, not from this ‘currently used’ section, if you think there’s any chance you might want to edit any of the markers later. This section will wrap onto multiple lines, if necessary, and is also where you’ll find any custom markers you’ve created using the Object > Objects to Marker menu entry.
Below a horizontal separator that, oddly, doesn’t stretch to the full width of the pop-up, you’ll find the complete set of markers that are built into Inkscape. Unfortunately, I haven’t been able to find a practical way to edit this collection. If you need to use the same custom markers regularly, the best approach seems to be to create your own default SVG file or template which contains them.
There are some interesting things to note about the marker icons in this section. The first is that each is presented with an associated gray line. This represents the stroke of the path on which the marker will be applied, and carries a couple of useful bits of information: the relative size of the marker compared with the line (e.g. those on the last row are the same width as the stroke thickness, so appear more like line caps than markers), and the position of the marker relative to the line (e.g. the pencil is offset to one side of the path).
It’s also worth noting that the position of each icon on the gray line, and the direction the marker faces, will be different depending on whether you’re selecting a start, end, or mid marker. For example, with mid markers, the gray line passes right through them, whereas for the others, the icon shows the marker placed at the appropriate end of the line. This is a subtle bit of UI design, but it helps to make more sense of how the final marker will appear in your document.
Once you’ve selected a marker, the bottom section becomes enabled to allow you to edit it to some extent. The options are mostly self-explanatory, and the preview pane on the left gives you a good idea of what the end result will look like as you play around with the spinboxes. The ‘Orientation’ buttons in the middle are worth some extra explanation, though.
These all deal with which direction the marker will face in. For some shapes, such as circles, these will make little or no difference. But for something like an arrow head, these buttons are essential to ensure that your markers point in the right direction.
The second button is the simplest to explain: this makes the marker point in the direction of the path, from start to end. With this enabled, using an arrow head as a start marker will show it as pointing in the direction of the path’s end, which is probably not what you want in this case. For mid and end markers, however, this is usually likely to be the best choice.
The first button behaves similarly, but flips the direction by 180° for start markers. If you find your start maker is pointing the wrong way, switch between the first and second buttons as necessary. Initially you might think that the last button is the right one to use in this case, but it’s probably not. That button flips the actual path definition, not the way it’s used in one specific instance – which means it also flips the direction of any other uses of that marker within the document (i.e. if you selected the same entry using the ‘current document’ line of markers at the top of the pop-up).
The third button simply allows you to specify a fixed angle for the marker. Note that this is an absolute angle, not relative to the path direction. For example, if you set this to -90° to make mid-marker arrows point upwards, they’ll point directly upwards for every node, regardless of the twists and turns of your path. If you actually need a marker to run at an angle that is relative to the path direction, rather than the page, you’ll need to create your own marker that is suitably oriented, use Object > Objects to Marker, choose it in the pop-up, and make sure to use the first or second button in this section.
In the bottom-left of the pop-up is an ‘Edit on canvas’ button. Click this and the on-canvas version of the marker will gain some basic editing handles. If you have multiple mid markers, these handles will appear on the first one. Using any of the three square handles you can resize the marker (hold Ctrl to scale proportionately); the circle is used to rotate it; the diamond in the middle can be used to move it, adjusting the offset from the path.
This will usually be a more intuitive way to adjust the size, position and rotation of the markers. Note that adjusting the rotation will automatically switch the ‘Orientation’ option to the third button, so steer clear of that circular handle if you need your marker to follow the direction of the path.
Finally, a note on color. SVG2 defines two keywords, ‘context-stroke’ and ‘context-fill’, as a shorthand for the stroke and fill color of the current object, respectively. Many of the markers make use of these to determine what color(s) should be used to render them. As a general rule, arrows and terminators tend to follow the stroke color (which is usually what you want), while the markers which appear with a white fill in the pop-up also use the fill color (which may not be what you want at all). If you wish to use different colors for your markers, you’ll need to dig around in the XML editor, find the marker definition, then drill down to the path itself (or some other part of the design, as needed) and modify the style attribute. It’s not for the faint-hearted, so make sure you save a backup of your file before you start messing around with the XML editor like this.
A particularly fine example of the context-stroke keyword at work is in the marker that looks like a pencil. This combines the keyword with some translucent panels in order to create a pencil whose body matches the stroke color of your path, but which still has some shadows and highlights based on that same color.
At the opposite end of the spectrum is the marker that looks like a location pin from a mapping site. This is hard-coded to always be red. If you want it to match your stroke color (or fill color), find it in the <defs> section of the XML editor, drill down to the path that’s inside the <marker> element, and change the ‘style’ attribute so that the ‘fill’ property is ‘context-stroke’ (or ‘context-fill’) instead of ‘#ff0000’. As an example, here is an image in which I’ve set the start marker to a fill color of ‘context-stroke’, left the mid marker as the default red, and set the end marker to a hard-coded value of ‘#009900’.
These new features in the Fill & Stroke dialog initially seem like small changes, but I’m sure you can see that they open up a lot of the possibilities that SVG offers, but which were previously hard to use within Inkscape. It’s a shame that changing the colors of markers requires a trip to the XML editor, and the technical knowledge that comes with that, but most users probably won’t need that level of control anyway.