Improved QR code generator for InDesign 20.1

[Mike Witherell]

Hi gang,

I cannot find specific info about the InDesign 20.1 release. Specifically, what version of QR code does ID now support? (I just made one that seems to support 3.0. Wiki says that there is also a version 4, a version 10, a version 25, and a version 40) Is the accented letter issue fixed? Is this accomplishing any improved compatibility with iPhones?

[Jeffrey_Smith]

Indesign 20.1 can create a Version 40 QR code. This code can contain up to 1852 characters. I tested an ID generated ver 40 QR code on iphone and was read with no issue, including text with accented letters.

[Mike Witherell]

Thanks Jeffrey,

How did you test for that?

[Jeffrey_Smith]

I created a text QR code with a lot of characters including accented letters [é]. Scanned the code with iphone (camera app) and viewed and verified the content between what was entered and what displayed on iphone.

[Mike Witherell]

Oh, I guess I was expecting something more difficult!

[James Gifford—NitroPress]

Count the legs and divide by 4. 🙂

[James Gifford—NitroPress]

Remember that what the form-driven entry (especially for vCard) and plain text entry support are two entirely different things. The only significant limit I know of, under Plain Text, is that the error correction level is fixed at the second of four levels (M?).

If there were changes to the QR code generator, I didn't see anything about it; pointers to release notes appreciated. (It's way overdue for some update/TLC!)

ETA: Just noticed I'm still at v20.0.xxx; if changes are coming in dot-one I look forward to them.

ETA2: Yes, with v20.1 the Business Card/vCard form now generates a v3.0 code. But I see no other changes and the selection is again fixed. But that should end the aggravating accented characters problem so many (especially in Europe) have been encountering. I'd still recommend using Plain Text for all QR code generation, to bypass all but that EC limitation.

[Mike Witherell]

James,

This is the only thing I've read so far:

https://indesign.uservoice.com/forums/601180-adobe-indesign-bugs/suggestions/41767447--id-4208669-qr...

[James Gifford—NitroPress]

That was the long-standing bug in ID, hard coding vCard as version 2.1. They now hard code it as v3.0. There should be no more accented character issues.

If anything else was changed,  it's way subtle. But good enough for now.

[Brad @ Roaring Mouse]

"Yes, with v20.1 the Business Card/vCard form now generates a v3.0 code."

Yup! finally.

Although it doesn't update any existing v2.1 ones in a document, one merely needs to select each and open "Edit QR Code" then click OK to close the dialog and it will regenerate in v3.0.

[Robert at ID-Tasker]

Although it doesn't update any existing v2.1 ones in a document, one merely needs to select each and open "Edit QR Code" then click OK to close the dialog and it will regenerate in v3.0.

By Brad @ Roaring Mouse

No need to do it manually 😉

[Brad @ Roaring Mouse]

It's not doing it automatically for me. What am I missing? Yes, the underlying code is updated to v3 vCard when you go to edit it, but the actual graphic hasn't changed intil you force apply it from what I am experiencing.

[Robert at ID-Tasker]

It's not doing it automatically for me. What am I missing? Yes, the underlying code is updated to v3 vCard when you go to edit it, but the actual graphic hasn't changed intil you force apply it from what I am experiencing.

By Brad @ Roaring Mouse

Sorry, by "not manually" I meant "through scripting".

[James Gifford—NitroPress]

There's probably a window here for a really good, solid, error-checked script to do this update. An efficient implementation would identify the vCard codes and update them selectively, since no other codes are really affected by the change.

Not sure what else could be done auto/magically, with scripting, or IDT or anything; it's not like we can intelligently update and insert accented characters that might have been left out.

Now if the devs would just add one drop-down, to choose Error Corrrection level, if not expand this change to allow selection of the vCard level (2.1, 3.0, 4.0, and expandable)... the base encoder would be a very powerful tool with or without automated help.

[Robert at ID-Tasker]

[...] Not sure what else could be done auto/magically, with scripting, or IDT or anything; it's not like we can intelligently update and insert accented characters that might have been left out. [...]

By @James Gifford—NitroPress

That's why I need good tutorials...

Yes, it's perfectly possible to do it "auto-magically" with IDT 😉 even if you need to edit them in full.

IDT can export codes as Snippets - to get information about what is currently inside - and then generate new ones. 

Even translation "on the fly" would be possible - IDT could connect to ChatGPT or something to check spelling. Or even use WORD, if user has it installed. Or use InDesign's built-in spellchecker.

Yes, it can be done with "regular" scripting - but it won't be as convenient.

[Robert at ID-Tasker]

And why to make life so hard - for the person who edits this INDD file - or files 😉

IDT can export text file - DOC/RTF or just TXT or to an online database or whatever - then person responible for the changes can make them - do double/triple-check - then send this file back - even in pieces - then it can be automatically imported back - saving the operator all the hassle.

But this process would require paid version of IDT.

[Robert at ID-Tasker]

There is a way to force InDesign to refresh the code - but as creating it from scratch is easy - it's no longer relevant. 

[James Gifford—NitroPress]

I wouldn't really want any autobot to "correct" all the names etc. in my contact database. Updating existing codes to v3.0 so they are processed correctly is one thing; correcting any blunt-force fixes that got the v2.1 versions to work is not going to be that simple.

[Robert at ID-Tasker]

I wouldn't really want any autobot to "correct" all the names etc. in my contact database.

By @James Gifford—NitroPress

Not sure what do you mean? In what database?

[Brad @ Roaring Mouse]

I wouldn't want them to be automatically regenerated either*. I suppose what could be implemented is a warning dialog informing of the change and "what do you want to do about it?" kinda thing.

(* I haven't used IDs v2.1 vCards in anything recent anyway, mostly becaise of the various phone incompatibilities, so it's kinda moot. I swirched long ago to an external vCard QR generator anyway as I have done upwards of 150 business cards for one large client and it was easier to have them generated from a database)

[Robert at ID-Tasker]

I wouldn't want them to be automatically regenerated either

[...] 

By Brad @ Roaring Mouse

By "automatic" I meant "no manual clicking".

Overall, the process is the same anyway.

For example, if you would need to update the domain - or phone number / email / etc.: 

1) get current info from the code, 

2) replace domain name, 

3) generate a new code. 

Yes, you would've to check them - but you would've to check them anyway - even if done manually, right? 

[Robert at ID-Tasker]

OK, here is a crazy idea 😄 

Knowing where codes are - I could either: 

a) export them alone - as a bitmap or vector, 

or 

b) export PDF, rasterise in Photoshop and then crop, 

then automatically read those images and compare with original information 😄 and generate report if they're OK. 

Can even send you an email 😉 

100% automated process: 

1) export of the current contents, 

2) edits - either external or "local", if it's just an update of a domain, change in a phone numbers, etc. - something that's "easy" / has a pattern, 

3) import and regeneration, 

4) export bitmaps, 

5) verification. 

Things that require/d a lot of "normal" coding, are piece of cake using IDT. And a lot is possible even in the free version.

[James Gifford—NitroPress]

I think maybe some of my offhand comments got taken too far down a specific road here. Maybe not. But to clarify, I think there are two forks to this whole conversation, one nearly trivial and one so complex I can't think of a fully workable implementation.

As far as I can tell, the ONLY change in the QR code generator for 20.1 is that it writes "v3.0" to vCard codes instead of "v2.1" — if it is actually encoding things any differently, it's not evident.

So re-generating QR codes with a quick call and exit of the QR code menu simply does that, writes the new string value to the data matrix. It makes no change to the other data or the code. But it means that the millions of readers out there expecting 3.0 will no longer choke on accented characters (and as far as I can tell, some don't, depending on how rigid the overall interpretation scheme is).

So any automated solution to open and rewrite QR codes would be fairly straightforward and, for some immediate but diminishing window, useful.

My other comment, about "fixing" the actual data in the code, is much more speculative. As far as I've been able to determine, InDesign accepts and encodes accented characters and other things not allowed by the v2.1 standard — that is, it's not stripping them to base roman forms or any such thing. So the data should be there with any QR code for vCard, as provided by the original designer. It's just not read correctly by some readers when they see "v2.1" and then encounter "forbidden" characters.

So there may be no need to touch the QR code data at all in this update process.

My thought, incompletely thought through, was that there might be QR codes in which the designer deliberately stripped out accented characters to get codes that work, for certain levels of "work," on all readers, despite things like names and place names being faulty in their original language. I was thinking there could be some process to fix these errors and restore accents where needed... but no simple dictionary or lookup function will do any adquate job. It will need wetware, advanced AI, or some advanced language tool/s to do even a 'mostly' job — all way beyond any scripting, automation or generic processes that can be implemented in ID.

Or so I see it. One task is simple, useful and can be efficiently achieved. The other is almost on a level with automated translation of content — advanced, difficult and maybe impossible, and maybe not worth pursuing for this very, very narrow application.

[Robert at ID-Tasker]

@James Gifford—NitroPress

Yes, you're right - it all depends on circumstances and the end goal.

That's why the option to export current contents for "manual editing" would be the best option.