lucide TTF font has inconsistent stroke width

Prerequisites

Version: v0.16.23–v0.17.13
Are you running from source/master: lucide-static ttf font file
Operating system: macOS 12.2.1 (Monterey)

Step to reproduce

Dear Lucide team,

I am using the font file from lucide-static in my LaTeX documents (using the XeLaTeX engine, which supports open type fonts). I noticed that in the resulting PDF, many icons have inconsistent stroke widths on some of their paths. This is only visible in smaller zoom levels, the symbol looks fine when I zoom in a lot. This seems to happen in all versions of the lucide-static ttf build, I tested it with the oldest stable 0.16.23 too.

On the left you see the original lucide-static icon, on the right I created a font myself (more on that below) — you'll notice that for the left symbol, the upper (right) path is thinner than the lower (left) one:

lucide-stroke

I created an Overleaf with the TeX source code (…not sure if you need an account to edit it, though - let me know):

https://www.overleaf.com/read/rfhcvtzbyfkc

Here is the resulting PDF:

lucide_font_stroke.pdf

I tested the PDF with multiple rendering engines — the bug occurs in

macOS default Preview.app
PDF Expert (which uses its own engine, afaik)
PDF.js (both the legacy one and the modern one)

The bug does not occur, e.g. both icons look the same in

Adobe Acrobat Reader DC
Chrome

Possible workaround

Before you released lucide-static, I used a custom-built font file for my latex documents. This rendering issue does not happen the way I build the font. I think the problem lies in the ./scripts/outlineSvg.js script, which uses the svg-outline-stroke npm package. Instead, I used a combination of svgo and inkscape's CLI, before passing the (modified) svg-files to fontcustom.

Here is an example script which uses svgo and inkscape:

#!/bin/bash

if [ ! -d "lucide" ]; then
    git clone https://github.com/lucide-icons/lucide.git
fi

mkdir -p icons-test       # (modified) svg files
mkdir -p icons-test-font  # font files


cd lucide
if [ ! -f "converted_icons/link.svg" ]; then
    yarn install
    yarn yarn build:outline-icons --outputDir=converted_icons
fi
cd ..
cp "lucide/converted_icons/link.svg" "icons-test/link-lucide-outlined.svg"


cp "lucide/icons/link.svg" "icons-test/link-r.svg"  # will be modified by svgo+inkscape+svgo
svgoconfig="module.exports={multipass:true,plugins:['convertPathData', {name:'convertShapeToPath',params:{convertArcs:true}}]}"
svgo --config <(echo "$svgoconfig") "icons-test/link-r.svg"


inkscape -g --export-plain-svg --export-filename "icons-test/link-r.svg" --batch-process --verb="EditSelectAll;StrokeToPath;SelectionUnion" "icons-test/link-r.svg"


svgoconfig="module.exports={multipass:true,plugins:['convertPathData', {name:'convertShapeToPath',params:{convertArcs:true}}, {name:'removeAttrs',params:{attrs:['fill','stroke','stroke-width','style']}}]}"
# TODO: not sure if these removeAttrs work for every icon in the set?
svgo --config <(echo "$svgoconfig") "icons-test/link-r.svg"


docker run -v ${PWD}:/project drichner/fontcustom compile "/project/icons-test" -h -n "lucide-r" -o "/project/icons-test-font" -F

This is only marginally related to Lucide itself — I thought that it might be interesting to share it with you nontheless.

Happy to hear your thoughts!

Mar 23 '22 12:03 r4lv

Some additions:

svg-outline-stroke basically just renders the SVG to a bitmap, and traces it with potrace. While that is quite genius, I think that is at the root of the problem.
there is also a discussion on webfonts and outlining paths on https://github.com/feathericons/feather/issues/135. Someone suggested svg-to-ttf, which is a bit outdated, but also uses inkscape internally.
the svg-fixer package, suggested in the same issue, also just wraps potrace, and shows the same rendering issue.

Mar 23 '22 13:03 r4lv

Hmm interesting. Good you find this issue. Yeah I think you solution is better, It felt a bit hacky how we outlined the paths. But it worked well, so far. The only think we should check if inkscape is correctly rendering the icons, we still have some issues with rendering icons in other design programs, see #443 .

Maybe you also like to join this issue: #514 , I'm not sure yet how to solve this.