>...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 re

>...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 https://en.wikipedia.org/wiki/OCR-B