@Aaron said:
@PeteyF said:
The barcode is not a checksum, per se, it contains the actual data. There's no need to OCR the (typed) fields if the data is in the bar code. It likely loads the data straight from the barcode into the database, and then minions have to verify the handwritten bits that are vital, like passport numbers.
I sincerely doubt that they've found a way to compress the contents of an entire form into a single bar code. It's a checksum.
Edit: Actually, maybe I'm wrong, some of those 2D bar codes can apparently accomodate a few thousand characters per square inch or something. Weird. But then that's the problem, isn't it - how in the world is a layperson supposed to know that that's where the actual information is, and that nobody's even going to look at the information they type/write in except to double-check what's in the weird symbol in the corner?
By reading the FAQ/barcode links above the form downloads-
(Which exposes yet more clunkiness...)
What information can be found in the barcode? Barcodes on passport application forms will contain the following fields of information:
- Surname
- First Name(s)
- Surname at Birth
- Date of Birth
- Place of Birth (City, Country)
- Permanent Address
- Mailing Address
Passport Canada officers, as per the current process, will manually enter all other required data. (<==emph added!)
Yes, it contains data, but very little actual data. And there's probably a checksum for what is in there.
The Real WTF (ignoring the scan your passport step!) here is the damn PDF. Let's take the worst of the worlds of user interface and paper forms and combine them together to miss the point even further.... A layout for a paper form has no relevance to optimal screen user input, and this form doesn't take advantage of eliminating duplicate data entry; 'Surname at birth' is likely the same as 'Surname' for 50+% of the people, have it default to the Surname entry but be editable to a newer name if necessary. Likewise with 'Perm Addr' and 'Mailing Addr' - likely the same or to have shared elements to be worthy of defaulting one from the other.
Instead of a series of fields grouped logically/optimally on a webpage screen, this thing forces you to meet the space requirements of the paper page.
And then you end up receiving any number of hybrid results from the user, from all hand-written to anywhere from one typed field and the rest hand-written to all typed and only printed for signatures.
Which have to be 'MANUALLY ENTERED' by government workers or contractors. !!!!
Canadians, Your tax 'Loonies' at work. (Perdon l'double-entendre/Forgive the double-entendre...)
How about a web app that shits out a completed PDF at the end of the process? Well, then Adobe wouldn't get $10,000US for Live Cycle designer, that's why...