Published February 2023

QR Codes in InDesign
James Gifford

CONTENTS

1 — QR Code Basics

2 — Creating QR Codes Using InDesign Options

3 — Advanced QR Code Encoding Using InDesign

4 — Exporting QR Codes from InDesign

 

---

1 :: QR Code Basics

There may be a tendency for readers to ‘skip to the good stuff’—the specific techniques for QR code creation that follow. I urge all readers to start with this informational and background section, even if it seems unnecessary or too much concerned with irrelevant nuts and bolts. Understanding what QR codes are—and more importantly, correcting any misunderstandings about them—will go a long ways towards effective implemention of the creation and customization information that follows.

QR Code Technical Basics

A QR code’s rectangular pattern of square dots is a compact way to encode information for optical machine reading, whether the ‘machine’ is a smartphone or a warehouse scanning system. Their use at a consumer/general user level has come and gone over the years since they were introduced. At one time, it was almost mandatory to have them on business cards and such; their use there is now much more selective. But used in the right way, for the right purpose, and with the right data encoded, they are almost irreplaceable as a way to pass along links, contact information and complex ID data in a simple, static, printed source.

QR codes are self-contained. Their entire rationale and purpose is that they require no support system or background database for interpretation; that as much specific information as is needed can be encoded right into the ‘barcode’ itself. UPC codes on products and ISBN codes on books (both more literally ‘bar codes’ because they are read linearly) contain no information except a series of numbers, which are often reproduced along the edge of the bar coding for human convenience. Without a database or other reference, the numbers are largely arbitrary and meaningless.

“Bar” codes are called 1D (one dimensional) or linear codes, because they are read from one line across their bars. QR codes are called 2D (two dimensional) codes, because the entire X-Y pattern has to be read for decoding.

Not so with QR codes, which can hold almost 3,000 characters of data right in the pixelation of the pattern. No database, no online link and no secondary reference is needed for a reader to extract the information. The only thing that's required is for the code be readable: that its printed resolution be adequate to sharply distinguish the black and white pixels, and that most of it be present.

Most, because QR codes use a technique called error correction to both speed their reading and help ensure the information is retained even if the code is damaged, smudged or partially missing. Besides being useful out in the real world, this feature is what allows some QR codes to be partially overlaid with an icon or logo. Such codes are actually “damaged” by the added art, but the error correction allows them to work anyway.

Try creating a fairly complex QR code and printing it out or displaying it at about two inches across. On paper, use something like a coin to obscure different parts of it; on the screen, maybe a snip of post-it note. You’ll find that the code is often readable with a sizeable bite of it missing.

There are four levels of error correction that range from “L” — Low, 7% correction, which can only correct slight errors, to “H” — High, 30% correction—which can make badly damaged codes readable. The higher the level, the less overall data the code can hold, due to the need for redundant data and correction info. InDesign creates all QR codes at the second level, “M” for Medium (15% correction). The third level up is "Q" for Quality (25% correction).

Of course, the information contained in a QR code can be and often are used as a lookup pointer, such as a simple stock number, an encrypted tracking number, or a URL. The ability to encode any number of alphanumeric digits allows more sophisticated pointers, though.

At a (very) technical level, QR codes can encode their information in four different ways, each optimized for a certain type of data and use. In practice, most QR codes that graphic and layout designers will create will use—or will effectively use—straight encoding of bytes in an alphanumeric string up to about 2,900 characters long. The other modes are more suited to encrypted or dense numerical data.

“Dynamic” QR Codes… not!

It is important to understand that the data encoded in a QR code, be it a five-digit number or 500 words of text description, is fixed and permanent. Once generated, the information will not and cannot change until a new code is generated using new information.

Put another way, there is no such thing as a “dynamic QR code,” and anything purporting to be such, or any service offering to provide one, should be treated with great caution. It is possible to set up a dynamic response to a QR code, but not a changing, ‘dynamic’ code itself, and the difference is crucial to understand. We'll come back to this point.

To be complete, the one place a QR code might fairly be called “dynamic” is on a web page or kiosk screen, where a code might be rapidly updated depending on user input, choices, time of day, and other factors. Each code itself, though, remains a static element.

But in general, the term “dynamic” as it is tossed around by the various code services and marketing gurus is meaningless — and often misleading! — marketing-speak.

QR Code Creation Apps & Services

There are only two ways to get data into a QR code: to use an app to generate the latter, given the former, or to use an online service (app or web page) that will do the job for you. It is not possible—within anything like reason—to craft a QR code using graphic skills alone, as can be done (with some difficulty) for simpler bar codes.

If you’re interested in the real 'guts and gears' of QR codes, you will want to at least skim through a copy of the defining standard, ISO/IEC 18004:2015. The complexity is… breathtaking.

The problem then becomes selecting an app or service to produce your QR code or codes. This is not a trivial issue, because the field is laden with pitfalls and outright traps.

First, there are very few completely standalone apps that generate QR codes. InDesign’s is one of the few. The majority, even those that present themselves as standalone or local on computers or mobile devices, use web or remote services to achieve the conversion. And all of the services are, of course, web-based.

This is a problem because some very large number of these services, and ‘app-services,’ are deceptive, convoluted or outright dangerous to use. Here’s why:

• Many online services that offer “free” conversion will add their own tracking information to any URLs presented for encoding. This means your downstream clients and users will have their usage and activity tracked by an unknown, un-accountable third party. Some of the redirection may not be entirely benign and could result in malware infection of any device that scans the code.
• (This became endemic in the restaurant/menu industry early in the pandemic, when paper menus were replaced by table-top QR codes. More than one service—many out of Russia—offered panicking restrauteurs “free” code creation and online menu hosting... often with malware, spyware or data scraping from each patron included “free” as well.)
• Many online services that offer immediate conversion and may call it “free” actually return a code that is obfuscated and/or redirected through their servers. Clicking on it will send the user to the end destination, as above... for a limited number of times, after which payment is demanded to continue the forwarding service.
• An unwary designer might already have 10,000 brochures in print before this little quirk is discovered. There is also no guarantee against the above tracking, or any other undesirable action by the (unwanted and unnecessary) intermediary.
• (This service, offered more openly but with the silent deception that the redirection is ‘necessary,‘ is the source for most claims that a QR code is “dynamic.” The unwary designer may fall for a number of sham arguments and false advantages in the belief that all QR codes must be handled by such a pay service.)
• And finally, even the most ‘honest’ conversion service that returns a patently correct, static QR code may well be scraping data from that submitted, both URLs and—much more significantly—the often detailed personal contact data entered for vCard codes. That unwary designer may find, down the road, that they have handed over a detailed directory of an employer or client’s company structure, including sensitive information such as senior staff’s direct email and cell numbers.

So: I unreservedly recommend against using any online service for QR codes, or any app that is not from a highly reliable provider that guarantees the data remains local, secure and unmodified.

InDesign’s QR code feature is the only such app or tool I know of that meets this standard—at least, the only one that is commonly available to designers from a trustworthy supplier. There are undoubtedly much more costly specialized tools out there. But with a little understanding, InDesign’s QR code creator will do any job any designer or information management specialist could need. There’s no need to deal with strangers.

QR Code Graphics Considerations

Everything has its price, and for QR codes, more encoded data comes at the price of finer granularity and smaller data pixels in the actual code. Yes, it is possible to encode very long URLs, exhaustive vCard data sets or even short-short stories in a QR code, but the resulting code will grow in number of pixels high and wide, and thus the relative size of each pixel will shrink. The finer the grid and the smaller the pixels, the harder it will be for readers to interpret the QR code quickly (or at all), unless the code is made physically larger for clarity.

At the limit of about 2,900 characters, a QR code will be 177 x 177 pixels, meaning that for each to be a reliable 0.5 millimeter across, the code will have to be about 3.5 inches wide. At a an extreme 0.25mm resolution, the code would have to be almost two inches across, and unless printed with a very clean, sharp process, may not be readily readable—or readable at all—by most QR code readers.

Data size, grid size and readability are opposed forces for QR codes. It is best to keep the data content as low as possible unless you have complete control of the code’s reproduction at a very high quality level.

QR Code Colors

QR codes can be created in any two colors. InDesign, like many generators, offers a two-color palette to allow creation in almost any code and background color combination. Once created, the graphic image (JPEG, PNG, etc.) can be recolored in any image editor. (This is, for some reason, one of the big come-ons of the pay code services. You have InDesign, which means you almost certainly have Photoshop—or Illustrator, for vector code exports—and can color away to your heart’s content. Be sure to use “fill” and scaling procedures with anti-aliasing turned off, so as not to distort the code pixels.)

Contrast is essential for rapid, reliable reads, so QR codes should be composed of one dark and one light color, if not always black and white for maximum contrast. The smaller the QR code will be presented and the finer the pixel grid, the more essential high contrast between the colors becomes.

In theory, either the code or the background can be the dark color. In practice, a light code on a dark background sometimes seems more difficult to read reliably, especially at higher grid densities. It is well to test both ‘polarities’ as actual prints at the desired size.

While reversed codes are not uncommon (a white code on a black or very dark package background) and the contrast rule is sometimes ignored (such as with one color of printing on the silvery aluminum of a drink can), using a dark code on a light, matte background is recommended.

Testing QR Codes

All QR codes, generated for any purpose or by any method, should be tested before they are placed in general use. This is doubly important for any printed use, and triply so for any printed use where a large volume or high cost of printed goods is involved.

A quick test with any convenient reader (smartphone, tablet, etc.) is good enough for development of a a project. But at completion, before a digital production is released or a printed project is sent to press, each QR code should be tested with as many readers as might be at hand — ideally, at least one Android and one iOS device, and if available, an older version of each. For print, the testing should be done on the very final PDF generated, either from the screen or (better) from a test print.

Testing should ensure that the code reads quickly (a variable, based on the reader and the complexity of the code) and accurately... and then, if the code requires some action (SMS or email send, web link, WiFi login) its functionality should be tested through completion.

2 :: Creating QR Codes Using InDesign Options

The InDesign QR code creator, accessed under Object | Generate QR Code, is a full-featured QR code generator that has five different data input options, all of which deal with the data as alphanumeric characters. (Technically, as bytes; there is another QR code mode that uses alpha characters more directly.)

The differences between the options are largely in how the data is entered into an input form. The generator then applies (alphanumeric) content formatting for the code so that it is correctly interpreted by readers.

As set up for use within InDesign, it will produce:

• SMS QR Codes — a valid destination text number and a messsage of up to 165 characters can be entered. Scanning this code with a text-capable device will send, with or without a pause for approval, the message to the designated phone number.
• Email QR Codes — a valid email address, subject line and message body can be entered. (The message body can probably be up to the ~2,800 or so remaining character limit.) Scanning this code with an email-capable device will set up an email message and send it, with or without a pause for approval.
• Web URL QR Codes — a valid web address or URL of almost any length can be entered, and should be fully formed (prefixed with http:// or https://, and complete to a page or final destination element).
• If no web prefix is used, http:// will be added to the string. (If the secure prefix, or a variant such as ftp:// is desired, it must be included manually, and will replace the automatic default.) Note that no validation of the URL is performed, and it can in fact be complete nonsense. QR codes generated with this option should be rigorously tested.
• vCard Codes — InDesign calls this option “Business Card,” which is a little vague in that there are several contact-info data format. It actually uses the (most common) vCard format. Multiple fields of contact information may be entered using this option, and they will be encoded in the standard vCard format for parsing and automatic addition to most contact lists.
• The number of fields is limited (to, for example, one phone number of each type and one email address) even though the vCard format allows dozens of field types and duplications of fields (for, say, work and home phone numbers). This standard entry form will cover a majority of needs, but more complex vCard structures can be created using the custom process descibed further on.

InDesign has the significant fault of creating only v2.1 vCard codes, an older standard which has several limitations, the worst of which is that accented characters will be mis-encoded and read as garbage on most modern QR code readers. This limitation can also be bypassed by using the custom process.

The actual encoding and structure of the first four code types will be discussed in the custom section below.

• Plain Text QR Codes — any string of alphanumeric characters may be entered into the text field, up to about 2,900 characters in all. Characters outside the ASCII 128 base set (ISO 8859-1) should be tested to be sure they encode and decode correctly. This entry mode may be used to emulate any of the others if the correct field names, format and structure are followed. Most QR code readers should decode the entire text content, but it will be presented as a single block of unformatted text. Line returns and paragraph returns may or may not be honored by the code reader’s display.

It is this plain text entry mode, however, that allows us to use InDesign’s QR code generator for completely custom codes.

3 :: Advanced QR Code Encoding Using InDesign

By entering pre-formatted text in the Plain Text entry mode, QR codes of any of the predefined types may be created, along with improved and extended versions of them, as well as codes of other types not directly supported by ID’s entry options. Each of these modes is discussed below, along with a comparison to the default ID feature, if applicable.

Reading Raw QR Code Content

ID’s QR codes, like the vast majority of QR codes in use, are simply a text string of a few to hundred to thousands of alphanumeric characters. It can be difficult, though, to read the raw encoded string from a graphic code; readers read, decode and parse the information into formatted display, stripping things like SMS, URL and vCard field codes. It can thus be difficult to analyze a code’s real contents, learn how a new code type is formatted internally. or diagnose problems with a code.

There does not seem to be a good “raw” QR code reader that will simply display the encoded string, although some claim to do so in their app store listings. (Many... fib about such things.)

Within InDesign, at least, though, there is a subtle workaround. When you create and place a QR code, you can hover the cursor over it… and the popup data will be the actual encoded string, or at least the first 100 or so characters of it. This will not work for QR code images from other sources, placed in ID, or codes encountered anywhere else. That “good raw reader” is sorely needed!

Encoding Plain Text (as, well, Plain Text)

There may be times when all that is needed in a QR code is plain, unformatted text content. This could be used to encode warehouse storage info, book summaries, clues for open-field games or art displays, or the like.

Usage is simple: enter the text you want the code to return, using only characters from the ISO 8859-1 standard.

• Keep the amount of text as low as possible, to ensure the code is of readable granularity.
• If you can avoid breaking text into paragraphs, the text will be compatible with the greatest variety of readers. To help readability, you might use slashes or pipe symbols ( | ) to separate sentences.
• The vCard standard does support line breaks using the ‘CRLF’ line break. Using a simple paragraph return (Enter) seems to work in the Plain Text field. Test any such text blocks on a few sample readers to ensure the results are acceptable.

Example:

You may have to expand this image in its own tab to enable readability.

Encoding Text Messages (SMS)

InDesign has a default entry option for SMS (text) QR codes. There is little reason to use a custom entry method for this, but for reference and to enable custom, mass or script-driven entry, the encoded string format is:

SMSTO:<phone num>:<message up to 165 char>

• Neither the phone number nor the message is checked for validity.
• Most readers will present the retrieved phone number and message for sending approval, although many can be configured to send the text automatically.

Example:

SMSTO:(212) 555-1212:SIGNMEUP

Encoding Phone Numbers (TEL)

A common QR code use is to encode a phone number, much like SMS without the attached message. InDesign has no default entry option for TEL, but it’s trivial to implement using custom entry:

TEL:<phone num>

• No format or other validity checking is applied to the phone number string, which may contain any standard separator characters (space, parentheses, dashes).
• Most readers will present the retrieved phone number for approval, although many can be configured to dial it automatically.

Example:

TEL:(212) 555-1212

Encoding Email Messages (MATMSG)

InDesign has a default entry mode for email codes. Again, there is little reason to use custom entry, other than for repeated or scripted creation, but the code format is as follows:

MATMSG:
TO:<email address>;
SUB:<subject line>;
BODY:<message body>;;

• None of the fields are type-checked in any way; use care in specifying the email address in particular.
• Line returns (CRLF) can be used in the message body, using Enter. The length of the body content is probably the overall code limit of about 2900 characters, less those used for addressing and field codes.
• Most readers will present the email content for sending approval, although many can be configured to send it automatically.
• Although savvy readers of this guide might assume that other fields can be added (cc:, bcc:, reply-to:, etc.) most readers ignore these fields or simply add all email addresses to the To: string.

Example:

MATMSG:
TO:joe@null.com;
SUB:Automating email barcodes;
BODY:Joe --

Hope you got the lunch invite.

This is just a reminder that email can be encoded into QRcodes should you ever want to do such a silly thing.;;

Using mailto:

You can also use the web/HTML ‘mailto:’ protocol in a QR code. References for this protocol, which allows more complex header information, can easily be found by searching.

Encoding URLs (Web Links/Addresses)

InDesign of course has a default entry option for web addresses, which is perhaps one of the two most common uses for QR codes. The default entry mode works well enough, but using a custom entry gives the designer more control over the code content, as well as the aforementioned ability to automate or script their creation.

• Any string entered in the InDesign field will be prefaced with http://, if a valid prefix is not already specified, and encoded. This is about the only difference between this option and Plain Text.
• No type of validity checking of any kind is performed, and the “address” can in fact be complete gibberish.
• Using the custom entry mode gives more control, beginning with the ability to use other prefixes, such as https://, ftp:// etc. These will be included without modification, in place of the default, but are not type-checked. If you know of a valid prefix for, say, direct access to a social media site or other specialized destination, you can use facebook://, twitter:// etc., but the actual code and functionality is up to you to discover and evaluate.
• In the end, this is “just a URL”— you can do anything here you could with any other form of web or URI link.

Once again, most readers will present the URL for review before continuing to a web destination, but some readers may be configured to open the site immediately. The latter is a very bad idea, especially in the era of endless malware etc. No one should ever have their device automatically open any QR code web destination or link, and should always review scanned links before giving approval to proceed!

Example:

https://www.amazon.com/dp/B09HZB4NQS

Creating "Dynamic" QR Codes

This is where a “dynamic” QR code can be created, under the full control of the creator.

If the URL points to a redirection address, the code and URL will always remain the same, but the destination reached by users can be changed as often as desired. These could be:

• A ‘Tiny URL’ or ‘short URL’ address that can be redefined as necessary. Free services are available.
• An HTML META refresh redirect page.
• An .htaccess Redirect statement.

If you are putting a contact or new-customer QR code on products or materials that may have a shelf life of years, using this redirect method will allow you to update your welcome without former customers or subscribers losing the link.

Encoding WiFi Network Login (WIFI)

A spectacularly useful QR codes purpose is to present WiFi network login information. This is best for public-use networks such as those in libraries, coffee shops and the like since the password must be openly encoded in the QR code. However, for guest networks, it makes login a snap for any visitor.

(This also enables frequent changes to the network information, so that shops can readily shed nearby “vampire” users who obtain the login and then continue to use it from their apartment or office. Actual visitors can snag the new login info in a moment, even if if changes every day.)

WIFI:T:<security type>;S:<ssid>;P:<password>[;H:<boolean>];;

• No format or other validity checking is applied to any element.
• The security types should match the router or AP setting: WPA, WEP, WPA2 and NONE are common.
• The H: parameter is required with a true argument if the WiFi SSID is hidden or not broadcast. It can be omitted (or used with a false argument) for broadcast SSIDs.
• Most readers will present the retrieved network data for approval, although many can be configured to connect automatically.

Example:

WIFI:T:WPA;S:MyCoffeeHouseWIFI;P:ABC123DEF456GHI789;H:false;;

Encoding Geographic Location (GEO)

Although use is selective, geographic coordinates of extreme precision can be encoded into a QR code. This could be used to establish geo-caching, trail or even aviation markers, or markers to set a map location to an intended destination.

GEO:<latitude>,<longitude>

• No format or other validity checking is applied to any element.
• Decimal values should be used, up to the six-place figures commonly used in Google Maps and Earth. (Don't forget the minus sign on the longitude of most locations in the Western Hemisphere!)
• Most readers will present the retrieved location data for approval, although many can be configured to connect automatically.

Example:

GEO:40.711605,-74.013182

Encoding Contact Data (vCard, Business Card)

This is the big one, in at least two ways. Along with URL codes, contact-info codes are probably the biggest use of QR codes. They were once somewhat faddishly required on business cards; although less often seen there these days, they are still useful to transfer contact information quickly and accurately.

As noted, ID’s default “business card” data entry will only encode the information using the vCard format, and in the older — obsolete, really — v2.1 standard at that. As more than one frustrated designer has found, v2.1 doesn’t handle accented characters. There are also other contact-info formats some designers may wish to use (or, more accurately, their employer or client may wish to use). So, if there is any QR code format worth learning to do in this custom mode, Contact Info is it.

While vCard seems to be the dominant and most widely used contact information format (especially when contained in .vcf files that can be attached to various message types), there are other contact-info formats in use. The most common of these is MeCard, which was developed in Japan for exchange of a limited contact information set between smartphones. Fortunately, the formats are similar enough that most devices seem to be able to read both, although information from whichever is the less compatible format may not be parsed into correct Contacts or application fields.

MeCard Format

You can also create QR codes encoded with MeCard data; the chief limitation of the format is fewer overall field types and no support for multiple fields of any one type. A fairly complete listing of the format and field types can be found here:

• Wikipedia: MeCard (QR Code) entry

vCard Format

We'll stay with vCard in the remainder of this discussion. For those who like a detailed reference, here are two. One is another Wikipedia entry that presents a reasonably good overview, and the second is the current full — and rather dense — vCard standard declaration. Both are useful in their place:

• Wikipedia: vCard entry

This is, oddly enough, one of the most coherent and comprehensive pages on the basics of vCard formatting out there. It may be all you need to write more complex QR code versions, although its organization is a little loose and you will have to, for example, carefully look for required fields and their coding.

• RFC 6350: vCard Format Specification

The comprehensive standards document for vCard, including some proposed extensions. Dense, but if you want to know all the standard codes you might use, their formats, and their requirements, this is the doc to bookmark.

There are three versions of vCard in use. Version 2.1 is still common, but has many limitations and should be avoided. Version 4.0 does not seem to be widely implemented, even after some ten years; it may be a case of simply adding too much complexity to what should be a simple data format. Version 3.0 seems to be the happy midpoint: supported by nearly all current devices and readers, but with no limitations in most modern uses, either. Unless otherwise noted, we will be discussing and working with vCard v3.0 for the remainder of this discussion.

InDesign & vCard

InDesign’s entry form allows input of one of each basic field type (following, oddly enough, the MeCard protocol). Besides the fixed v2.1 encoding (which, again, does not permit accented characters in the data fields), this limited structure may not accommodate your needs or those of your company or client. Fortunately, vCard (3.0) is a flexible format with dozens of defined field types, and nearly all can be duplicated to allow multiple email addresses, phone numbers, etc.

Let's start with a fully populated InDesign vCard, for reference, comparing the input fields with the resulting encoded string:

BEGIN:VCARD
VERSION:2.1
N:<lastname>;<firstname>;
FN:<firstname> <lastname>
ORG:<company name>
TITLE:<title>
TEL;CELL:<phone #1>
TEL;WORK;VOICE:<phone #2>
ADR;WORK:;;<street>;<city>;<state>;<postcode>;<country>
EMAIL;WORK;INTERNET:<email address>
URL:<web address>
END:VCARD

Fairly obvious and intuitive, but observe the many small details of the field names, separator characters, etc. (And yes, both the N and FN fields are needed.) But there are many things missing here, as well. For one thing, there can be three more fields in the N field (middle name, prefix and suffix). The telephone numbers and online address can be other than WORK, etc.

In perhaps the most important variation, if you were to enter that same block into Plain Text, but substitute VERSION:3.0 for the second line… the resulting code would be interpreted under v3.0 rules, which would allow any field to contain ‘upper’ characters such as accented letters. Yup, it’s that simple.

The InDesign export is following v2.1 convention for field parameters in using, for example, WORK in place of the v3.0 TYPE="work". Either seems to work in most cases, but it is probably sensible to use the newer definitions over the outmoded ones.

Creating Custom vCard Codes

Here is the most basic vCard format, with the minimium required elements in the required order:

BEGIN:VCARD
VERSION:3.0
N:
FN:
END:VCARD

The N (structured name) and FN (formatted name) fields are required even if empty.

With this basic frame, the information from the full InDesign version above, and the two resources listed, you should be able to create vCard codes of almost any combination of content.

And here is a more extended vCard format, which you may cut and paste and edit as necessary.

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

Basic notes for formatting fields and parameters in this structure are as follows:

• All secondary fields are optional and may be omitted. For example, under N, you can omit everything after firstname. If, though, you omit middlename but want to include a prefix, such as ‘Dr.’, you must include the empty semicolon to mark field order.
• Parameters separated by commas are multiples of the same type (e.g. 'M.S.' and 'Ph.D.') and optional. Not all readers will parse the additional elements.
• The type flags (TYPE="work" etc.) are optional but help the Contact app sort and tag multiple entries.
• Many TYPE definitions can be stacked when separated by commas.
• The ADR (address) parameter can accept multiple fields.
• The TEL (telephone) parameter can accept multiple TYPE modifiers.

When the above basic structures, keywords and information begins to make sense, most designers will want to refer to the complete vCard definition, RFC 6350, which specifies several dozen parameters including added personal information (gender, birthday, anniversary), company information, organizational information such as time and datestamps, and more. The link is above.

4 :: Exporting QR Codes from InDesign

If you use QR codes only within InDesign projects, the integral nature of the code generator offers its full power. Codes are live elements that can be resized, managed with many of ID's layout tools and features, previewed by hovering over them and edited with a simple right-click.

If, on the other hand, you want to use InDesign as a code generator for exported/outside use, it has other advantages. It is, of course, completely stand-alone, doesn't embed unwanted mal-code around your content, isn't tied to a pay service (well, other than the Adobe subscription), is as secure as your workstation happens to be, and is more or less free.

A further advantage of InDesign, especially using the custom code techniques above, is that code creation can be managed with scripting and other automation, making things like generating a large series of vCard, warehouse, event badge and other codes relatively simple.

But you have to get the darn things out of InDesign to use them in, say, web pages or projects created using other applications. Here's a streamlined method for that.

Create an InDesign Export Project

In a nutshell, an InDesign document intended for QR code creation and export should have small, square pages. That will eliminate any need to crop the exported graphics.

To expand that notion:

• Create an ID document with several 4-inch by 4-inch pages with zero margins.
• Each time you create a new code, select a blank page and drag the placement corner to corner.
• Export the page to PDF if you want a scalable graphic for use in an app sophisticated enough to handle placed PDFs.
• Otherwise, export the page to PNG at 300 dpi, Maximum Quality, Gray color space.

With the "isolation zone" around the pixel area, this will generate a QR code of about 950 pixels square, high enough resolution for almost any purpose, but still as a conveniently small file (typically 5-100k).

If you are creating only relatively simple, “coarse” codes, you could go down to 3 inches, or even 2. But two-color, gray-space PNG files are very small anyway... may as well have the resolution to use! 4 inches should be enough for the finest granularity most high-content codes will create, but if you are creating text codes with large content and thus a very fine screen, using a 5 or even 6 inch page might be wise.

From there, you can color the exported codes in Photoshop if you want to be fancy and faddish. Be sure to use dark colors to maintain adequate contrast, and be sure to turn off all anti-aliasing and use resizing that preserves hard edges. (Letting the pixels get fuzzy will reduce read reliability)

Embedding logos is a try-and-try-again thing, and will probably not work very often since ID exports QR codes at the second-lowest of four error correction levels. (If the maximum level, H, was allowed, it would probably be a snap to cover up the middle square with a logo.)

External Identification

Within ID, it's just a matter of hovering over a code or even opening the code editor to identify it. Out in the exported realm, if you have multiple codes for a project or library, careful file naming can help keep things sorted out. In some circumstances, putting a small text code in the isolation margin of each code will give an immediate identification, won't interfere with code reading and probably won't be noticed by most human readers or users of the document. (You can always “tuck in” the graphic margin to hide the identifier as a late/last step, too.)

Conclusion

So there you have it, InDesign users — a method to create almost any useful QR code format, with automation and scripting potential and full control, with no security issues, malware potential, ‘pay-me’ or usage limits, and all at no extra cost. Go fill the world with more “Martian Fingerprints.”

Here's a link code for this page, all fancied up and everything:

---