Chapter 2, Template Features for Designing Static Forms
XFA Specification
Formatting Text That Appears as Fixed or Variable Content
49
Special Processing of Barcode Data
Some types of barcodes can hold arbitrary binary data. Others are limited to a particular set of characters
or codes. It is the responsibility of the form creator to ensure that the data is appropriate for the barcode,
for example by imposing a validation on the field.
Some types of barcodes are inherently fixed in data capacity. Others may optionally grow to fit the
supplied data. However even growable one-dimensional barcodes hold a few tens of bytes at most.
Two-dimensional barcodes can hold up to a kilobyte or so. When the data does not fit into the barcode the
data is truncated.
In view of the limited capacity of even two-dimensional barcodes it is desireable to be able to easily
specify a subset of the data to incorporate into the bar code. XFA already includes a
manifest
element
which represents a collection of nodes. In XFA 2.4 the
manifest
element has been made a child of
variables
and new methods have been provided so that a script can easily set the value of a barcode
field to an XML representation of the values of the nodes in a
manifest
.
The data must be expressed as a stream of bytes before it can be placed into the barcode. By default it is
encoded and serialized as UTF-8 (without a byte order mark). However other codings can be specified so
that the encoding matches the expectations of existing applications. This is particularly important for
QRCode applications which normally uses Shift-JIS encoding.
There is an option to apply lossless compression to the data after it is encoded but before it is printed in
the barcode. The default behavior is not to compress. However when the
dataPrep
attribute is set to
flateCompress
the data that is placed in the barcode is a byte with a numeric value of 257, followed by
a byte with a numeric value of 1, followed by the data compressed using the method defined by the
Internet Engineering Task Force (IETF) in
[RFC1951].
No predictor is used. Compression must not be
specified for barcode types that cannot hold arbitrary binary.
Finally, the data may be encrypted after it is encoded and optionally compressed but before it is printed in
the barcode. The default behavior is not to encrypt. But when the
barcode
element has an
encrypt
child the certificate and other properties of the
encrypt
element are used to encrypt the data with a
public key. This way the printed barcode does not reveal its content to anyone who does not know the
private key. The encrypted data consists of:
●
●
●
●
●
A byte containing the hexadecimal value 82 (decimal 130).
A byte containing the value 1.
A byte containing the second-least-significant byte of the certificate serial number.
A byte containing the least-significant byte of the certificate serial number.
A random 16-byte session key encrypted using the algorithm and the public key specified by the
certificate.
The serialized and optionally compressed data encrypted using the RC4 algorithm and the session key.
●
Note:
RC4 is a copyrighted, proprietary algorithm of RSA Security, Inc. Adobe Systems has licensed this
algorithm for use in its Acrobat products. Independent software vendors may be required to license
RC4 to develop software that encrypts or decrypts RC4-encrypted barcodes. For further
information, visit the RSA Web site at <http://www.rsasecurity.com> or send e-mail to
<products@rsasecurity.com>.
The chosen encoding, compression, and encryption affect only the printed barcode, not the internal
representation of the data or what the user sees when the field has focus in interactive contexts.