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.
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.
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.
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.
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.
ChrisArchitect | a day ago
shreddit | 23 hours ago
diroussel | 21 hours ago
jrmg | 21 hours ago
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!).
foodevl | 17 hours ago
jeroenhd | 7 hours ago
andix | 23 hours ago
diroussel | 21 hours ago
Or was that text added since you viewed it?
andix | 20 hours ago
I’m still not sure if this is the mentioned issue or a different one.
foodevl | 17 hours ago
Groxx | 17 hours ago
jeroenhd | 7 hours ago
LoganDark | 23 hours ago
athenot | 23 hours ago
trillic | 22 hours ago
b112 | 5 hours ago
zb3 | 22 hours ago
altairprime | 20 hours ago
karunamurti | 19 hours ago
foodevl | 17 hours ago
bch | 16 hours ago
foodevl | 17 hours ago
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.
andonumb | 20 hours ago
jhogervorst | 20 hours ago
maguay | 11 hours ago
dspillett | 5 hours ago
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).
bulder | 3 hours ago
notRobot | 4 hours ago