InDesign QR generator and diacritic characters in V card

[axelr16807532]

How to input diacritic characters (like é) in the QR code generatosr?

Option+e e results in √â if scanned

[James Gifford—NitroPress · Accepted solution]

The short answer is that you can't. The QR code creator in InDesign defaults to v2.1 of vCard, which does not support the extended character set.

The only solution is to use another QR code creator, one that does support vCard v3.0 (or 4.0, although my sense is that 4 is not widely supported yet). The problem there is that there are no good creation tools and apps among the hundreds out there — all, or most, seem to be crippled by things like added tracking, data scraping, binding the code to a pay platform, etc.

I am, oddly enough, in the middle of writing a long info/how-to article on using InDesign's QR code generator (which is trustworthy, standalone and transparent) to manually create a variety of data types, including vCard 3 and 4, but it's not done yet.

The short answer, if it's not too cryptic, is to use the Plain Text mode to enter the vCard format manually. It's not complex, but it is a bit involved. If you can't find a good example of vCard structure, try the Wikipedia article (not something I say very often!) as a start, and if you can wait, I should have this reference article done sometime this weekend.

• https://en.wikipedia.org/wiki/VCard

You should be able to cut and paste the example structure into the Plain Text field, add any fields you want, and export successfully. If not, try again. 🙂

[James Gifford—NitroPress]

Here's a shortcut that might help.

Create your vCard QR code as before. In InDesign, hover over it until the popup appears. That will contain the actual text string of the code. Copy it into a Plain Text QR field, but update the second line to VERSION:3.0.

That should work. (To help with the popup string, you might grab a screen snip to look at while you retype it.)

[axelr16807532]

Thanks James, the workaround works perfect!

Converted the input to tekst, changed version to 3.0, typed the diacritic characters and copied it as plain tekst in QR generator in ID: problem solved!

Have a great weekend all

[Jitka Art-D]

Hi, unfortunately it doesn't work for me. I tried it on iPhone 13 mini (ok there) and Samsung A52 (not there). Plain text was showing on Samsung, not a business card. Adobe indesign version 2023 and 2024.
Thanks for the advice

[James Gifford—NitroPress]

Don't use the vCard form at all. Write your own plain-text content.

[Ivo K]

shame, adobe is not able to fix their own bugs!

anyway, this was a working workaround! thank you!

[James Gifford—NitroPress]

It's not really a bug, just a feature that has not been updated to manage any vCard standard later than 2.1.

Using the Plain Text mode bypasses nearly all the limitations of the feature. But you can't back up and use the form options without risking the kind of unwanted changes you encountered.

I see this thread is old enough not to have included this link; you may find this information useful:
http://www.nitrosyncretic.com/DPR/dpr_qrcodes.php

[Rishabh_Tiwari]

Hi @axelr16807532 ,

Thank you for reaching out. I tested this on my end, and it seems to be working. Would you mind testing it on a different device/scanner? Some scanners may not support certain character encodings, so it's important to test the QR code on different devices.

Let us know if it works, or a different device or if you still need further assistance.

Regards

Rishabh

[Rishabh_Tiwari]

I am so sorry for the confusion. Please avoid my previous response as I didn't tested this on a V-Card. Instead, it was a plain text. On testing it further, I am getting the same character, so I'll get this checked from the team and will update the discussion.

[James Gifford—NitroPress]

Yes, this is a longstanding limitation of the QR code creator — it only produces v2.1 codes, and v2.1 does not support accented characters on most readers, most notably iOS's. (But, hey, nobody uses that, so it's not a problem! 🙂 )

Adobe really, really needs to either update the code creator to use v3.0, or allow selection of the version. I don't think there would be any problem at all if it was just hard-coded to v3.0, except possibly with some very old and outdated readers.

Overall workaround article coming, as I noted.

[Rishabh_Tiwari]

Thank you for confirming @James Gifford—NitroPress I'll share the feedback with the team.

[CaiPE]

Is there any update on this? I followed the suggestion above to use the InDesign plain text QR code generator containing vCard code, and the resulting QR codes work fine on iphones but open an empty contact on Android devices.

This seems to be a common issue that others are experiencing. Using the exact same vCard code on other web based QR code generators results in a QR that works perfectly on Android, so could it be an issue with the way InDesign encodes a plain text vCard QR code?

Would love to have this working as I'm not keen on using online generators with private personal info.

Thanks!

[Robert at ID-Tasker]

@CaiPE 

When you scan them - how different content is?

Have you tried to check what are the "pixel" differences - you could just place on two different layers in InDesign or use Photoshop.

[James Gifford—NitroPress]

I don't believe anything has changed (for the better or the worse), but it's best if you avoid the form-entry creation and write your own plain-text data for ID's QR code generator.

I can't think of any reason a whole code would work on one platform and not the other; it's usually details such as not reading fields with accented characters, or a reader that does not read and pass along the less common fields.

The acid test is always to scan them to a reader that shows you the scanned data, not what it decides to do with it after sorting and parsing it. You have to set readers to a special mode, usually, and not all of them have that mode. But the process is at least three steps long (read/parse/pass to applet) and any of those can go wrong even if the code is technically perfect.

ETA: You also don't say where you're scanning the code from, how dense the data is (how fine the grid, that is) and whether the code is being presented with enough resolution/fidelity to be read easily. It may be that one OS or the other, in any random instance, can do a better job of reading a faulty/fuzzy code.

While QR codes aren't magic, they also aren't "monolithic" and a bunch of things have to be correct/work right for a majority of devices to be able to read and parse them.

[CaiPE]

Well yes – the QR codes generated as plain text in InDesign and on a web based QR code generator look completely different, but I don't know what to do with that information haha. (QR overlay image attached, ficticious contact info used)

For clarification I am using InDesign's plain text QR code generator and inputting vCard code which is correct and works perfectly on Apple devices – and also works on Android devices when generated with the same code outside of InDesign. The quality of the QR code is not the issue, I am across resolution and quality issues. The QR does 'scan' on an Android device but opens an empty contact, it is unable to get the contact information.

I have tried using only the fields that InDesign uses in the built in vCard form (assuming they are commonly supported fields) – I have tried the code as v2.1 and v3 vCards, to the same result. There are no special characters present.

[James Gifford—NitroPress]

Everything in resolving problems like this comes down to a raw read-back of what's actually encoded in the QR matrix. You need a reader, any reader on any platform, that offers that raw-data mode. It's there that you will find how IN handled the input, how a web tool handled it, etc., and often where you will find some overlooked glitch.

Just some added thoughts, in no particular order:

• As far as I know, the ID encoder is 100% reliable. I can't think of a case where it wrote a broken matrix, other than in the narrow and known instance of forcing vCard data to v2.1, which can change any data characters outside its range. But even there, the code isn't broken (it works fine, to certain limits); it's the data transformation that's mangled.
• The difference between code creators comes down to two factors. Assuming the exact same plain-text data is fed in, they should be identical (within perhaps a few dots; the algorithm is so complex is may vary a little in actual runtime on each implementation), unless:
  • The encoders are using different error correction levels. ID has one fixed level; another tool might allow selection or simply use a higher or lower EC factor. (The higher the correction factor, the lower the amount of data within the same grid-size parameters, etc.) This can't be checked easily as I have yet to find an available QR reader that identifies the EC level in use.
  • One encoder is changing, adding to or padding the data, usually with tracking or pay-me code. This can be identified by a raw code read, but may be masked if a reader only shows the parsed and sorted data.
• Again, a successful result has at least four steps on each device. Simply going *ping* - it works on iOS and *ping* - it doesn't work on Android is of little use in resolving the problem. Ideally, every code will read properly and parse into the final app on every device. When it does not, you have to identify the point of failure —
  • If the device simply will not read the code, the code image is likely at fault — blurred, too fine-grained, damaged, etc. Generatred codes rarely have technical faults that prevent reading, but the scanned image has to be sharp enough for the device to decode it. Make it larger, less blurry, etc. especially if displayed on a screen or printed at small scale.
  • If the code is read and there's no good result —
    • The actual data may be faulty. This is where examining it with a raw code reader pays off. It may have an error in the encoding string; it may have unintended changes (the 2.1-v-3.0 thing); it may have been padded with tracking etc. data that corrupted it.
    • The reader may not be able to assign the data to the right app. Sending a URL to 'Contacts' or vCard data to a browser will likely cause a blind failure, much like what you're seeing on the Android device.
    • The app has to be able to parse and read the data. This is a bigger problem than most of the others. Including fields in vCard that the app doesn't read or support leads to frustration because "the iPhone won't load Titles or Locations or something" — because the app just doesn't, well, load those fields. There are many other faults that can occur at this step because the data, data order, app, fields, and support for the data are not universal and not consistent.

Because you're getting a blank result in Contacts, I'd say everything on the Android is working up to parsing the data. And you're back to using a raw data check to make sure the encoded data is exactly what it's supposed to be, so that you can analyze why one platform is reading it and one isn't. This often comes down to things like hard vs soft returns, spaces in the wrong places, and other details that don't seem significant until you actually try to get them through the whole data transfer process.

One important thing is not to rely on only one input method. Most phones have QR code reading built into various apps; if that doesn't work, bypass it for the OS-level reader or, best of all, a third-party reader that doesn't ass/u/me too much about the system, setup, apps etc. And has that "show me the raw data" mode.

[CaiPE]

Thank you for all this information – much appreciated! 

However I can't see how the ID encoder is 100% reliable when a quick Google search shows that others complain of the exact same issue. As a graphic designer, I just need InDesign to create vCard QR codes that work with data merge (hence using the plain text input and not vCard form) and can be read on most common mobile devices.

I don't understand the intricacies of different encoding processes that can turn the same data into a working or non-working QR code, and even if I did, I'm not sure how that would help with the issue of InDesign not correctly encoding for Android. 

[James Gifford—NitroPress]

Okay... forgive a little exasperation, here. First, you tacked your inquiry onto an older thread that doesn't have much to do with the problems you're reporting, so we start with a bit of murkiness as to what applies to what, and it's hard to scroll up and down and figure out what might have already been said, or not.

Second, you haven't provided anything but anecdotal data about how you're doing everything right but the codes work on (some unidentified) Apple device but not on (some unidentified) Android device.

You haven't given any indication that you have worked through (or grasp) the multiple levels at which a code reading problem can be encountered, and keep referring to it all as a monolithic issue with ID's code generator as the obvious fault. (Proof: you found "other complaints" out there in the Wild World Web. — but of exactly what, you don't make very clear. Color me 'Surprised.")

The levels of code interpretation and data transfer are anything but absolute across the spectrum of devices and apps; the one thing that is fairly fixed is that few code generators themselves, especially ones from major software houses in use for many years, actually make faulty codes... that your Device A could read it is pretty much proof absolute that the code it not at fault here. That your description of Device B is that it reads the code but can't quite figure out what to do with it is additional proof that the problem lies somewhere other than the code... and after you get past the insanely complex encoding algorithm, QR codes are just simple, linear encoding of a text string. Everything else depends on how that string is read and interpreted, and IME that's where nearly all faults are encountered. (Including in the original, accented character, 2.1-v-3 issue.)

Here's an analogy: You create an absolutely perfect, gorgeous brochure in ID and have it printed by the finest press in New York. You sent it to the recipient, who reports that he's unable to make head or tail of it, and says none of his co-workers can, either. That the brochure is composed in English and the recipient reads only Polish — or maybe, is blind — does not make any of this InDesign's technical fault.

Beyond the technical reading of the code — and we have indirectly established that both devices are reading the code — the successful result comes from a chain of apps, applets, readers and such on each platform doing its job correctly. I've explained that in detail. Saying that you've made this A/B test and platform B fails, so it must be ID's fault... well.

When you can provide a couple of samples of QR codes, created using any dummy data you like and using ID's code creator, that work fine on a defined Apple device but do not work on a defined Android device... we might be able to identify the actual cause of the problem. From both experience and following your reports as closely as I can, I hereby bet one virtual wooden nickel that the problem lies in any of the interpretation steps except the actual coding/creation of the QR code. (Because that's how all prior cases have turned out, no matter how many people have posted complaints that "ID made me a bad code.")

Examples, when you have a moment. Thanks.

ETA: providing the EXACT plain text strings used to generate your samples would open other lines of testing. Thanks.

[CaiPE]

Thank you, that tool you linked below was helpful to see the difference between the QR code I generated online and the InDesign plain text generated version using the same vcard string.

I've attached both QR codes and both decode results, and although I'm not sure how to fix it, it seems the InDesign QR code is not giving a Parsed result. I'm not sure why Apple devices (tested on several iphones) are able to get an address book entry from that, but Android devices (including Samsung and Pixel phones) can tell it's a contact but only get empty data fields.

Apologies for jumping into an old thread originally! I mainly wondered if there had been any update to the issues discussed previously as an Adobe employee had responded here, and someone also commented on Jan 9 2024 with an issue that sounds similar to what I am experiencing. Any help is appreciated, honestly not trying to be a nuisance 🙂

[James Gifford—NitroPress]

Just to close out this thread (hopefully) with useful info — it is harder to find a good "diagnostic" QR code reader than I thought. The nature of the micro-industry just seems to prevent anyone from creating and then maintaining something that doesn't generate revenue.

But for anyone who wants to look at the bare bones of a QR code's data, from the raw encoding string to the stripped and parsed data, and a few other useful bits (although not the error correction mode — that would be nice), this web tool seems to be trustworthy, stable and useful. It is basically orphaned and no longer updated, and there are comments that it and some possible device apps have trouble with some newer iterations of code, but it's the best we have, more or less:

• ZXing Decoder Online

and a sample decode:

• 

[Tedvat]

Hi guys.

Try to put ";VERSION:3.0" in one of the input boxes.

I put it right behind the title i used, it dosn't show

[James Gifford—NitroPress]

Does not work (reliably); does not overwrite VERSION:2.1 string in the data. Whether it does so on data parsing is probably up to the device. Don't use this hack; use Plain Text and properly structured vCard data instead.

[Tedvat]

Of course James, Plain Text is the way to go. But this fixed the problem for a customer of mine, who unfortunately had no knowledge of vCard data. And this fixed the iPhone problem temporarily. I would definitely use vCard myself.