Drawing with Inkscape – Part 158
By Mark Crutch

After a couple of false starts, the latest bug fix version of Inkscape is out. There was an attempt to release 1.4.1, which was stopped at the last minute when significant issues were found, so the new version is 1.4.2. But even that suffered a Windows-only problem initially, so had to be repackaged and re-released. The official release date was May 12th 2025, so if you installed a Windows version of 1.4.2 around that time, it might be worth downloading again to make sure you’ve got the latest version.
There is a long list of bugs addressed in this release, so it’s worth updating if you’re running 1.4. There are very few new features though, and only one that I think will be worth covering in detail in this column (the Clean Up Paths extension). Some improvements and additions to the import filters are worth mentioning in passing: the importer for Affinity Designer files (added in 1.4) has been substantially improved, and there is a new import filter for Linearity Curve (formerly Vectornator) files. As usual with import filters, if you do experience issues then please raise a bug and provide a file showing the problem, in order for the developers to improve the code further.
Continuing with the changes in version 1.4, this month I’m going to look at the Filter Gallery: a new dialog that aims to make it easier for you to preview and select from the many filters that Inkscape ships with. Before I get into that, however, it’s been a while since I did an explanation of how filters actually work in the SVG world, so let’s begin with a quick introduction for anyone new to Inkscape or to SVG, the native format for Inkscape files.
SVG is an open format for defining vector graphics files. Compared with raster (also known as bitmap) files, vector files are more about defining the way in which an image is drawn, rather than the final result. A raster image consists of lots of individual dots – pixels – whereas a vector file is more of a mathematical description of the parameters needed to draw shapes. A circle in a raster image is actually an approximation made up of a large number of dots; a circle in an SVG image is defined by its center coordinates and radius. Raster files lose quality as they are scaled up or down from their ‘native’ size, whereas vector images – in theory at least – are infinitely resizeable without any loss of quality or resolution.
That’s not to say that SVG files are always purely vector data. It’s possible to link to external raster files so that they become part of your image, or to embed the raster data directly into the SVG file itself. This causes something of a dilemma, however, as it means you effectively lose the infinite scalability of your vector file – it now has an optimum size, defined by the raster image. To confuse matters further, you could potentially include multiple raster images, each with a different optimum size, to create an SVG file which no longer scales infinitely without losing quality, but which also no longer has a single optimum size, either. The worst of all worlds.
In truth this is often more of a theoretical problem than a practical one. If your original raster images are high enough resolution then they can usually be scaled down quite a bit without the quality suffering, subjectively speaking. Scaling up is more of an issue, but it depends on how your image is going to be used. A blocky raster image might be a problem in a magazine, but that same level of blockiness could be unnoticeable on a billboard poster.
But, as a general rule, vectors are scalable, rasters are not, and SVG is primarily a vector format. So it might come as a surprise to you if I say that filters are raster operations, despite being one of the core components of the SVG format.
At this point, it’s important to consider the output device being used to present your Inkscape image to the world. Like images, output devices broadly fall into two categories: raster and vector. A computer screen, phone or tablet are raster devices – the hardware itself is made up of thousands or millions of individual pixels arranged (usually) in a rectangular grid. Likewise with laser or inkjet printers, which produce their images by placing dots of toner or ink in a rectangular grid on the page. But there are other output devices – such as laser engravers, pen plotters and vinyl cutters – which work with raw vectors in order to move a laser, pen or blade in two dimensions. For those devices, a line isn’t an array of individual dots, but rather instructions to drive a pair of motors controlling the x and y position of the output head in one continuous movement.
We’ve got some vector data in our SVG file. We can send that directly to a plotter or cutter (possibly after converting to a different file format) to create images that are, in theory, infinitely scalable. Whether you have a tiny desktop pen plotter, or a large industrial laser cutter, the same basic vector data can be used. The output device will convert the vector geometry into the correct signals to drive those x and y motors.
But we can’t send that vector data directly to a screen or printer. Instead we have to turn it into a raster image that the device knows how to handle, through a process called rasterisation. Without going into detail, this basically entails doing the mathematics to work out which part of the vector file should be visible for each pixel of the output. It turns your smooth vectors into a blocky raster – albeit at a resolution high enough that it shouldn’t look particularly blocky on your screen or printed page, unless you inspect it with a magnifying lens.
SVG filters apply to the image just before this final rasterisation step. Since this step is only relevant to screens, printers and the like, the first take-home is that filters are useless for any device which receives vector data. It doesn’t matter what your filter looks like, it will be ignored by a pen plotter or vinyl cutter. Laser engravers are a different matter, as they can often also be used to ‘print’ raster graphics by varying the laser’s intensity and drawing lots of dots – but when used as a pure vector cutting device, for example, this same restriction applies.
Consider these two images. They may look identical, but the one on the left was created by duplicating one circle and moving it, whereas the one on the right is the result of using a filter.

Send these two images to a screen (such as when editing in Inkscape, or loading the SVG image in a web browser), or a printer, and you’ll get four circles in total. Send it to a pen plotter and you’ll get only three – the fourth one isn’t really a vector object, so the plotter won’t be able to do anything with it.
So, if one of the circles on the right is actually a raster graphic, we’ll be able to see the blockiness if we zoom in, right? Let’s give it a try by zooming in within Inkscape…










It still looks pretty smooth to me. That’s because the filter is applied as one of the very last steps in the rasterisation process, just before it’s displayed on screen. Zooming in within Inkscape isn’t taking a raster version then scaling it, it’s creating a whole new raster image of the zoomed in content. Effectively filters always output at the native resolution of the device they’re being rendered on, creating an optimally sized raster image. This means that you can, to some extent, ignore the distinction between raster and vector for screen or print work – the output will always be the optimum size.
From this, I hope you’ve understood that filters are a purely visual thing – they don’t alter the underlying geometry of your objects in any way. All they do is apply a series of operations to determine what color and opacity each rendered output pixel should be, as part of the rasterisation process. Which precise operations are performed will vary from filter to filter, with each filter (or “filter chain”) typically being made up of several “filter elements” which are connected to each other in a network. Each filter element does one job: it could be generating a color or fractal noise pattern as a source of image data for the filter chain; it might blur its input before passing it on; it might remap the colors of the input image. There are many more of these primitives which can be combined to create an incredible variety of filter chains for an infinite range of effects.
In early versions of Inkscape, there were no predefined filters included. There was an editor with which you could make your own – but that’s a skill that most of us simply don’t have. Filter chains can become very complex very quickly. For example, here’s one in which I’ve applied the Textures > Wax Print filter to one of those circles from earlier in the article. The result is on the left, with the corresponding filter chain on the right. This one is relatively simple, with only eight filter elements connected in a mostly linear way, but it’s still not something that most Inkscape users could create for themselves.

With version 0.47, the program shipped with a large selection of predefined filters, grouped into related types and exposed via the Filters menu. This was a great step forward, but working out which filter you need for a given design is often a case of trial and error, selecting each filter in succession to see the effect it has. This is made more complex by the fact that filters can be combined, so it’s important to undo (Ctrl-Z) the previous filter before trying the next one, if you really want to see its effect in isolation.
With 1.4, however, we finally have a more graphical way to select filters. The menu entries still exist, but at the very top of the Filters menu is now a ‘Filter Gallery…’ option. Selecting this opens a new dialog.

The obvious good news here is that we now have thumbnails that give some idea of the effect each filter might have. All the thumbnails use the same flower-like shape as their base, with no option to change it – a limitation that I’ll come back to shortly. You can alter the thumbnail size using the slider hidden in the Settings pop-up (the ‘cog’ button) – though I have to wonder whether there’s a need for a separate pop-up with only a single entry in it. Surely the slider could have been squeezed into the dialog directly.
To the left is a list of the filter categories, matching the categories in the Filter menu. This list also features an “All Filters” entry at the top if you just want to see all the thumbnails at once. The button at the top-left will toggle the visibility of this list. When it’s hidden, the view is automatically switched to show all the filters, which makes sense. Re-showing the list, however, can lead to a mismatch in the UI, whereby all the filters are still visible despite the previously selected category being highlighted. I don’t see that this will be much of an issue though – you’re either the sort of person who uses the categories, in which case it makes no sense to hide the list at all; or you’re the sort of person who prefers the “All Filters” view, in which case you may as well leave the list permanently hidden.
Completing the top of the dialog is a disappointing search box. It’s disappointing for two reasons: firstly it searches only the filters for the currently selected category, whereas searching across all filters would make more sense to me; secondly it searches only in the filter name and category, not in the well-worded descriptions that accompany each filter, making it harder to find a filter unless you know its specific name.
Once you’ve found the filter you want to use, click on the thumbnail to select it. Despite the wording at the top of the dialog (“Select filter to apply”), the act of selecting doesn’t actually apply it. For that you have to click on the “Apply” button, oddly positioned at the bottom-center of the dialog, and your selected filter will be applied. Possibly.
You see, there are two types of filter in Inkscape: those that apply immediately, and those which open a dialog to let you adjust the parameters, and even preview the result. In the Filters menu the latter is indicated by an ellipsis (“…”) after the filter name. In the Filter Gallery, however, there’s no indication in the name or the thumbnail as to which filters will open another dialog and which won’t. Only after you’ve made your selection can you tell: the “Apply” button changes to “Apply…” if there’s a dialog to follow. I’d much rather have that information presented on the thumbnails themselves, via an ellipsis, a badge, or some other indicator.
Aside from these UI niggles, there’s one big problem with this dialog: the shape used for the thumbnails. It’s not that there’s anything wrong with it, as such – but no single shape can possibly be representative of how a filter will work in all cases. Many filters work best on bold, solid objects – use them on thin filigree lines and they’ll disappear to nothingness. Others might be the opposite, with fine details that work best with thin shapes or sharp angles, rather than the soft roundness of the flower shape in the thumbnails. I’d love to see that settings pop-up extended to allow a choice of preview objects: perhaps some basic primitives such as a triangle, square, star and circle – with the option to have them filled or just use a stroke. And, most of all, the ability to preview using a text sample, in the font of my choice, would make using filters with text a lot more practical.
This may seem like nit-picking, but you’ll quickly find that the thumbnails can be very, very misleading. Consider the crimson circle from earlier: here’s what it looks like with three of the filters, alongside the thumbnails for reference:

The result of the top one is less “Fat Oil” and more “grease stain”. The second doesn’t give me the thin black stroke I expected from the “Jigsaw Piece” preview, but rather a super-thick outline instead. And “Matte Bevel” just causes the crimson circle to disappear entirely – to the extent that I’ve left the selection box visible, to provide some evidence of its existence.
This isn’t a problem with the new dialog, so much as it is an issue with SVG filters in general. This is where I come back round to that distinction between vector and raster. Filters can themselves contain raster data – and often do. Some filter primitives require a raster graphic which is used as part of its operation. For example, the feDisplacementMap element often uses a raster graphic as a way of storing a 2D matrix of numbers that are used to define x and y displacements.
Similarly, the commonly used feTurbulence primitive generates an array of random(ish) data, but does so with a “size” parameter that defines the resolution of the noise it creates. Here’s the output of that filter applied to two rectangles, with the only difference between them being the value of the size parameter:

This size parameter remains constant in the filter, whether it’s applied to a large object or a small one – or to a small one that’s then resized to make it larger (or vice versa). There’s no way to link the size parameter to the final dimensions of the object it’s being applied to in order to make it change when the object’s size is altered. That’s just the way SVG filters work, but it does mean that they can be extremely sensitive to the size of the object you’re applying them to. Here’s that “Fat Oil” filter again, this time applied to four filled circles. Clearly it works as expected for larger objects, but not so well for smaller ones.

For this reason, while I applaud the addition of this dialog, please don’t get too excited by the possibilities the thumbnails suggest. It’s not until a filter is applied to your objects in your drawing that you can really see whether or not you’ll get the effect you expected. Perhaps, one day, we’ll get live on-canvas previews of all the filters so we can more easily select the right one for each design. Until then, the Filter Gallery is perhaps most useful as a way to definitively rule out some filters, rather than as a means to choose a specific one. Even when using this dialog, I still find myself following the familiar approach of applying a filter, then undoing, then applying another, and so on. The difference now is that it’s easier to skip the ones that are more obviously wrong.

Mark uses Inkscape to create comics for the web (http://www.peppertop.com/) as well as for print. You can follow him on Twitter for more comic and Inkscape content: @PeppertopComics