Adopt Feather/Lucide icons

[Jermolene]

Feathericons are an open source library of very nicely drawn SVG icons published under the MIT license. They have the interesting property that they are designed by used at varying line widths. I think this is helpful for accommodating personal taste and accessibility needs.

I propose that TiddlyWiki 5 adopt the Feathericons for the core, replacing the current icons. Where necessary we might need to create additional icons in the Feathericons style, which we will offer to upstream.

https://feathericons.com/%0A

[pmario]

I did have a fast look. It seems not all icon elements are paths. So they will not work with our current hover CSS states, without adjustments. So we'll basically need to create them ourself using that style as a template.

[Jermolene]

Thanks @pmario do give a link to anything problematic if you can.

[mateuszwilczek]

I think a refreshment of TW icons is a very good idea. While each fits its own purpose very well in TW, there are some inconsistencies between them. I was considering proposing some changes to amend these, but moving to a new base might be worth the additional efforts.

I happen to have briefly explored the idea of creating custom icon sets for TW recently. I didn't have time to really do anything useful, but hopefully my observations will offer some additional insight. I will be referring to two large open source icon collections from "big tech" that I looked into, that is Google Material Symbols and IBM UI Icons. There are certainly many other open source sets worthy of consideration, before making the decision to move.

Lucide instead? The Feather set seems to have no active development since some time. I have found some comments that it is considered abandoned. There is its fork, Lucide, on a similar license, with > 1200 icons (Feather has < 300), and it seems to be under active development.

SVG code consistency. This is a huge advantage of Feather/Lucide. As far as I have checked, all icons consist only of strokes, with stroke-width, stroke-linecap, and stroke-linejoin defined in the opening svg tag. This should allow to programmatically "tiddlify" them, and even offer sharp line ends as an option. The same cannot be said about IBM icons - their SVG code is all over the place, using different names and svg elements for identical things. Material Symbols are at least consistent in the code structure, it would be possible to programmatically tiddlify them, but they are offered only as expanded paths, not strokes, even though they mostly consist of lines and are available in many line width options. So each "weight" or "stroke width" option is actually a separate path.

Well, as @pmario mentioned above while I was writing this, this design of Feather/Lucide might not be so good after all. Is rearranging TW to work with stroke-only icons as well as path-only a reasonable thing?

Stroke-only design. In my opinion some icons simply look better when using filled shapes as well, not only strokes (e.g. image with mountains and sun, hexagons with Motovun/puzzle/tools inside, to name a few). The caveats are: I don't know if icons with filled shapes could be as easily adaptable as the stroke-only ones, it would be more difficult to keep them consistent, and merging with upstream would probably not be accepted.

Summing up: I think refreshing TW icons and making them more consistent is a good objective. Lucide offers a wide choice with a good code quality (allowing for easy user customization). There is the issue of support for stroke-only icons in TW, and design issue of sticking to stroke-only icons. These issues and other available open source icon sets should be explored.

[pmario]

Our concept is different. Eg: alert-triangle looks like this. Feathericons uses stroke-width parameter to define the stroke width, which seems to be one reason, why you want to switch.

TW icons do not have a stroke-width atm.

The fill parameter defines the icon colour. The feathericons use it differently

fill and stroke redefined. We would need to completely change our CSS rules, which will cause problems with 3rd party plugins.

[pmario]

It seems, that several sets contained in https://morosanuae.github.io/tw-icons/ do meet the TW affordances and can be directly used.

The only difference is, that the will need the new <<size>> parameter. They use the hardcoded width and size values at the moment.

[pmario]

There is its fork, Lucide, on a similar license, with > 1200 icons

I do like this project. They look good. If we could find a way to "batch convert" them into a format, that is compatible with ours that would be nice.

[pmario]

There seems to be a possibility to use InkScape from the CLI

See: https://github.com/leifgehrmann/svg-stroke-to-path/tree/master
and: https://dev.to/saulodias/convert-svgs-from-stroke-to-path-420j

[mateuszwilczek]

So using Lucide as-is (in the stroke-only form, with ability to change stroke-width on the go) requires a lot of changes in the core and introduces incompatibilities.

If Lucide can be dependably converted from strokes to paths, and if we could also automate the process of "tiddlifying" it (parametrizing size, removing eventual unnecessary metadata, changing to usable TID or JSON format, packing into a plugin), then we could easily offer the icons at a couple of different preset stroke widths as core plugins. Not as adaptable on the go as the stroke-only icons, but also within reach without breaking anything.

But the question is, if it is worth going that far at all for the stroke width variability. If we are to convert Lucide to paths, we may just as well use another icon set, that is already available in path form. The Material Symbols are already available at different stroke widths/ weights, maybe there are other interesting sets like that?

[pmario]

The Material Symbols are already available at different stroke widths/ weights, maybe there are other interesting sets like that?

I did have a look at them from https://morosanuae.github.io/tw-icons/ -- IMO the only one, where the whole set looks OK and has paths, is: Zwicon (565 icons). The last one -- But -- It needs to be optimized in size. The icon set has way more path elements than needed for small sizes we use them. If used as they are, they will need 960 kByte. SVGOMG can probably strip it down to about 30% or more of that size. I only tested it with 4 random complex icons.

Since v5.3.0 SVGs are already backwards incompatible for 3rd party plugins, IMO there would be a chance to change the way core icons work.

In my earlier comments I did not take parametrized transclusions into account, which may make it possible to improve backwards compatibility. Even with stroke-like SVGs

---

I personally do have a Font Awesome 5 Pro license, which is sufficient for my needs. They have 1852 path icons in 4 versions: Solid, Regular, Light and Duotone. -- It would be sad if I'd need to throw them into the bin.

Conclusion

Whatever we decide, we will never be able to use an existing icon set out of the box, because of the flexibility we want to have. 3rd party icons sets will never allow us to use TW macro calls to define width and height=<<size>>

Even if we introduce a "hard dependency" and contribute to that icon set upstream, we will probably need a "build step".

So using the same mechanism https://morosanuae.github.io/tw-icons/ already provides with an official TW icon set seems to be manageable.

• There could be some predefined sets like: Solid, Regular and Light that contain the TW core icons
• With the rest of the icons, users will be able to download user defined sets
• If the configurations would be stored in browser local storage it would also be easy to extend existing sets

Just a thought.

[Jermolene]

Thanks @pmario @mateuszwilczek for the interesting points.

I wasn't aware of Lucide, which does seem a much better candidate.

I agree that the backwards compatibility implications of switching from fills to strokes are tiresome.

I wonder if we can stick with the fill approach, but parameterise the designs to give even more axes of variability than just the stroke width. We'd add a "stroke-width" parameter to the existing TW core icons that would do the maths to vary the stroke width. We might also add a "colour" parameter for easily overriding the colour of the icon without having to use CSS.

I also agree that we're likely to need a build process of some kind.

[mateuszwilczek]

We'd add a "stroke-width" parameter to the existing TW core icons that would do the maths to vary the stroke width.

Generating filled paths from strokes at arbitrary widths inside TW would be very convenient, but from what (little) I have read (here or here), outlining strokes is not a trivial operation, it requires some dedicated libraries or programs (the Inkscape CLI mentioned above). As said, I haven't researched it much, but this might be problematic.

If so, we would have to revert to outlining outside of TW and offering separate icon sets outlined at different stroke widths.

[pmario]

[. . .] outlining strokes is not a trivial operation, it requires some dedicated libraries or programs (the Inkscape CLI mentioned above). As said, I haven't researched it much, but this might be problematic.

Yea I did find similar posts and found the links to the InkScape CLI, which would probably provide us with parts of the "build steps" needed.

• We would first need to set stroke-width to 1
• Create / download the SVGs with that setting
• Convert them to paths
• Add our TW specific classes
• Add our width and height settings
• Add our parameters
• Optimize file size
• Start from the beginning with stroke-width 2 and 3

We already have a step, that optimizes the size of SVGs. I do not know where it is called but probably somewhere in the build steps

We would need run some test, if that workflow would create 3 reasonable icon sets.

[Jermolene]

Generating filled paths from strokes at arbitrary widths inside TW would be very convenient, but from what (little) I have read (here or here), outlining strokes is not a trivial operation, it requires some dedicated libraries or programs (the Inkscape CLI mentioned above). As said, I haven't researched it much, but this might be problematic.

I agree. This is highly speculative but I wasn't thinking that we'd generate the filled SVGs from the paths, but rather than we'd parameterise our filled-style SVGs. We'd make the images out of transformed rectangles for the lines and circles for the line joins and caps.

[mateuszwilczek]

We'd make the images out of transformed rectangles for the lines and circles for the line joins and caps.

This seems like a lot of manual work and there is the issue of more complex shapes not composable using only straight lines and circles.

What we would ideally want sounds a lot like the variable fonts, that is fluid adjustment of the "weight" of complex filled paths. But I have no idea how it's done internally in VFs (interpolation between edge cases would be the simplest, but I have a feeling it is more complex), or whether this analogy helps in anything at all.

In any case, the only icon set that I know with similar properties are the Material Symbols mentioned above. They are distributed as static paths or variable font in 7 weights × 3 grades (sub-weights) = 21 actual weights. It would be interesting to know what are the internals of generating all those variants. I wonder if the webfont does anything more clever than simply storing all those variants as static paths. It is intended to be used over the web and weights 10 MB, so maybe it is just a store of static paths. If so, then this ends up being not a much different workflow than the one described by Mario.