Why are QR Codes with capital letters smaller than QR codes with lower case? | Hacker News Reader

Why are QR Codes with capital letters smaller than QR codes with lower case?

shkspr.mobi

319 pointstodsacerdoti123 comments

When QR codes first came out I thought it was really cool. But then re-entering meatspace after the pandemic I was honestly saddened to see so many in-person venues start using QR codes. QR codes are machine-readable, but they sure aren't human-readable, but why can't we have both? For instance, plain text using a low-pixel font with a dotted line underneath for error-correction and alignment.

Yes, I'd love to see menus printed in OCR-A[0].

[0]: https://en.wikipedia.org/wiki/OCR-A

OCR-A looks cool, but my above post isn't saying I want the menus in a machine-readable font, but rather I want the human-relevant parts of the lookup to be both human-readable and machine-readable.

>...I want the human-relevant parts of the lookup to be both human-readable and machine-readable.

There is OCR-B[1] for that. It is widely used as the human readable part of EAN/UPC barcodes used for laser scanners in retail. The relevant thing here is that the human readable part is never OCRed in practice because the barcode can be read much more reliably. OCR-B seems to be recommended simply because it is a well specified (ISO standard), easy to use (no weird licensing), high legibility font. Which is interesting because, as mentioned elsewhere on this thread, you don't really need a special font for OCR anymore. So it is a commonly used font that no longer serves the original purpose of the design. If you trained your OCR only on OCR-B you would likely get get some amount of accuracy improvement, but that would work for any high legibility font.

So the problem would be convincing app designers to read both things, where one of those things is much more reliable. I guess that might make sense for things that require high security, where the false negatives were worth the bother.

Getting back to the original article, OCR-B only has the good OCR characteristics for the upper case Latin characters, like with the QR code size thing, and for the same reason. If you are identifying something you generally want to use the larger, easier to read (both for people and machines), upper case characters. The lower case glyphs were added later to OCR-B as an afterthought.

[1] https://en.wikipedia.org/wiki/OCR-B

I'm not sure I see the distinction. if the human readable part is machine readable, there's no need for a separate machine only readable region. I'm on iOS and selecting text from images is assumed by this point. I'm not sure SOTA on Android for that though.

"I would love to see menus printed in OCR-A" just takes a regular human readable paper menu, and increases the success rate if you were to painstakingly scan each page to make a PDF with selectable text. That doesn't solve an actual need when sitting with the paper menu.

Taking a QR code that takes you to a URL, and writing out the URL in text does not enable anything, as you still must have an internet-connected device to retrieve the content, in which case you would most likely be able to scan the QR code anyway.

The point is to have e.g. a QR code, while still having human-readable content for those not having or wishing to use their smartphone in this interaction. E.g., just having the list of things on the menu printed in plain text (e.g., on a wall, over the counter, paper menu, ...), but also having a QR code with images and the ability to order directly to your table - stuff beyond what text would get you.

> Taking a QR code that takes you to a URL, and writing out the URL in text does not enable anything, as you still must have an internet-connected device to retrieve the content, in which case you would most likely be able to scan the QR code anyway

I often see things that I want to "look up later" while I'm passing by, but they only have QR code. I don't know if it is worth the time to stop and scan but if there's a URL I can just read it and remember.

To keep an actual URL for later you'd have to write it down or take a picture of it (which also works for the QR code, either by following it later or keeping the tab open). URL's aren't human-readable or memorizable, nor is it meant to be.

"Easy to remember URLs" are just domains that mostly match the human-friendly name of the place. As you are not memorizing a full URL, you can only really go to the frontpage, and so you can just memorize the name of the place instead.

It's a different story if there's just a random QR code with no clear purpose of ownership, but... maybe don't scan that.

I always find it strange here when I share an experience and people want to tell me why what I experienced was technically impossible. URLs don't have to be human readable but they often are, and the frontpage is probably fine indeed but to get there I need to know the name of the thing or some search term when more and more often--and this is the point I'm making--the only thing I'm given is a QR code.

You misinterpret - I am not saying that what you experienced was technically impossible (you saw a URL, later recreating a valid URL at least partially), but that your interpretation of what happened is neither practical nor possible in the general case, nor is it necessary. Let's try with an example:

You see a poster. "Samsung Galaxy, for real this time. Tune in on 1st of April to watch the ceremony live where we subjugate the last planet in the Milkyway.".

Scenario 1: The poster has a QR code, and a URL: https://events.samsung.com/press-room/world-domination. You memorize the hostname (events, samsung, com), and half a day later you manage to pull up a page for events, select the intended one, and get to the live feed.

Scenario 2: The poster has a QR code, no URL. You memorize "samsung galaxy", or "samsung event", or even just "samsung", and half a day layter you type this into your browser's address bar, which gives you as the first result the live feed you were looking for, or at the very least to samsung's event page.

"memorizable URLs" is not human-readable information, but computer-readable information constructed with certain rules to mimic human-readable information - e.g., the company name mangled to fit URL syntax. The original, unmangled information is easier to remember.

Scenario 3 the poster is a cool looking image with people doing something that interests me. There is a QR code and no other information.

Scenario 3 the poster says something is happening like "Neighbourhood dinner, Sunday at 7 -- Want to help cooking? Scan this code" -- There is a QR code but no information about who is organising it, where it is or how else to contact someone about helping to cook.

Yes, a name serve just as well as a URL, the point is that people begin to believe that a QR code is more convenient than text. Give me a link, give me a name, give me a search term, just give me something more than a QR code.

Then we agree.

Yes a URL is much handier than a QR code because I can read and remember it.

... no.

If you need to add human readable information (which is your scenario), a URL is never the right answer. Write a name or a sentence. Computer-readable information is for computers to read.

Just because something is OCRable doesn't make it structured data that can be used immediately. A table at a restaurant might have a QR code that takes me to a menu with the table number already encoded and pre-entered into the order page ready to go. An OCRable table number does not give me that, and an OCRable URL like https://fragmede.restaurant/menu?table=42 might work for HNers, but most humans won't recognise and understand their table number when going up to the bar to order.

"Fragmede.menu" costs $35 a year, which is roundoff error cost for a restaurant, and is a short-enough domain for a customer who wants to view a menu and order. No need for the "https://" which is implied. Adding a "?table=42" could be optional but isn't necessary, as the website in addition to simply presenting the menu could provide a means to order and if so have a little html input box when ordering to put their table number or whether it is pickup.

Sure it can be done, but there's no denying that a simple scan of a QR code instead of manually typing a URL would make life easier, as would some kind of alternative encoding technology that is more pleasing to the eye.

"if the human readable part is machine readable, there's no need for a separate machine only readable region"

So why are physical venues in 2025 presenting me with QR codes? If there is some randomish number (like another commented pointed out QRs may have a UUID number) or a checksum, then encode those randomish bits as a dotted rectangular outline or a line underneath, so a big QR doesn't ruin my human experience.

I have no idea which restaurants your frequent but take it up with them, not me. having a url written out http://restaurantname.com/menu on a sign that you can take a picture of and click on is functionally the same as a having a qr code that links to the exact same url

Having a short url like restaurantname.menu is not simply functionally the same as a qr code. A QR code is almost meaningless for me to look at...all that it says is that that there is a code hidden within these dots and I maybe can infer that the code contains a url to a menu (and maybe contains random tracking stuff). But restaurantname.menu in text communicates to me that these letters are almost certainly a url for a menu for restaruantname, and it is something that I can verbally say to the other people at my table and remember in my head.

So they can change the menu online without having to re-print it.

They can do that with a URL.

Scanning a QR code is far faster than typing a URL, and you need some sort of a computer to access the URL anyway, so providing a human-readable URL doesn't achieve anything.

A relatively short url like restaurantname.menu is something a human can say and remember, so it does achieve something more useful than a QR code. I might even be able to type or speak a short url quicker into my phone than for me to find the QR code reader feature in my phone and point and hold my phone still.

That's fine but it's moving the goalposts from the specified "reason for using a QR code" that I was responding to.

If they get you to use that QR code, they will get you to visit a URL and maybe show you ads, or sell your information to trackers. I mean with your tracking cookie, you visited a physical location, that's gotta be worth something.

In theory, if every QR in the building was different and they had the right sensors, they could also try to pair your browser fingerprint to your Bluetooth Mac, WiFi Mac, and your face. That pairing would have value on its own.

How is that different than a text url?

A simple short human-readable text url that a human can say and remember is not going to have a bunch of ".php?q=trackingcode&..." nonsense (though of course other trackers like cookies may still exist).

I don't know why the parent is getting downvoted...they bring a up very good point that hidden inside these QR codes are a bunch of tracking bits and the QR's ability to include tracking stuff may sadly be a significant reason why we see QRs way too much.

Both the human and the QR-encoded URL will be shortened and use a redirect to the URL with the tracking info.

this is not the point

Scanning a multi-page whole menu with a camera does not make it machine readable. And frankly, the menu is not in the qr-code, it is a link to the menu. What sounds appropriate here is to write also the content of the qr-code with plain letters, so one can type it, alongside the qr-code, for those who do not have a camera or whatever.

Now, the problem of requiring a mobile device to see the menu is a problem on its own, and while this is faciliated by having a qr-code vs having customers manually copy links on their phone (either writing them or with OCR), it is 2 separate issues for discussion. Moreover, OCR-A is not needed for any of that anywhere in the 2020s that we live.

The problems with QR code is that sometimes people have older smartphones or camera do not recognise them or, frankly, it being a means of obfuscating sth from humans. I have been in many situations with queues of people struggling for indeterminate reasons to scan a qr code to go fill up sth. If there was a simple link in plain text people could have even shared it between each other. Blindly trusting technology that can easily fail and is unnecessary for what one does and without redundancies is unwarranted imo.

you missed mine. if there is the text http://restaurant.com/menu.pdf I can scan that just as easily as I can a qr code, thanks to advancements in OCR technology.

It's 2025, regular english is machine readble

There is machine readable and consistently machine readable in a limited time under non-ideal lighting conditions with part of the code obscured using only cheap cameras and processors. Barcodes didn't just stop having a purpose in 2025.

Another common hangup is a legible font needs to unambiguously distinguish between lowercase eL (l), capital eye (I), the number one (1), and the pipe symbol (|), or at least for instance only deal with capital letters and numbers.

If a restaurant has no way to allow customers to not use their phone I normally just leave.

Generally speaking, I'm with you. However, there is one use case that's exceptional: when you're with a large group where every sub-party will be ordering & paying separately. It can be a godsend to have phone ordering when 25-50 people descend on a restaurant all at once (my typical use case being kids sports teams + family members). It's absolutely not ideal for experiential dining where you're going for ambience as much as the cuisine, but it definitely expedites the ordering process and the ability to keep a tab open is a huge benefit.

It's fine to have the options, there just needs to be a phone-free option as well.

I find that surprising because in my experience QR code ordering systems are almost always worse than paper menus and ordering at the bar.

The comment you replied to was in agreement with you. They're saying they don't want to be forced to order via a QR code.

Thank you for pointing this out! I think I missed a double negative.

Yes, if I cannot eat without pulling out my phone, then no thanks, I will leave my money elsewhere (which is what parent said).

Not a bad way to make a point locally, but wow are QR codes nice when you’re traveling and don’t speak the language. You get the menu, in a browser, with all of the translation and parsing tools on your phone.

(Offline) camera translation is the answer.

Having ended up in a situation where I attempted this:

no.

It is not the answer, it is a frustration where you wonder what "bean massacre pastry" is (chopped nut cookies, aka slivered almond cookies) or what they mean by "Surprise coriander special" described as "flavor of comatose with many spices in hot cow" as the translation. The accurate translation would be "mixed spice beef special" and "Beef with spice and vegetables."

Cameras are betterthan they were 10 years ago but machines are better when they have real sources in front of them

You know that you can scan/highlight the raw text and translate individual portions?

And sometimes, say in Chinese cuisine, the dishes are indeed using some flourished language. You get your translation and a peek into their culture. Win/win.

no, just looking at the properly translated menu on my phone is so much nicer

Waiting for Apple watch to have a camera.

And __not__ this one: https://wristcam.com

Seems unlikely. They day I can’t wear my watch in the changing room is the day I stop wearing it to the gym, and therefore stop wearing it altogether, and therefore stop buying new ones every 5ish years.

Why can't you wear a watch with a camera in the changing room?

It's normally forbidden because most people don't want to end up naked on some weird website without their consent.

But lots of people use their phones in the changing room ...

it's usually not allowed to have recording devices in places where people are naked.

I think what used to be considered "usually not allowed" is no longer true and a sign of one's age that you even remember not being able to use a camera any place/time. Someone could be using their phone without using their camera and they will look just like someone that is using their camera. People have become numb to it now.

> look just like

In my experience, there is usually an obvious difference between seeing a phone used as a camera versus not, based on whether it's aimed at an interesting subject or not. There are exceptions, like sitting with your elbow propped on the arm of a chair for a few minutes to avoid fatigue, which causes the phone to be at eye level and therefore perfectly vertical, but this is rare.

s/will/can/

Agreed. I like how most 1D barcodes have human-readable numbers/text printed under the barcode. For example, think of UPC barcodes on retail products. Not many 2D barcodes respect this convention.

This is directly caused by UPC codes being numerical and short, while 2D barcode have significantly higher, and often ASCII-space, data density in which human readability does not bring much of an advantage.

What does 1D barcode mean? I can think of no bar that can be represented in 1D.

A normal UPC barcode, as the parent said. The data is read along the horizontal dimension. The only reason the lines extend in the vertical direction is to make them easier to scan.

You're taking it too literally. 1D is the industry term for such code, to mean that data is encoded in one direction/dimension.

Getting hung up on the fact that the printed code needs some height to work isn't productive to the conversation.

i'm not hung up on it nor trying to be unproductive. i asked a simple question and then get chastised for it. that's not productive at all. In fact, someone much posted a much more productive response much earlier than you did, so you very much added nothing to the conversation

Whenever people are suggesting adding a QR somewhere (ad, in-app, etc) I always advocate for showing the short URL too. But about half the time they insist that "everyone knows how to scan a QR code". They clearly haven't tried to ask a few people to scan a QR code to see how easily most people do it.

I've seen QR codes to join a discord that have text under them that looks like

   discord.gg/{... a few random characters ...}

which are just fine to scan or type in.

My own 'discovery' about QR codes a few years is that you can make them "module 2" sized that ought to be easy to read with a low-spec system and have astronomical capacity if you use uppercase characters, a reasonably short domain and identifiers similar to random UUIDs. These were part of the system of "three-sided cards"

https://mastodon.social/@UP8/111013706271196029

but new-style cards put the QR code in front because (1) I have a huge amount of glossy paper that I can't print on the back of, (2) you can't read the QR code on the back if the card is stuck to the wall with mounting putting, (3) three-sided cards struggled with branding in that people didn't really understand the affordances they offered, a problem that the new-style cards attack in various ways.

https://mastodon.social/@UP8/113541119391897096

(Note the QR codes on both of those cards do not point at safebooru but at a redirect that I control that fits my QRL specification)

Personally I don't think any QR code for the web should ever require more than a "module 2" QR code and that printing a QR code which requires extra alignment markers is a sign of failure. (e.g. sure you can make a QR-code with 2000 bytes of form data embedded in it, but should you? Random UUIDs are so numerous and redirects so cheap that every new-style card like that Yakumo Ran card has a unique id because with inkjet printing it doesn't cost anything more)

That's basically converting a QR scanner into a text detector. It might work but why do they need to be human-readable? Most part of the encoded string would be UUID that's useless for human eyes anyway. After scanning, the important info will also usually show on the phone screen.

I want it human readable so I'm not presented with QR codes when I'm in meatspace. I'd rather see a pixel-font that say MENU://JOES-CHICKEN when I want to look up the menu at my local chicken restaurant than look at a QR.

If part of the data is just a random number like a UUID that is meaningless to a human, well that number could simply be placed after the pixel-font text or as a rectangle outline...if using a 3x5 pixel font then that gives 4x5=20 bits per character cell, so a 128-bit UUID with 12 bits of overhead could fit within the space of 7 characters...fine...but at least put the parts of the info that the human can relate to (like that this a MENU for RESTAURANT) as pixel text so both the human and machine are happy.

Or maybe OCR-A? https://en.m.wikipedia.org/wiki/OCR-A

There is no "after the pandemic" (yet). The pandemic is still ongoing. (Source: WHO)

No one in the real world actually acknowledges this as being fact. Further pushes by the WHO just lower trust even more.

So glad most people in the “real world” are experts in health an epidemiology.

Taking the same stance as most people has never been wrong.

100%, I remember this being a big pain during the period where places were open but you had to order from the table. If your phone didn't want to scan the code you were kind of stuck - and to make it worse some of them _deliberately_ degraded the code to add a cutesy logo or whatever.

My favorite QR code visual explainer:

https://qr.blinry.org/

Not very useful, as it doesn't support alphanumeric mode.

> For our code, encoding mode is Alphanumeric (2), but we haven't implemented how to read that yet. Sorry! Try another QR code!

Thank you for that! A lot is over my head, but very interesting none-the-less.

This site is the best visual explainer for QR code generation.

https://www.nayuki.io/page/creating-a-qr-code-step-by-step

It reproduces what the article is saying, with more detail.

Thanks, this looks like an awesome tool. I wish more web explainers took this "explain your work" approach. It's great that it uses the content you put in to illustrate the step-by-step breakdown.

All this bitwise optimization, but most of the QR codes I see in the wild have >100 bytes of useless cruft like https://engagement.bigcompany.com/campaigns/1485-0123/landin...

It's not useless, it just makes the tracking data (which it almost always is) easier to implement.

Also makes it harder to actually use because the requirements for camera focus get cranked way up.

thanks for wasting my time! :)

(nomel's profile)

Would be neat to have that as a game, and you get a timer that tells you how long you took.

Another example, Victoria Australia COVID tracking QR code.

https://nick.zoic.org/art/qr-codes-advice/#no-funny-business

It works though. Perhaps it would have been easier to use when optimized, but it’s a nontrivial effort - especially if the original requirements were bloated. To me it’s no different than misusing heavy JS frameworks or an electron app.

Here's a guy making a QR code by hand on a Go board, just the way the inventors did: https://www.youtube.com/watch?v=w5ebcowAJD8

I'm reminded of part of (my family) history where I discovered that my grandfather had worked on the UPC system.

The original "test blanks" for UPCs were steel plates with machined cuts in them, photoreduced down to small sizes for testing.

A good channel overall. Some things are better, some other worse but for instance, his explanation of the Bayes theorem is on par with the one from 3blue1brown

“a guy” aka Veritasium, the channel with 17M subs

What are you saying? He's so popular he cannot be referenced with a simple pronoun?

Sorry, meant no disrespect. I am assuming he's a guy; apologies if I'm wrong. :)

And that's why you should probably use base45 for binary data in QR codes: https://www.rfc-editor.org/rfc/rfc9285.html

Some discussion happened here about that when it was in draft: https://news.ycombinator.com/item?id=27628178

tl;dr: It is sadly not the most efficient encoding (and they missed an opportunity to make it actually base41, which could have been URL safe) -- as defined it only needs 41 characters (as 41^3 > 2^16).

The RFC is also not standards track, it's just "Category: Informational".

I think a better approach is to understand there are many circumstances where different sets of characters make sense for encoding data. There's no need to write an RFC, instead define a custom alphabet for them, using something like base-x[1].

[1]: https://github.com/cryptocoinjs/base-x

Or just use numbers. Simpler, no weird symbols, more efficient.

If your original data is not a byte sequence then it would indeed work. Otherwise you have to convert it back to bytes yourself, but no small x exists such that 10^x is just barely smaller than 256^y and bignum would be necessary for efficient encoding. Base45 doesn't need bignum and only incurs ~3.2% overhead [1] compared to the pure octet mode (which might be unsuitable for decoder compatibility and other purposes though).

[1] 32 original bits = 4 original bytes = 6 base45-encoded letters = 33 bits in the alphanumeric mode, so the overhead is 1 - 33/32 = 0.03125 for 4n bytes of data.

10^12 < 256^5 ≈ 1.1e+12, which isn't too bad. You could also use 10^118 < 256^49, which wastes less but is in bignum land.

But don't you want 10^x to be slightly bigger than 256^y, so you could represent all length-y byte sequences in x-digit number? In this direction, there's 10^53 > 256^22, but that is still in bignum land.

Yeah, use a bignum. QR codes are not very big.

And while 3% overhead is fine, encoding decimal digits in groups of 3 is only 0.3% plus a couple bits to round up to the nearest digit.

The problem with using base10 is that it cannot encode a URL. Alphanumeric is the simplest QR code encoding mode that can encode a URL.

Also, when I do the math alphanumeric is the most efficient QR mode, although just barely.

You can switch modes. (Yes that costs a dozen bits if you were otherwise able to stay in the same mode the entire time. Oh well, but I'd say it's worth it to avoid base45.)

And base45 is less efficient than looking at the efficiency of raw alphanumeric.

> base45 is less efficient

Not according to my math:

Numeric: 1000/1024 = 98%

Alphanum: 2025/2048 = 99%

Byte: 191/256 = 75%

Kanji: 13/16 = 81%*

Alphanumeric is the most efficient QR code encoding mode.

(Just to further make this clear, for QR Byte encoding uses ISO/IEC 8859-1, where 65 characters are undefined, so 191/256, which is ~75%. If character encoding isn't an issue, than byte encoding is the most efficient, 256/256, 100%, but that's a very rare edge case. Also, last time I did the math on Kanji it was about 81% efficient. *I have not dug too deep into Kanji and there may be a way to make it more efficient than I'm aware of. I've never considered it useful for my applications so I have not looked.)

> Alphanum: 2025/2048 = 99%

That is a semi-correct calculation of the wrong number. Base45 does not use all 45 characters in every slot. It goes 16 bits at a time, so the character storing the upper bits only has 2^16/45^2 = 33 possible values.

The most straightforward way to measure efficiency is to see that base45 takes 32 source bits, and encodes them into 33 bits. The way you're calculating, that's only 50%

But the better way to calculate efficiency is to take the log of everything (in other words, count how many bits are needed). Numeric is log(1000)/log(1024) which is 99.7%. Alphanum is 99.9%. Base45 is 97%.

And I don't know where that kanji number came from. It stores 13 bits at a time, mapping to 8192 shift-JIS code points, and the vast majority of them are valid. It's pretty efficient.

> Base45 does not use all 45 characters

Huh? I don't necessarily care about an exact "base45", I care about QR code alphanumeric, which just so happens to be a (generic) base 45 character set. For QR code, two characters are encoded into 11 bits.

>in every slot.

I've worked with the QR code standards pretty seriously and I am unfamiliar with the term "slots" being used by the standards. This is why I suspect your referring specifically to RFC base45 (although the term isn't used there either), which QR code doesn't care about. I also don't care about RFC Base 45 and would prefer to use a more bit space efficient method, such as using the iterative divide by radix method, which I also call "natural base conversion".

> base45 takes 32 source bits For QR code alphanumeric, 6 characters use 33 bits, not 32. way to calculate efficiency

The way we calculate this, for example, 2025/2048, we've termed "bit space efficiency". I'm not sure how commonly adopted this term is used in the rest of the industry. On the matter, I thought I had read "the iterative divide by radix algorithm" in industry, but after searching it turns out to be a term novel to our work.

This is also similar to the way Shannon originally calculated entropy and appears to be a fundamental representation of information. Of course log is useful, but it often results in partial bits or rounding, 5.5 in the case of alphanumeric, which is somewhat absurd considering that the bit is the quantum of information, again as shown by Shannon. There is no such thing as a partial bit that can be communicated, since information is fundamental to communication, so the fractional representation we've found to be more informative and easier to work with.

Granted, in all of this, when I have done the math (and I done a lot of math on this particular issue) there appeared to be some very extreme edge cases at the end result of the QR code where some arbitrary data encoded into QR numeric was slightly more efficient than alphanumeric, but overall alphanumeric was more efficient almost all the time. There are other considerations, like padding and escaping, that makes exact calculation more difficult than it's worth. I just needed to "most of the time" calculation and that's where I stopped.

For more detail of my work, my BASE45 predates the RFC by 2 years in 2019, then I published a base 45 alphabet, BASE45, by March 1, 2020, a whole year before the RFC. A patent including BASE45 was submitted June 22, 2021: https://image-ppubs.uspto.gov/dirsearch-public/print/downloa...

Matter of fact, because of the issues and confusion surrounding base conversion, I wrote this tool in 2019:

https://convert.zamicol.com

It is the first arbitrary base conversion tool on the web. It also was essential for our work with QR code and other base conversion issues.

> Huh? I don't necessarily care about an exact "base45", I care about QR code alphanumeric

> I suspect your referring specifically to RFC base45

> For more detail of my work, my BASE45 predates the RFC by 2 years in 2019

The RFC was linked in the comment I originally replied to. The same comment where you saw the term "base45", because I didn't repeat it in my original reply.

> The way we calculate this, for example, 2025/2048, we've termed "bit space efficiency". I'm not sure how commonly adopted this term is used in the rest of the industry.

It's not a good metric when the size can vary.

3/4 uses 75% of the bit space, and 512/1024 uses 50% of the bit space. But if you give 20 bits to each, the first method can encode 59049 combinations and the second method can encode 262144 combinations.

> which is somewhat absurd considering that the bit is the quantum of information, again as shown by Shannon. There is no such thing as a partial bit that can be communicated, since information is fundamental to communication, so the fractional representation we've found to be more informative and easier to work with.

You can use any base and the math is roughly the same.

Distinguishing between two symbols is just the minimum. You can't transmit .3 bits but you can easily transmit 2.3 bits. If your receiver can distinguish between 5 symbols at full speed then 2.3 bits at a time is the most natural communication method.

> There are other considerations, like padding and escaping, that makes exact calculation more difficult than it's worth. I just needed to "most of the time" calculation and that's where I stopped.

Yeah, that's fine. They're both efficient. My deciding factor is not the tiny difference in efficiency, it's the ill-behaved symbols in alphanumeric.

One of the things that Data Matrix got right was being able to shift between encoding regimes mid-stream. Many character sets can be represented in radix-40 (so three characters per two bytes), and the occasional capital character can be handled by a shift byte. If you have a long string of digits, they can be encoded in 4 bits/char. You can even put raw binary in there if need be

A QR Code consists of a sequence of segments. Each segment has a mode - numeric, alphanumeric, kanji, or byte. It is possible to shift between encoding regimes by ending a segment and beginning a new segment with a different mode. https://www.nayuki.io/page/optimal-text-segmentation-for-qr-...

Some 1D barcodes have inline shift symbols like you said for Data Matrix, though. e.g. https://en.wikipedia.org/wiki/Code_128

I was going to reply to point that out. I'm not surprised you're the one to point it out first!

I seems to me best approach would be to compress the contents with a Huffman code or some other entropy encoding. All this business of restricted character sets is just an ad-hoc way of reducing the size of each symbol and we've got much more mature solutions for that.

For entropy codes to be effective for such short strings you need a shared initial probability table. And if you have that you are effectively back at special encoding modes for each character set.

Another level of "Why": QR codes were invented in 1994 in Japan for automated scanning. As you all probably know, Japanese uses Kanji, and hiragana+katakana; it does not rely on the Latin alphabet. However, Japanese speakers are familiar with it and occasionally use it for specific purposes. While katakana is commonly used for transliterating foreign words, sometimes the exact original spelling is preserved for stylistic reasons, especially in acronyms or single-word cases.

However, in such cases, they usually use only capital letters. In Japanese, there's no distinction between lowercase and uppercase letters. So for them this distinction is, if you allow some leeway, similar to the differences between normal, italic, or bold letters in English. So it makes sense with this context, if you are making a "group of letters and numbers", to default to uppercase + numbers as the normal/shorter version.

tl;dr: Upper case letters can be represented in "alphanumeric" mode, which uses 11 bits per two characters (5.5 bits per character, but padded if the length is uneven). Lower case letters are not included in alphanumeric mode, so the QR code has to be represented in byte mode, which uses 8 bits per character.

Is it safe to uppercase the protocol part of the URL?

I decided to use segments and stick to lowercase "https", because I didn't trust various implementations out there to handle "HTTPS" correctly. Should I?

RFC 1738 and 2396 both say schemes are lowercase but implementers "should" treat uppercase as equivalent.

RFC 3986 explicitly says schemes can have uppercase letters but are canonically lowercase, and says that they are case-insensitive. But it also still says that implementations "should" accept uppercase letters as equivalent.

WHATWG's URL standard mandates case-insensitive matching.

In practice anything you scan a QR code with will probably not have a problem with the uppercase scheme.

On this exact issue my work did extensive testing and researching various standards.

Although we found browsers were out of alignment with standards on all sorts of matters, we found broad compatibility with upper case. (Of course, meaning everything before the path. The interpretation of the path is delegated to the server which may or may not be case sensitive, up until octothorpe, #, which is then solely interpreted by the browser.)

How many implementations do you care about? All major phones do very well at QR scanning these days including uppercase URLs.

Leaving a naked domain name like "www.example.com/1234" was not quite as good, but at least iPhones, Pixels and Samsungs worked well IIRC.

I used this trick to allow printing of QR codes at smaller resolutions for 4+ years, and phones have gotten noticeably better in that span at handling QR codes printed at smaller sizes, with uppercase, nonstandard shapes, borders, you name it.

If you make https: lowercase and the rest uppercase, with QR encoding that does smart segmentation, I'm pretty sure you can still get most of the benefit... but, exercise for the reader.

The smallest v1 QR code is 21 modules. That can fit 20 uppercase letters.

The 25 module size, is not that much bigger and can get 38 uppercase or 26 lowercase letters.

Strangely not including the scheme doesn't seem to consistently work on an iPhone when in uppercase, a string like "FOO.COM/BAR" does open as a URL, but a string like "FOO.UK/BAR" does a search. I think it's best to include the full HTTPS:// prefix (and I don't think it being uppercase really matters, I'd be surprised if that breaks anything).

I did a lot of trial and concluded the same: for non .COM address we had to use the full HTTPS:// prefix otherwise iOS won't open it. On Android it opens any TLDs, even unusual ones like .MD or .NZ.

> If you make https: lowercase and the rest uppercase, with QR encoding that does smart segmentation, I'm pretty sure you can still get most of the benefit... but, exercise for the reader.

That is actually exactly what I ended up doing. I care about all mobile phones and tablets, and I was worried whether any implementers actually tested uppercase protocol names.

In which case, you can still uppercase the domain to get a partial size reduction as QR code does allow for switching to other encoding modes in stream.

If you control the destination server, you can also upper case the path.

In the old days, Yahoo's build of Apache (yApache) included an option to automatically lower case urls before matching them. Super handy because lots of urls were coming in from print publications and you could never get publications to show urls properly, nor get users to type them in properly.

> Byte mode uses (you guessed it!) 8 bits per single character.

8 bits is enough to represent the entire ascii char table, there must be some other limitation going on. QR code control chars maybe?

The linked "byte mode" table only has 45 individual chars. This could be represented with 6 bits with room to spare..

> 8 bits is enough to represent the entire ascii char table, there must be some other limitation going on. QR code control chars maybe?

The specified capacity of "25 characters" for QR code size is 25 characters in alphanumeric mode, not in byte mode.

> The linked "byte mode" table only has 45 individual chars. This could be represented with 6 bits with room to spare..

Even better than that - it's 5.5 bits per character! Each pair of characters is represented as a single 11-bit code unit. (This works because 45 x 45 = 2025, which is just barely under 2^11 = 2048.)

There's apparently some support in the QR standard for mixed-encoding codes, but few encoders seem to use that.

Apparently you can specify the text encoding in a thing called “ECI”, but support varies and most readers just guess the encoding by the bytes. I imagine these days most are UTF8 https://stackoverflow.com/questions/9699657/is-utf-8-the-enc...

> The linked "byte mode" table only has 45 individual chars.

No, that link is for alphanumeric mode, which uses 5.5 bits per character (45 * 45 = 2025 <= 2048, so it fits in 11 bits).

This reminds me of a silly nerd lie I like to tell non-technical people: "Did you know that capital letters take up 4 more bits of storage than lowercase letters?"

Reply on news.ycombinator.com