SVG version often rasterized with gaps

[tobast]

Hello,

I've noticed that although the SVGs generated by qrencode seem quite reasonable, a large variety of programs/libraries displaying those rasterize them with gaps between the qrcode "squares" (I'm unsure about the correct terminology, I'll refer to the little dark blocks as the qrcode squares). You can find examples of this behaviour at the end of the report.

Arguably, the error lies with the SVG rasterizers, and is out of the scope of qrencode, since the svg produced is quite reasonable. However, it seems that this issue has been lying for a very long time and is probably not going to be fixed everywhere any time soon. In the meantime, this makes qrencode --type SVG pretty much useless, since the output won't be reliably displayed nicely.

Proposed patch

I gave the issue a bit of thought, and although this doesn't seem completely satisfying (it looks way too much like duct tape), I believe that the best course would be to add a border to every square of eg. 5% of the square's size. From the limited experiments I made, it seems to fix the problem (at least on the few programs I tried), doesn't seem visually awkward, and doesn't prevent qrcode scanners to read the qrcode (again, very limited experiments so far).

If the fix seems reasonable to you, I could submit a PR.

Examples

I rendered a qrcode holding the string "foobar" for demo purposes, with qrencode 4.1.1, using the command qrencode --type SVG --background ffffff00 "foobar". Here are screenshots of a few applications rendering it badly:

Eog (Eye of Gnome), common software to display images:

Inkscape (svg editor):

After creating a PDF embedding the SVG qrcode with Inkscape,

Zathura, using the pdf backend mupdf:

Firefox, using the pdf backend pdfjs:

[tobast]

I just stumbled upon PR #41 and the --svg-path option, which indeed solves the issue above, and looks like the right thing to do indeed.

Maybe putting the option a bit more forward somehow, or enabling it by default, would be nice?

Thank you!

[peter-scholtens]

Instead, I would suggest to specify --svg-no-path as a command line option and let the default behavior to create it using paths when SVG is selected. I couldn't think of a use-case where it is useful, having no paths, but if some users want it, then they can still have it.

[JonathanAlcaraz]

I found this thread because I was also having this issue too. While --svg-path fixed the problem in my image viewer (Gnome) and inkscape, the issue still comes up for me in LibreOffice Draw and the PDFs it generates.

If I run qrencode -o test.svg -t SVG --svg-path 'hello world', I get this in my image viewer:

However, the gaps come back when I embed that image into LibreOffice Draw:

And they persist when I export the document as a PDF:

Maybe this is a LibreOffice issue—the link you shared to the old inkscape issue makes it clear that rendering cases like this is non-trivial. I just thought I'd share my experience since it doesn't seem this issue is fully solved.