vcard QR code not working with some Android devices

[Jeffrey_Smith]

There are 2 ways to generate a vcard/QR code in Indesign,

1. Method 1 Type: Business Card

2. Method 2 Type: Plain Text with code:

BEGIN:VCARD
VERSION:3.0
FN:First Last
N:Last;First;
END:VCARD

Here's what I have observed:

• Androids can read Method 1 QR code without issue
• Most Androids cannot read Method 2 QR code
• If text code from Indesign's Method 2 is used in other QR code utility, then Androids can read QR code.

It seems as though something is happening in the QR code generation process. You can use Method 2 in a data merge workflow, and is the reason that I would like to continue using this method. I have tried various versions of Indesign. I have tried versions 2.1, 3.0, 4.0 of vcard.

Is there anything else to try in using Method 2 and have QR code read by Android?

[James Gifford—NitroPress]

The following test data:

BEGIN:VCARD
VERSION:3.0
N:<lastname>;<firstname>;<middlename>;<prefix[,prefix]>;<suffix[,suffix]>
FN:<firstname> <lastname>
NICKNAME:<nickname[,nickname]>
TITLE:<title>
ORG:<company name>
EMAIL;TYPE="work":<email address>
EMAIL;TYPE="home":<email address>
TEL;TYPE="work":<work phone number>
TEL;TYPE="home":<home phone number>
TEL;TYPE="cell,text":<mobile phone number>
URL;TYPE="work":<web address>
END:VCARD

Created the following QR code:

Which reads in fine on my Samsung S9. (Just to confirm, I have tested this right off the post screen, as well.)

I suggest that any failure of a vCard code to load is due either to a fault in its encoding, or a fault of the device/app being used to read it. QR codes, after all, have four stages of function—

• Correct data encoding.
• A QR reader that can successfully read the encoded data.
• A device/app that can successfully parse the data and pass it to the correct destination app.
• A destination app that can successfully parse and store the data.

In vCard codes, for example, it's easy to include fields that a particular Contacts app may not recognize or store correctly. (Proper app behavior is to ignore any unrecognized field.) There are often complaints that a device did not store all four email addresses, or a photo, or a title — not because there was anything wrong with the first three steps, but because the app did not have four email slots, or a title slot, or store photos.

There is no fundamental fault in ID's creation of any QR code if a correctly formatted plain text string is used. Whether any given device can properly decode and use that data is up to the device, and its settings. As for variant results, some devices/readers/apps might tolerate certain flaws in the data formatting while others do not; I recall a specific case where an extra (faulty) semicolon did not affect code reading on one platform but caused a read failure on the other.

You might want to review the primer on QR codes from InDesign I wrote; link is above, or here:
http://www.nitrosyncretic.com/DPR/dpr_qrcodes.php

Happy to hear any corrections or questions.

[CarolAlmeida]

I follow precisely your article, since march, to write the plain text. Thank you for that, btw.

And I wrote many, exaclty like your example.

I've been sending those QRs to a lot of people here in the company, (more than 20 received them already) with different android devices, (including Samsung) and all of them had the same issue: an empty vCard.

The only solution was to paste this plain text in the plugin.

That is why I believe it is an ID issue.

[James Gifford—NitroPress]

Have you analyzed the actual, generated QR codes to see if the strings are identical?

Here's one of the only raw decoders I know of. Compare the two strings:

ZXing Decoder Online

What I would look for is—

• If ID encoded the plain text string exactly as provided;
• If there is any difference between the ID and the plugin strings, as encoded.

Since I can't replicate your problem and have never heard of any general fault in ID's encoding — for one platform or another or all — I remain convinced the problem is somewhere other than ID's performance.

[James Gifford—NitroPress]

I would also suspect a read issue. If your codes are dense, the Android devices may simply be reading them incorrectly. Have you tried it with large images of the code? With the pixels at least 2mm across?

[James Gifford—NitroPress]

And one more simple question: are you encoding the same string in both ID and the plugin, or using a different method in the latter?

[CarolAlmeida]

Yes, the string was always excatly the same. That is why I suspect it is a ID issue.

BEGIN:VCARD

VERSION:3.0

N;CHARSET=UTF-8:Doe;Jane;;;

FN;CHARSET=UTF-8:Jane Doe

TITLE;CHARSET=UTF-8:Marketing and Sales Assistant

ORG:ACompany

PHOTO;TYPE=PNG:<url>

LOGO;TYPE=PNG:<url>

ADR;TYPE=WORK;PREF;CHARSET=UTF-8:;;Josef-Straße 33;Berlin;;53333;Deutschland

EMAIL;TYPE=INTERNET,WORK;PREF:jane.doe@acompany.com

TEL;TYPE=WORK:+4922228888;ext=0

TEL;TYPE=DIRECT,VOICE;PREF=1:+4922228888;ext=56

TEL;TYPE=CELL,VOICE;PREF=2:+491719993333

URL:<url>

NOTE:Languages: German (native), English

END:VCARD

[CarolAlmeida]

as a side issue, I can't add the extension (like the old PABX number) to this card in a way that does not prevent the number from being dialed. None of the following solutions work:

• ;ext=
• \;ext=
• \,ext=
• ;
• ,

[James Gifford—NitroPress]

I'll just have to concede that you're seeing some real difference between the generated codes, but I'm at a loss to explain why. (I'd have to see a set of the code strings, be able to generate them myself and then test them in various ways and on various devices, which puts it outside the range of what I can do here — for one thing, I don't have any iOS devices at hand and I can't really dial all the numbers to check them. 🙂 )

ETA: In a perfect world, the generation tools would create identical QR codes from identical strings. If there are variations, using exactly the same data (string, image files, etc.) then ID may be creating a code that faults in the various ways I suggest below, without it necessarily being a technically faulty code. Correct encoding, that is, but some aspect that chokes the Android reader.)

But the 'why' eludes me; I simply do not know of a prior case where the InDesign encoding is faulty. There are faults, as noted, in the data munging and string-building done by the form-based entry, but that's why I actively deprecate using the forms and learning to write the code strings as a professional practice. But cases of ID not encoding a given string... I know of none.

That is a jam-packed record you're encoding, though, and that alone may be causing problems. Photos and logos take up a ton of data even in tiny thumbnail forms used. Multiple phone numbers and addresses and long phone numbers, ditto. So I imagine the resulting code are quite fine-grained, and thus have simple readabiliy/recognition hurdles under the best conditions. If they aren't physically large and perfectly sharp, a reader might have problems with them for a cascade of technical reasons. I suggested creating some very large versions and seeing if they read better with the Android devices; that would be one test.

You might also try creating them without the photo and/or logo. It may be that the encoding process for those is not the same for both ID's implementation and the plug-in, and the former is doing something non-compliant that chokes the Android reader/parser.

Other than that last point, though, I'd expect to find the problem somewhere in the data-handling chain after code creation; the Android reader may simply be tripping over a valid but un-parsable passage, or is having trouble sorting out the many, many fields for passing to the Contact applet.

Have you tried other QR code readers on the Android devices? I often use QR Droid and I experiment with others from time to time. The fault may lie exclusively with the default/OS reader; I am dimly recalling other cases where QR Droid was more successful at passing the data to an applet than the OS one was. That's not a good solution since any valid QR code scanner should work and it's unreasonable to expect users to go find an alternate one. But it would pin down the problem area.

As for the extension number, I'd pin that on a combination of encoding and app function; you may need to make some deep dive into what encoding characters translate to the right dialing characters. (I used to work in hardwired telecom and spent too many frustrating hours trying to get Box A to properly signal Box B; absurd workarounds were sometimes needed.)

My mostly-mostly sense is that you're pusihing the limits of what a wide spectrum of mobile devices — not just Android v iOS, but OS versions, UI variations, user settings and Contact/data-receiving apps — can handle in vCard complexity and size. While the standard and the overall implementation lets you pack in all that auxiliary information, not all systems — especially not all destination apps — can use or manage it, and the fault may lie there. As a real starting point, you might want to make sure those Android devices actually accept, parse and store all those fields; it may just be that it's too much excess data for those apps and the device can't sort out the useful from the ignored.

[CarolAlmeida]

I sent those QR to be tested here in the company and, when generated by ID, the Android devices come up with an empty contact. When gerated by a plugin though, it reads. iOs can ID and plugin either way.

I tried without the images. To be fair, to have the link makes no difference in the outcome, since nor iOs or Android can read it anyway.

The extension/PABX is the most problematic piece of information, by far. The QR plugin or ID generated, neither iOs or Android can solve this.

I am aware that I've been pushing the limits of the vCards. But the plain text should let us do that, right? 🙂

[James Gifford—NitroPress]

The key(s) still may be trying a larger image of the code, and a different QR reader on Android. Mostly as diagnostic steps.

The overall problem here is, as I noted before, that QR is an ecosystem, not just the codes. All of the parts and steps have to work, and I have a growing if somewhat subjective sense that a lot of readers aren't fully compliant, and their implementation (in getting the parsed data to the right receiving app) is not consistent.

Pushing the limits of the system is all well and good, but if you're doing it when it knowingly excludes some subset of readers — for any reason or anyone's "fault" — and to including bags and bags of data that most systems will ignore or bypass.... maybe te solution is to push a little less. I am not even sure what Contact apps read things like logos and photos; I am pretty sure none of the default system ones do. Why clog up the code and the process with all that data?

The same may be true of the EXT field. Encoding the data is one thing; getting the Phone app to dial it correctly, at the right time etc., is probably dependent on the Phone app itself. I'd look at working examples of extension dialing, if you can find any, and work back. And implementation — do you expect the EXT to be dialed automatically, or just present for the user to tap, or even dial? If a particular person is at a given extension and that's how you reach them, I'd just encode it on their work phone number, with a pause as necessary. Not sure of the value of putting it in a separate field except for user reference.

My overall advice here is common to all new-ish, complex systems: just because the feature is there doesn't mean you have to use it. You may simply be overreaching (entirely within the standard/process/etc.) and colliding with limitations in the broader implementation of QR/vCard.