I am trying to use ZXingObjC to generate PDF417 barcodes for my iOS app. I've got it all working, sort of. It generates the barcode and displays it on the screen. Unfortunately, sometimes the barcode is unreadable by a 'real' scanner.
If the encoded text is all just upper or lower case characters, for example, "Now is the TIME for all good men", then the generated barcode is perfectly readable.
However, if the string contains just one number, anywhere in the string, then the barcode is unreadable. It's just not recognized by the 'real' scanner.
Other encoded strings produce barcodes that decode as gibberish.
I am wondering if I need to do more configuration to generate PDF417s properly. For example, it says on the ZXingObjC website "Use UTF-16 for all PDF417 characters". How would you do that?
Are there other configuration options I should be setting?
I know this is an obscure topic, but hope someone has some knowledge about this. Thanks in advance.
Related
I am trying to create an Apple Wallet pass for SMART Health Card QR codes.
The content of the QR code will be something like the following dummy data, and it appears to be generated with a medium error correction level:
shc:/567629095243206034602924374044603122295953265460346029254077280433602870286471674522280928613331456437653141590640220306450459085643550341424541364037063665417137241236380304375622046737407532323925433443326057360106452931531270742428395038692212766728666731266342087422573776302062041022437658685343255820002167287607585708105505622752282407670809680507692361773323356634342439664440596761410443377667202663224433674530596175400038397052612140292974753658337372662132066669047253044469405210524536242721550377673434280323045475690310233670562227414567090555653507636250537239522776211205312561442568282012726838630039087127042463716936535535602928393065580072763158437500341209546904210458383257586630101033123422114008776058732325243477645920113037325929083272452732223707055550412927584543582550667760036577724025621136525340592771740903663844771261692077697211447057562509437029626707254539002011763240720310114260256672645965627243654061066553770056003044082967606162724306592273682223412466107335331229606157521057357572327529693965670332063208596309543400076452696835713027450728663529345234666377297208583525543653527774072234735706452828641140633528387577054371703966706421520708254156041170353656054471407636552612616834377244090406554327122559623453686207006139712936404138601156656945315611255669116044703333731263580306106975715411702932060511012768634011703371553353213365032550756476005853005224547339310064671161682376335069647622323339523133724171327531702738363650063527592633763908656123314363227707566731311074
Using most standard QR code generators, this gives the following (correct, expected) QR code.
In my pass.json file, I have the following segment for the QR code:
*snip* "barcode":{"message":"shc:\/567629095243206034602924374044603122295953265460346029254077280433602870286471674522280928613331456437653141590640220306450459085643550341424541364037063665417137241236380304375622046737407532323925433443326057360106452931531270742428395038692212766728666731266342087422573776302062041022437658685343255820002167287607585708105505622752282407670809680507692361773323356634342439664440596761410443377667202663224433674530596175400038397052612140292974753658337372662132066669047253044469405210524536242721550377673434280323045475690310233670562227414567090555653507636250537239522776211205312561442568282012726838630039087127042463716936535535602928393065580072763158437500341209546904210458383257586630101033123422114008776058732325243477645920113037325929083272452732223707055550412927584543582550667760036577724025621136525340592771740903663844771261692077697211447057562509437029626707254539002011763240720310114260256672645965627243654061066553770056003044082967606162724306592273682223412466107335331229606157521057357572327529693965670332063208596309543400076452696835713027450728663529345234666377297208583525543653527774072234735706452828641140633528387577054371703966706421520708254156041170353656054471407636552612616834377244090406554327122559623453686207006139712936404138601156656945315611255669116044703333731263580306106975715411702932060511012768634011703371553353213365032550756476005853005224547339310064671161682376335069647622323339523133724171327531702738363650063527592633763908656123314363227707566731311074","format":"PKBarcodeFormatQR","messageEncoding":"iso-8859-1"} *snip*
When this pass is added to Apple Wallet, I get the following QR code in the Wallet app:
This technically does appear to encode the same data. However, because the QR code in an Apple Wallet pass is so small and the code is so dense with unnecessary junk, I haven't had much luck getting any QR code readers to actually read it from my device's screen, like how a Passbook pass would normally be used.
I didn't find any way to set the error correction level in Passbook, but when I tried generating the QR code using different error correction levels to check, even the highest error correction level wouldn't produce a QR code like the one my Apple Wallet produced. My guess, given how repetitive the right 2/3 of that second code looks, is that it's null padding, but I'm not sure.
What's happening here, and how can I fix it so that my passes contain the QR code from the first example without all the additional junk? If it isn't possible to fix, is there a way for me to just embed the image of the correct QR code on the pass but have it displayed large enough to scan?
========
Update: removing just the shc:/ header seemed to pruduce a QR code that looks closer to what is expected; although this header is necessary and so this is not a solution, I'm guessing it means Wallet is just having a hard time encoding it effectively.
The code in Apple Wallet looks very different because it uses an inefficient method to encode the data in question.
Apple Wallet (PassKit) likely uses the CIQRCodeGenerator Core Image filter to generate QR codes. The filter automatically chooses the most suitable encoding mode based on the given data, and it chose binary/bytes mode in this case. Because the vast majority of the SMART Health Cards data is expressed in numbers (which only carry ~3.3 bits of information per digit), encoding it in binary mode (8 bits/character) is rather inefficient. This is why the QR code looks much denser yet repetitive.
When you removed shc:/, the resulting QR code seemed more "correct" because the filter was then able to encode in pure numeric mode. Funny enough, if you changed shc:/ to all uppercase, the filter would encode in alphanumeric mode, which is still more efficient than binary mode for this data.
Some other QR code generators could handle this better as they are able to segment the data for maximum efficiency. In fact, the framework protocol described as much — binary mode for shc:/ and the optional chunk prefix, then numeric mode for the rest.
Unfortunately, there doesn't seem to be a way to fix this within Apple Wallet, at least as of iOS 14. The Core Image filter is simply not flexible enough to encode data using multiple modes, and PassKit itself still leaves a lot to be desired.
iOS 15.0+ has fixed this. For shc:/ content it has a lower level of error correction: M now.
I hope Apple would back port this to iOS 14 or 13.
So I'm currently working on a project that requires scanning GS1-128 barcodes. So far, for other barcode types, we've been using AVFoundation's scanning without a problem. AVFoundation can read Code-128 (which GS1-128 is encoded in); where we're having the problem is that it doesn't look like AVFoundation is giving us any of the FNC1 characters to identify which numbers in the barcode are attribute identifiers and which are values, or I'm just missing something. Has anyone had any success with this?
Thanks!
The company I work for has a program that is no longer supported called QADisplay. Inside of this program is a tool for annotating images. It's very similar to photoshop in that it takes a layer based approach to the annotations with each annotation as its own class in Delphi 7. These annotations are stored as the base image and a text file with the information describing the contents of the annotaion.
The issue is that the text that is displayed in the annotations is somehow encoded in the text file. For example, if the annotation displays as "Arial" (without the quotes), the text file will be written as:
TEXT (Type of annotation)
5 (Length of the literal string, in this case: Arial)
07)I86P (The encoded string)
What I need to do is extract all of the text from the annotations in preparation for the installation of our new software system.
I am not familiar with Delphi and do not have access to the source code. I have tried to disassemble the executable but haven't had much luck there. Does anyone have any ideas on how to approach decoding this? I've googled around a bit (Arial "07)I86P") and found some results relating to virus scan error logs and things of that nature but no dice on anything that I found helpful in relation to the issue I'm having.
That is not a standard text encoding. Maybe it is encrypted?
Without documentation or contact with the original developers, you will have to reverse engineer the app. Using a disassembler/debugger like IDA, if you can pause the app after it loads 07)I86P into memory, you can follow the code as it processes the characters, which will help you reconstruct the decode algorithm.
I stuck in my project. I have searched more but can't find the solution. My problem is when i scanned barcodes more then one from my handheld barcode scanner. I am not getting any such type of character by which i can separate the scanned string to save in array. Is there any way by which i can get the each scanned value separately. Any help will be appreciated. Input can be come from any Handheld/Ring barcode scanner.
I got a bunch of .DOC documents. I'm not even positive they are Word documents, but even if they are, I need to open and parse them with eg. Python to extract information from them.
Problem is, I couldn't figure out how they were encoded: UltraEdit's Conversion function wouldn't correct the text no matter which encoding I tried. OpenOffice 3.2 also failed displaying the contents correctly (guessing Windows-1252).
Here's an example, hoping that someone knows what pagecode it is:
"lÕAssemblŽe gŽnŽrale" instead of "l'Assemblée générale"
Thank you for any tip.
Greenstone digital library http://www.greenstone.org/ provides pretty good text extraction from word documents, including encoding detection.
Running msword in server mode gives you a range of scripting options- I'm sure detecting the encoding will be possible.