It doesn’t seem to like spaces that much, the code for [QR coded] is broken for me on safari ios. When the space is removed it’s a working qrcode again
I haven't tried on macos, but yeah, the biggest problem right now seems to be implementation differences with how embedded spaces are handled. Earlier, the biggest cross-browser issues were pixel alignments within the QR codes, but those seem largely resolved.
The only thing I'm seeing there is that line-wrapping might do [something], and a suggested workaround (which, oddly, they don't implement on the page). And the line-wrapping issue doesn't look like that to me, at least when I do it.
Fair warning though: this was designed and implemented by an LLM, as an experiment to see if it was possible. I only guided it to a working solution by pointing out problems, and never dug deeply into its inner workings.
OpenType specification is Turing complete, its hinting engine does math during rasterization and its GSUB (Glyph Substitution, a layout and shaping engine) does glyph stacking, QR code correction, etc to finalize the QR. The nice thing about it is if you copy and paste it, it goes to the original text.
That’s a common downside of HN: submitters often link the GitHub repository rather than the project’s explanation. The article’s had the project link added at the top (just below the GitHub link) and it has a much clearer story.
Or with some tweaks to the font code they could see a different URL…
This could be used for good (diverting bots away from where you don't want them) or evil (different destinations for user and other readers of the page could be used to trick people going to undesirable locations, because the apparent URL checks out find according to automated scanners).
This is SO COOL. Works perfectly in FF for me, if it can be made to work in safari then this might be one of the easiest ways to generate and display QR codes on the front-end.
Maybe it's not practical for day-to-day use but the way this hacks the font to produce something completely different is amazing!
[dupe] a recent Show HN: https://news.ycombinator.com/item?id=48703200
A fun benefit seems to be that you can select the QR code as text and copy it, which puts the original text in your clipboard.
Font rendering should scare you
Indeed, I have all font downloads off in all my browsers, by default.
It doesn’t seem to like spaces that much, the code for [QR coded] is broken for me on safari ios. When the space is removed it’s a working qrcode again
The page addresses this issue, saying that browser text wrapping can cause issues and gives advice on how to deal with it.
I think this is a different problem.
The page says that “browsers may split a QR code across lines” - but this isn’t split across lines.
Experimenting, if I just type "[Q R]" (very short, so not likely to line-break), the problem still occurs.
If I inspect the element, and add `white-space: nowrap;` to its style, the problem still occurs (although the text doesn’t wrap!).
I haven't tried on macos, but yeah, the biggest problem right now seems to be implementation differences with how embedded spaces are handled. Earlier, the biggest cross-browser issues were pixel alignments within the QR codes, but those seem largely resolved.
It looks like Safari doesn't render this correctly (checked on macOS). Works fine in Chrome and Firefox, though. Must be a Safari quirk of some kind.
Impressive, but on iOS 27 even one of the examples don't work. Seems like it has an issue with spaces. https://imgur.com/a/tZGqtjR
Checked on my phone, Chrome+Firefox work, WebKit (through wpe-android) doesn't. Safari and WebKit can't render this font for some reason, I suppose.
Did you read the explanation? It says right there on the page why it happens.
Or was that text added since you viewed it?
The only thing I'm seeing there is that line-wrapping might do [something], and a suggested workaround (which, oddly, they don't implement on the page). And the line-wrapping issue doesn't look like that to me, at least when I do it.
I probably didn’t read it. But I also had to read it twice to understand what it meant.
I’m still not sure if this is the mentioned issue or a different one.
Just glancing I would say it seems a bit different.
Unfortunately the most important thing here is missing - the whole explanation, like how did we get there, what those fonts can do and so on..
Some details of how it works are in https://github.com/jimparis/qr-font/blob/master/design.md
Fair warning though: this was designed and implemented by an LLM, as an experiment to see if it was possible. I only guided it to a working solution by pointing out problems, and never dug deeply into its inner workings.
OpenType specification is Turing complete, its hinting engine does math during rasterization and its GSUB (Glyph Substitution, a layout and shaping engine) does glyph stacking, QR code correction, etc to finalize the QR. The nice thing about it is if you copy and paste it, it goes to the original text.
This doesn't use hinting. Some reasons why are listed at: https://github.com/jimparis/qr-font/blob/master/design.md#wh...
What a vector (no pun intended) for malware or other computation…
That’s a common downside of HN: submitters often link the GitHub repository rather than the project’s explanation. The article’s had the project link added at the top (just below the GitHub link) and it has a much clearer story.
This ... means the page could render a QR code for humans while letting bots see the actual URL. That is incredibly cool.
Or with some tweaks to the font code they could see a different URL…
This could be used for good (diverting bots away from where you don't want them) or evil (different destinations for user and other readers of the page could be used to trick people going to undesirable locations, because the apparent URL checks out find according to automated scanners).
Conventional web technologies already can handle this kind of use case, either by wrapping an image in a link tag, or using an alt= value.
I think qr code is more readable by bots than humans and I would prefer to see actual url...
Great idea, but it's a shame that it only supports Basic Latin (English-only).
This is SO COOL. Works perfectly in FF for me, if it can be made to work in safari then this might be one of the easiest ways to generate and display QR codes on the front-end.
Spaces are definitely broken in Safari.